Always resolve type@primitive as a primitive, not a module
Previously, if there were a module in scope with the same name as the
primitive, that would take precedence. Coupled with
https://github.com/rust-lang/rust/issues/58699, this made it impossible
to link to the primitive when that module was in scope.
This approach could be extended so that `struct@foo` would no longer resolve
to any type, etc. However, it could not be used for glob imports:
```rust
pub mod foo {
pub struct Bar;
}
pub enum Bar {}
use foo::*;
// This is expected to link to `inner::Bar`, but instead it will link to the enum.
/// Link to [struct@Bar]
pub struct MyDocs;
```
The reason for this is that this change does not affect the resolution
algorithm of rustc_resolve at all. The only reason we could special-case
primitives is because we have a list of all possible primitives ahead of time.
Closes https://github.com/rust-lang/rust/issues/74063
r? @Manishearth
mir: mark mir construction temporaries as internal
Fixes#73914.
This PR marks temporaries from MIR construction as internal such that they are skipped in `sanitize_witness` (where each MIR local is checked to have been contained within the generator interior computed during typeck). This resolves an ICE whereby the construction of checked addition introduced a `(u64, bool)` temporary which was not in the HIR and thus not in the generator interior.
r? @matthewjasper
Audit hidden/short code suggestions
Should fix#73641.
Audit uses of `span_suggestion_short` and `tool_only_span_suggestion` (`span_suggestion_hidden` is already tested with `run-rustfix`). Leave some FIXMEs for futher improvements/fixes.
r? @estebank
Previously, if there were a module in scope with the same name as the
primitive, that would take precedence. Coupled with
https://github.com/rust-lang/rust/issues/58699, this made it impossible
to link to the primitive when that module was in scope.
This approach could be extended so that `struct@foo` would no longer resolve
to any type, etc. However, it could not be used for glob imports:
```rust
pub mod foo {
pub struct Bar;
}
pub enum Bar {}
use foo::*;
// This is expected to link to `inner::Bar`, but instead it will link to the enum.
/// Link to [struct@Bar]
pub struct MyDocs;
```
The reason for this is that this change does not affect the resolution
algorithm of rustc_resolve at all. The only reason we could special-case
primitives is because we have a list of all possible primitives ahead of time.
add `lazy_normalization_consts` feature gate
In #71973 I underestimated the amount of code which is influenced by lazy normalization of consts
and decided against having a separate feature flag for this.
Looking a bit more into this, the following issues are already working with lazy norm in its current state #47814#57739#73980
I therefore think it is worth it to enable lazy norm separately. Note that `#![feature(const_generics)]` still automatically activates
this feature, so using `#![feature(const_generics, lazy_normalization_consts)]` is redundant.
r? @varkor @nikomatsakis
Fix try_print_visible_def_path for Rust 2018
The recursive check of `try_print_visible_def_path` did not properly handle the Rust 2018 case of crate-paths without 'extern crate'. Instead, it returned a "not found" via (false, self).
This fixes#56175.
Some refactoring around intrinsic type checking
So... This PR went a bit overboard. I wanted to make the `rustc_peek` intrinsic safe (cc @ecstatic-morse ), and remembered a long-standing itch of mine. So I made that huge `&str` match for the intrinsic name a match on `Symbol`s (so basically `u32`s). This is unlikely to have a positive perf effect, even if it likely has better codegen (intrinsics are used rarely, mostly once in their wrapper), so it's mostly a consistency thing since other places actually match on the symbol name of the intrinsics.
Handle inactive enum variants in `MaybeUninitializedPlaces`
Resolves the first part of #69715.
This is the equivalent of #68528 but for `MaybeUninitializedPlaces`. Because we now notify drop elaboration that inactive enum variants might be uninitialized, some drops get marked as ["open" that were previously "static"](e0e5d82e16/src/librustc_mir/transform/elaborate_drops.rs (L191)). Unlike in #69715, this isn't strictly better: An "open" drop expands to more MIR than a simple call to the drop shim. However, because drop elaboration considers each field of an "open" drop separately, it can sometimes eliminate unnecessary drops of moved-from or unit-like enum variants. This is the case for `Option::unwrap`, which is reflected in the `mir-opt` test.
cc @eddyb
r? @oli-obk
[mir-opt] Fix mis-optimization and other issues with the SimplifyArmIdentity pass
This does not yet attempt re-enabling the pass, but it does resolve a number of issues with the pass.
r? @oli-obk
I believe this closes#73223.
Add `format_args_capture` feature
This is the initial implementation PR for [RFC 2795](https://github.com/rust-lang/rfcs/pull/2795).
Note that, as dicussed in the tracking issue (#67984), the feature gate has been called `format_args_capture`.
Next up I guess I need to add documentation for this feature. I've not written any docs before for rustc / std so I would appreciate suggestions on where I should add docs.
Use 'tcx for references to AccessLevels wherever possible.
Most of the changes are just fallout from removing a lifetime parameter from structs, and mostly in clippy.
r? @Manishearth
resolve: disallow labelled breaks/continues through closures/async blocks
Fixes#73541.
This PR modifies name resolution to prohibit labelled breaks/continues through closures or async blocks, fixing an ICE. In addition, it improves the diagnostics surrounding labelled breaks/continues through closures or async blocks by informing the user if the label exists in an parent scope and telling them that won't work.
r? @petrochenkov (resolve)
cc @estebank (diagnostic changes) @tmandry (issue is from `wg-async-foundations`)
Use WASM's saturating casts if they are available
WebAssembly supports saturating floating point to integer casts behind a target feature. The feature is already available on many browsers. Beginning with 1.45 Rust will start defining the behavior of floating point to integer casts to be saturating as well. For this Rust constructs additional checks on top of the `fptoui` / `fptosi` instructions it emits. Here we introduce the possibility for the codegen backend to construct saturating casts itself and only fall back to constructing the checks ourselves if that is not possible.
Resolves part of #73591
This commit marks temporaries from MIR construction as internal such
that they are skipped in `sanitize_witness` (where each MIR local is
checked to have been contained within the generator interior computed
during typeck). This resolves an ICE whereby the construction of checked
addition introduced a `(u64, bool)` temporary which was not in the HIR
and thus not in the generator interior.
Signed-off-by: David Wood <david@davidtw.co>
This commit modifies resolve to disallow `break`/`continue` to labels
through closures or async blocks. This doesn't make sense and should
have been prohibited anyway.
Signed-off-by: David Wood <david@davidtw.co>
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
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
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
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
