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 checks that the target type of the cast (an error related
to which is being reported) does not have types to be inferred before
checking if it implements the `From` trait.
Signed-off-by: David Wood <david@davidtw.co>
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
