Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rollup of 11 pull requests #129391

Closed
wants to merge 30 commits into from
Closed

Conversation

jieyouxu
Copy link
Member

Successful merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

bvanjoi and others added 30 commits July 5, 2024 01:00
Since the `compiler_builtins` update [1], ABI bugs on x86 should be
resolved. Enable tests for f16 on these platforms now.

[1]: rust-lang#125016
Since `f16` now works on x86 and x86-64, change doctests to use this
instead of aarch64. This is to make sure any changes get run in PR CI.
1. Decouple them.
2. Make logic around `diagnostic_outside_of_impl`'s early exits simpler.
3. Make `untranslatable_diagnostic` run one loop instead of two
   and not allocate an intermediate vec.
4. Overall, reduce the amount of code executed
   when the lints do not end up firing.
This approach is, roughly, based on how Discourse does it.
It came up while discussing some other possible sidebar changes,
as a design that made rapid scanning easier while avoiding the
inherent trade-offs in summarizing.
`Cell` and `RefCell` have their `into_inner` methods const unstable.
`OnceCell` has the same logic, so add it under the same gate.

Tracking issue: rust-lang#78729
This makes it easier for maintainers to see what the Python script is for.
Trying to get rid of this Python script looks tempting, because it's currently
the only Python script in the whole `run-make` suite that we actually run.

But getting rid of it would require pulling in a Rust crate to parse XML
instead, and that's probably not worth the extra hassle for a relatively-minor
test.
…avidtwco

Implement `-Z embed-source` (DWARFv5 source code embedding extension)

Implement rust-lang/compiler-team#764 MCP which adds an unstable flag that exposes LLVM's [DWARFv5 source code embedding](https://dwarfstd.org/issues/180201.1.html) support.
use old ctx if has same expand environment during decode span

Fixes rust-lang#112680

The root reason why rust-lang#112680 failed with incremental compilation on the second attempt is the difference in `opaque` between the span of the field [`ident`](https://github.com/rust-lang/rust/blob/master/compiler/rustc_hir_typeck/src/expr.rs#L2348) and the span in the incremental cache at `tcx.def_ident_span(field.did)`.

-  Let's call the span of `ident` as `span_a`, which is generated by [`apply_mark_internal`](https://github.com/rust-lang/rust/blob/master/compiler/rustc_span/src/hygiene.rs#L553-L554). Its content is similar to:

```rs
span_a_ctx -> SyntaxContextData {
      opaque: span_a_ctx,
      opaque_and_semitransparent: span_a_ctx,
      // ....
}
```

- And call the span of `tcx.def_ident_span` as `span_b`, which is generated by [`decode_syntax_context`](https://github.com/rust-lang/rust/blob/master/compiler/rustc_span/src/hygiene.rs#L1390). Its content is:

```rs
span_b_ctx -> SyntaxContextData {
      opaque: span_b_ctx,
      // note `span_b_ctx` is not same as `span_a_ctx`
      opaque_and_semitransparent: span_b_ctx,
      // ....
}
```

Although they have the same `parent` (both refer to the root) and `outer_expn`, I cannot find the specific connection between them. Therefore, I chose a solution that may not be the best: give up the incremental compile cache to ensure we can use `span_a` in this case.

r?  ``@petrochenkov`` Do you have any advice on this? Or perhaps this solution is acceptable?
Enable `f16` on x86 and x86-64

Since the `compiler_builtins` update [1], ABI bugs on x86 should be resolved. Enable tests for f16 on these platforms now.

[1]: rust-lang#125016

try-job: i686-gnu
try-job: dist-i586-gnu-i586-i686-musl
…it_unsafe, r=tgross35

WASI: forbid `unsafe_op_in_unsafe_fn` for `std::{os, sys}`

Part of rust-lang#127747 for WASI

try-job: test-various
…ints, r=davidtwco

 Improve diagnostic-related lints: `untranslatable_diagnostic` & `diagnostic_outside_of_impl`

Summary:
- Made `untranslatable_diagnostic` point to problematic arguments instead of the function call
  (I found this misleading while working on some `A-translation` PRs: my first impression was that
  the methods themselves were not translation-aware and needed to be changed,
  while in reality the problem was with the hardcoded strings passed as arguments).
- Made the shared pass of `untranslatable_diagnostic` & `diagnostic_outside_of_impl` more efficient.

``@rustbot`` label D-imprecise-spans A-translation
…, r=jieyouxu

Allow rust staticlib to work with MSVC's /WHOLEARCHIVE

This fixes rust-lang#129020 by renaming the `__NULL_IMPORT_DESCRIPTOR` to prevent conflicts.

try-job: dist-i686-msvc
…=light, r=GuillaumeGomez

rustdoc: animate the `:target` highlight

This approach is, roughly, based on how Discourse does it. It came up while discussing [some other possible sidebar changes](https://rust-lang.zulipchat.com/#narrow/stream/266220-t-rustdoc/topic/Moving.20deprecated.20items.20out.20of.20the.20way), as a design that made rapid scanning easier while avoiding the inherent trade-offs in summarizing.

https://github.com/user-attachments/assets/f7a8fec3-70a5-40a1-92ea-bfdffbd61c22
…n_check_language_ub, r=workingjubilee,the8472

Change `assert_unsafe_precondition` docs to refer to `check_language_ub`
…r, r=Noratrieb

Add `const_cell_into_inner` to `OnceCell`

`Cell` and `RefCell` have their `into_inner` methods const unstable. `OnceCell` has the same logic, so add it under the same gate.

Tracking issue: rust-lang#78729
Advise against removing the remaining Python scripts from `tests/run-make`

After some recent PRs (e.g. rust-lang#129185), there are only two Python scripts left in `tests/run-make`.

Having come so far, it's tempting to try to get rid of the remaining ones. But after trying that myself, I've come to the conclusion that it's not worth the extra hassle, especially if it means pulling in an XML-parsing crate just for one test.

This PR therefore leaves behind a few signpost comments to explain why getting rid of these particular scripts has low value.
…-errors

Do not rely on names to find lifetimes.

For some reason, we were trying to find the lifetime parameter from its name, instead of using the def_id we have.

This PR uses it instead. This changes some ui tests, I think to be more sensible.
@rustbot rustbot added A-run-make Area: port run-make Makefiles to rmake.rs O-wasi Operating system: Wasi, Webassembly System Interface S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. rollup A PR which is a rollup labels Aug 22, 2024
@jieyouxu
Copy link
Member Author

@bors r+ rollup=never p=5

@bors
Copy link
Contributor

bors commented Aug 22, 2024

📌 Commit 24e7d69 has been approved by jieyouxu

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Aug 22, 2024
@jieyouxu
Copy link
Member Author

Oh wait no this is going to crash into #129365.

@jieyouxu jieyouxu closed this Aug 22, 2024
@jieyouxu jieyouxu deleted the rollup-h9m0d6y branch August 22, 2024 06:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-run-make Area: port run-make Makefiles to rmake.rs O-wasi Operating system: Wasi, Webassembly System Interface rollup A PR which is a rollup S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.