Rollup of 10 pull requests
Successful merges:
- #73414 (Implement `slice_strip` feature)
- #73564 (linker: Create GNU_EH_FRAME header by default when producing ELFs)
- #73622 (Deny unsafe ops in unsafe fns in libcore)
- #73684 (add spans to injected coverage counters, extract with CoverageData query)
- #73812 (ast_pretty: Pass some token streams and trees by reference)
- #73853 (Add newline to rustc MultiSpan docs)
- #73883 (Compile rustdoc less often.)
- #73885 (Fix wasm32 being broken due to a NodeJS version bump)
- #73903 (Changes required for rustc/cargo to build for iOS targets)
- #73938 (Optimise fast path of checked_ops with `unlikely`)
Failed merges:
r? @ghost
Fix wasm32 being broken due to a NodeJS version bump
Emscripten's SDK [recently bumped the version of NodeJS they shipped](https://github.com/emscripten-core/emsdk/pull/529), but our Dockerfile for the wasm32 builder hardcoded the version number. This will cause consistent CI failures once the currently cached image is rebuilt (either due to a change or due to the cache expiring).
This PR fixes the problem by finding the latest version of NodeJS in the Emscripten SDK and symlinking it to a "latest" directory, which is then added to the `PATH`.
Compile rustdoc less often.
Previously rustdoc was built 3 times with `x.py test`:
1. stage2 (using stage1 compiler) for compiletest tests (stage1-tools copied to stage2).
2. stage1 (using stage0 compiler) for std crate tests (stage0-tools copied to stage1).
3. stage2 test (using stage2 compiler) for rustdoc crate tests and error_index_generator (stage2-tools).
This PR removes the majority of number 3, where it will instead use the stage1 compiler, which will share the artifacts from number 1.
This matches the behavior of the libstd crate tests. I don't think it is entirely necessary to run the tests using stage2.
At `-j2`, the last build step goes from about 300s to 70s on my machine. It's not a huge win, but shaving 4 minutes isn't bad.
The other two builds would be pretty difficult (or undesired or impossible) to unify. It looks like std tests use stage1 very intentionally (see `force_use_stage1` and its history), and compiletests use the top stage very intentionally.
Unfortunately the linkchecker builds all docs at stage2 (stage2-tools), which means a few build script artifacts are not shared. It's not really clear to me how to fix that (because it uses `default_doc`, there doesn't seem to be any control over the stages).
---
For `x.py doc`, rustdoc was previously built three times (with compiler-docs):
1. stage2 (using stage1 compiler) for normal documentation output (stage1-tools copied to stage2).
2. stage1 (using stage0 compiler) for compiler-docs
3. stage2 (using stage2 compiler) for error_index_generator (stage2-tools)
This PR combines these so that they consistently use the "top stage" rustdoc. I don't know why the compiler-docs was written to use stage minus one, but it seems better to be consistent across the doc steps.
---
I've tried to test this with a variety of commands (`x.py doc`, `x.py test`, different `--stage` flags, `full-bootstrap`, setting `--target`, etc.) to try to make sure there aren't significant regressions here. It's tricky since there are so many variables, and this stuff is difficult for me to fully understand.
Closes#70799 (I think)
add spans to injected coverage counters, extract with CoverageData query
This is the next iteration on the Rust Coverage implementation, and follows PR #73488
@tmandry @wesleywiser
I came up with an approach for coverage spans, pushing them through the Call terminator as additional args so they can be extracted by the CoverageData query.
I'm using an IndexVec to store them in CoverageData such that there can be only one per index (even if parts of the MIR get duplicated during optimization).
If this approach works for you, I can quickly expand on this to build a separate IndexVec for counter expressions, using a separate call that will be ignored during code generation, but from which I can extract the counter expression values.
Let me know your thoughts. Thanks!
r? @tmandry
Rust compiler MCP rust-lang/compiler-team#278
Relevant issue: #34701 - Implement support for LLVMs code coverage instrumentation
Deny unsafe ops in unsafe fns in libcore
After `liballoc`, It's time for `libcore` :D
I planned to do this bit by bit to avoid having a big chunk of diffs, so to make reviews easier, and to make the unsafe blocks narrower and take the time to document them properly.
r? @nikomatsakis cc @RalfJung
Rewrite a few manual index loops with while-let
There were a few instances of this pattern:
```rust
while index < vec.len() {
let item = &vec[index];
// ...
}
```
These can be indexed at once:
```rust
while let Some(item) = vec.get(index) {
// ...
}
```
Particularly in `ObligationForest::process_obligations`, this mitigates
a codegen regression found with LLVM 11 (#73526).
`#[deny(unsafe_op_in_unsafe_fn)]` in libstd/fs.rs
The `libstd/fs.rs` part of https://github.com/rust-lang/rust/issues/73904 . Wraps the two calls to an unsafe fn `Initializer::nop()` in an `unsafe` block.
Followed instructions in parent issue, ran `./x.py check src/libstd/` after adding the lint and two warnings were given. After adding these changes, those disappear.
Split and expand nonstandard-style lints unicode unit test.
RFC 2457 requested that the `nonstandard_style` series of linted be adjusted to cover the non_ascii_identifier case. However when i read the code of those implementations, it seems they're already supporting non_ascii_identifiers. But the exact rules is a little different than what's proposed in RFC 2457.
So I splitted and expanded the existing test case to try to exercise every branch in the code. I think it'll also be easier to examine the cases in these unit tests to see whether it's ok to just leave them as is, or some adjustments are needed.
r? @Manishearth
Recover extra trailing angle brackets in struct definition
This commit applies the existing 'extra angle bracket recovery' logic
when parsing fields in struct definitions. This allows us to continue
parsing the struct's fields, avoiding spurious 'missing field' errors in
code that tries to use the struct.
Handle `macro_rules!` tokens consistently across crates
When we serialize a `macro_rules!` macro, we used a 'lowered' `TokenStream` for its body, which has all `Nonterminal`s expanded in-place via `nt_to_tokenstream`. This matters when an 'outer' `macro_rules!` macro expands to an 'inner' `macro_rules!` macro - the inner macro may use tokens captured from the 'outer' macro in its definition.
This means that invoking a foreign `macro_rules!` macro may use a different body `TokenStream` than when the same `macro_rules!` macro is invoked in the same crate. This difference is observable by proc-macros invoked by a `macro_rules!` macro - a `None`-delimited group will be seen in the same-crate case (inserted when convering `Nonterminal`s to the `proc_macro` crate's structs), but no `None`-delimited group in the cross-crate case.
To fix this inconsistency, we now insert `None`-delimited groups when 'lowering' a `Nonterminal` `macro_rules!` body, just as we do in `proc_macro_server`. Additionally, we no longer print extra spaces for `None`-delimited groups - as far as pretty-printing is concerned, they don't exist (only their contents do). This ensures that `Display` output of a `TokenStream` does not depend on which crate a `macro_rules!` macro was invoked from.
This PR is necessary in order to patch the `solana-genesis-programs` for the upcoming hygiene serialization breakage (https://github.com/rust-lang/rust/pull/72121#issuecomment-646924847). The `solana-genesis-programs` crate will need to use a proc macro to re-span certain tokens in a nested `macro_rules!`, which requires us to consistently use a `None`-delimited group.
See `src/test/ui/proc-macro/nested-macro-rules.rs` for an example of the kind of nested `macro_rules!` affected by this crate.
Provide more information on duplicate lang item error.
This gives some notes on the location of the files where the lang items were loaded from. Some duplicate lang item errors can be a little confusing, and this might help in diagnosing what has happened.
Here's an example when hitting a bug with Cargo's build-std:
```
error: duplicate lang item in crate `core` (which `rustc_std_workspace_core` depends on): `try`.
|
= note: the lang item is first defined in crate `core` (which `z10` depends on)
= note: first definition in `core` loaded from /Users/eric/Proj/rust/cargo/scratch/z10/target/target/debug/deps/libcore-a764da499c7385f4.rmeta
= note: second definition in `core` loaded from /Users/eric/Proj/rust/cargo/scratch/z10/target/target/debug/deps/libcore-5b082675aea34986.rmeta
```
expand: Stop using nonterminals for passing tokens to attribute and derive macros
Make one more step towards fully token-based expansion and fix issues described in https://github.com/rust-lang/rust/issues/72545#issuecomment-640276791.
Now `struct S;` is passed to `foo!(struct S;)` and `#[foo] struct S;` in the same way - as a token stream `struct S ;`, rather than a single non-terminal token `NtItem` which is then broken into parts later.
The cost is making pretty-printing of token streams less pretty.
Some of the pretty-printing regressions will be recovered by keeping jointness with each token, which we will need to do anyway.
Unfortunately, this is not exactly the same thing as https://github.com/rust-lang/rust/pull/73102.
One more observable effect is how `$crate` is printed in the attribute input.
Inside `NtItem` was printed as `crate` or `that_crate`, now as a part of a token stream it's printed as `$crate` (there are good reasons for these differences, see https://github.com/rust-lang/rust/pull/62393 and related PRs).
This may break old proc macros (custom derives) written before the main portion of the proc macro API (macros 1.2) was stabilized, those macros did `input.to_string()` and reparsed the result, now that result can contain `$crate` which cannot be reparsed.
So, I think we should do this regardless, but we need to run crater first.
r? @Aaron1011
Remove legacy InnoSetup GUI installer
On Windows the InnoSetup `.exe` installer was superseded by the MSI installer long ago. It's no longer needed.
The `.exe` installer hasn't been linked from the [other installation methods](https://forge.rust-lang.org/infra/other-installation-methods.html#standalone) page in many years. As far as I can tell the intent was always to remove this installer once the MSI proved itself. Though admittedly both installers feel very "legacy" at this point.
Removing this would mean we only maintain one Windows GUI installer and would speed up the distribution phase.
As a result of removing InnoSetup, this closes#24397
Test UI tests for pass=check
I'm going to just compare the builder times since I wasn't able to get this working nicely locally (hit some obscure linker error).
Fixes part of #69823
When a `macro_rules!` macro expands to another `macro_rules!` macro, we
may see `None`-delimited groups in odd places when another crate
deserializes the 'inner' macro. This commit 'unwraps' an outer
`None`-delimited group to avoid breaking existing code.
See https://github.com/rust-lang/rust/pull/73569#issuecomment-650860457
for more details.
The proper fix is to handle `None`-delimited groups systematically
throughout the parser, but that will require significant work. In the
meantime, this hack lets us fix important hygiene bugs in macros
Rollup of 17 pull requests
Successful merges:
- #72071 (Added detailed error code explanation for issue E0687 in Rust compiler.)
- #72369 (Bring net/parser.rs up to modern up to date with modern rust patterns)
- #72445 (Stabilize `#[track_caller]`.)
- #73466 (impl From<char> for String)
- #73548 (remove rustdoc warnings)
- #73649 (Fix sentence structure)
- #73678 (Update Box::from_raw example to generalize better)
- #73705 (stop taking references in Relate)
- #73716 (Document the static keyword)
- #73752 (Remap Windows ERROR_INVALID_PARAMETER to ErrorKind::InvalidInput from Other)
- #73776 (Move terminator to new module)
- #73778 (Make `likely` and `unlikely` const, gated by feature `const_unlikely`)
- #73805 (Document the type keyword)
- #73806 (Use an 'approximate' universal upper bound when reporting region errors)
- #73828 (Fix wording for anonymous parameter name help)
- #73846 (Fix comma in debug_assert! docs)
- #73847 (Edit cursor.prev() method docs in lexer)
Failed merges:
r? @ghost
Fix wording for anonymous parameter name help
```
--> exercises/functions/functions2.rs:8:15
|
8 | fn call_me(num) {
| ^ expected one of `:`, `@`, or `|`
|
= note: anonymous parameters are removed in the 2018 edition (see RFC 1685)
help: if this is a `self` type, give it a parameter name
|
8 | fn call_me(self: num) {
| ^^^^^^^^^
help: if this was a parameter name, give it a type
|
8 | fn call_me(num: TypeName) {
| ^^^^^^^^^^^^^
help: if this is a type, explicitly ignore the parameter name
|
8 | fn call_me(_: num) {
|
```
This commit changes "if this was a parameter name" to "if this is a parameter name" to match the wording of similar errors.
Use an 'approximate' universal upper bound when reporting region errors
Fixes#67765
When reporting errors during MIR region inference, we sometimes use
`universal_upper_bound` to obtain a named universal region that we
can display to the user. However, this is not always possible - in a
case like `fn foo<'a, 'b>() { .. }`, the only upper bound for a region
containing `'a` and `'b` is `'static`. When displaying diagnostics, it's
usually better to display *some* named region (even if there are
multiple involved) rather than fall back to a generic error involving
`'static`.
This commit adds a new `approx_universal_upper_bound` method, which
uses the lowest-numbered universal region if the only alternative is to
return `'static`.
Document the type keyword
Partial fix of #34601.
Two small examples, one clarifying that `type` only defines an alias, not a completely new type, the other explaining the use in traits.
@rustbot modify labels: T-doc,C-enhancement
Make `likely` and `unlikely` const, gated by feature `const_unlikely`
This PR also contains a fix to allow `#[allow_internal_unstable]` to work properly with `#[rustc_const_unstable]`.
cc @RalfJung @nagisa
r? @oli-obk
Remap Windows ERROR_INVALID_PARAMETER to ErrorKind::InvalidInput from Other
I don't know if this is acceptable or how likely it is to break existing code, but it seem to me ERROR_INVALID_PARAMETER "The parameter is incorrect" should map to ErrorKind::InvalidInput "A parameter was incorrect". Previously this value fell through to ErrorKind::Other.
I can't speak for anyone but myself, but I instinctively thought it would be InvalidInput.
Document the static keyword
Partial fix of #34601.
This documents the `static` keyword. It's basically a simplified version of the reference with more examples.
@rustbot modify labels: T-doc,C-enhancement
