Rollup of 13 pull requests #85949
Closed
Rollup of 13 pull requests #85949
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This commit updates the compiler's handling of the `#[target_feature]` attribute when applied to functions on WebAssembly-based targets. The compiler in general requires that any functions with `#[target_feature]` are marked as `unsafe` as well, but this commit relaxes the restriction for WebAssembly targets where the attribute can be applied to safe functions as well. The reason this is done is that the motivation for this feature of the compiler is not applicable for WebAssembly targets. In general the `#[target_feature]` attribute is used to enhance target CPU features enabled beyond the basic level for the rest of the compilation. If done improperly this means that your program could execute an instruction that the CPU you happen to be running on does not understand. This is considered undefined behavior where it is unknown what will happen (e.g. it's not a deterministic `SIGILL`). For WebAssembly, however, the target is different. It is not possible for a running WebAssembly program to execute an instruction that the engine does not understand. If this were the case then the program would not have validated in the first place and would not run at all. Even if this were allowed in some hypothetical future where engines have some form of runtime feature detection (which they do not right now) any implementation of such a feature would generate a trap if a module attempts to execute an instruction the module does not understand. This deterministic trap behavior would still not fall into the category of undefined behavior because the trap is deterministic. For these reasons the `#[target_feature]` attribute is now allowed on safe functions, but only for WebAssembly targets. This notably enables the wasm-SIMD intrinsics proposed for stabilization in rust-lang#74372 to be marked as safe generally instead of today where they're all `unsafe` due to the historical implementation of `#[target_feature]` in the compiler.
Fixes: rust-lang#84018 With `-Z instrument-coverage`, coverage reporting of dead blocks (for example, blocks dropped because a conditional branch is dropped, based on const evaluation) is now supported. Note, this PR relands an earlier, reverted PR that failed when compiling generators. The prior issues with generators has been resolved and a new test was added to prevent future regressions. Check out the resulting changes to test coverage of dead blocks in the test coverage reports in this PR.
…mber of exported symbols for each crate Restored underlying num_def_ids_method Update compiler/rustc_metadata/src/rmeta/decoder/cstore_impl.rs Changed name to fit with naming convention Co-authored-by: bjorn3 <bjorn3@users.noreply.github.com> Update compiler/rustc_metadata/src/rmeta/decoder/cstore_impl.rs Replace regular doc with Rustdoc comment Co-authored-by: Joshua Nelson <jyn514@gmail.com> Clarifies third-party use of num_def_ids_untracked
This wasn't necessary for msvc and caused issues where different types with the same name such as different instantiations of `Option<T>` would have colliding debuginfo. This confused the debugger which would pick one of the type definitions and use for all types with that name even though they had different layout.
Previously, we would generate a single struct with the layout of the dataful variant plus an extra field whose name contained the value of the niche (this would only really work for things like `Option<&_>` where we can determine that the `None` case maps to `0` but for enums that have multiple tag only variants, this doesn't work). Now, we generate a union of two structs, one which is the layout of the dataful variant and one which just has a way of reading the discriminant. We also generate an enum which maps the discriminant value to the tag only variants. We also encode information about the range of values which correspond to the dataful variant in the type name and then use natvis to determine which union field we should display to the user. As a result of this change, all niche-layout enums render correctly in WinDbg and Visual Studio!
This makes the type name inline with the proposed standard in rust-lang#85269.
…=m-ou-se Stabilize `vecdeque_binary_search` This PR stabilizes the feature `vecdeque_binary_search` as tracked in rust-lang#78021. The tracking issue has not received any comments for the past 5 months, and concerns have been raised neither in the RFC rust-lang/rfcs#2997 nor in the tracking issue rust-lang#78021.
…sm, r=joshtriplett rustc: Allow safe #[target_feature] on wasm This commit updates the compiler's handling of the `#[target_feature]` attribute when applied to functions on WebAssembly-based targets. The compiler in general requires that any functions with `#[target_feature]` are marked as `unsafe` as well, but this commit relaxes the restriction for WebAssembly targets where the attribute can be applied to safe functions as well. The reason this is done is that the motivation for this feature of the compiler is not applicable for WebAssembly targets. In general the `#[target_feature]` attribute is used to enhance target CPU features enabled beyond the basic level for the rest of the compilation. If done improperly this means that your program could execute an instruction that the CPU you happen to be running on does not understand. This is considered undefined behavior where it is unknown what will happen (e.g. it's not a deterministic `SIGILL`). For WebAssembly, however, the target is different. It is not possible for a running WebAssembly program to execute an instruction that the engine does not understand. If this were the case then the program would not have validated in the first place and would not run at all. Even if this were allowed in some hypothetical future where engines have some form of runtime feature detection (which they do not right now) any implementation of such a feature would generate a trap if a module attempts to execute an instruction the module does not understand. This deterministic trap behavior would still not fall into the category of undefined behavior because the trap is deterministic. For these reasons the `#[target_feature]` attribute is now allowed on safe functions, but only for WebAssembly targets. This notably enables the wasm-SIMD intrinsics proposed for stabilization in rust-lang#74372 to be marked as safe generally instead of today where they're all `unsafe` due to the historical implementation of `#[target_feature]` in the compiler.
…elwoerister
Improve debugging experience for enums on windows-msvc
This PR makes significant improvements over the status quo of debugging enums on the windows-msvc platform with either WinDbg or Visual Studio in three ways:
1. Improves the debugger experience for directly tagged enums.
2. Fixes a bug which caused the debugger to sometimes show the wrong debug info for niche layout enums. For example, `Option<&u32>` could sometimes use the debug info for `Option<&f64>` instead leading to nonsensical variable values in the debugger.
3. Significantly improves the debugger experience for niche-layout enums.
Let's look at a few examples:
```rust
pub enum CStyleEnum {
Base = 2,
Exponent = 16,
}
pub enum NicheLayoutEnum {
Tag1,
Data { my_data: CStyleEnum },
Tag2,
Tag3,
Tag4,
}
pub enum OtherEnum<T> {
Case1(T),
Case2(T),
}
fn main() {
let a = Some(CStyleEnum::Base);
let b = Option::<CStyleEnum>::None;
let c = NicheLayoutEnum::Tag1;
let d = NicheLayoutEnum::Data { my_data: CStyleEnum::Exponent };
let e = NicheLayoutEnum::Tag2;
let f = Some(&1u32);
let g = Option::<&'static u32>::None;
let h = Some(&2u64);
let i = Option::<&'static u64>::None;
let j = Some(12u32);
let k = Option::<u32>::None;
let l = Some(12.34f64);
let m = Option::<f64>::None;
let n = CStyleEnum::Base;
let o = CStyleEnum::Exponent;
let p = Some("IAMA optional string!".to_string());
let q = OtherEnum::Case1(42u32);
}
```
This is what WinDbg Preview shows using the latest rustc nightly:
Most of the variables don't show a meaningful value expect for a few cases that we have targeted natvis definitions covering. Even worse, drilling into many of these variables shows information that can be difficult to interpret without an understanding of the layout of Rust types:
With the changes in this PR, we're able to write two natvis definitions that cover all enum cases generally. After building with these changes, WinDbg now shows this instead:
Drilling into the same variables, we can see much more useful information:
Fixes rust-lang#84670
Fixes rust-lang#84671
…erage, r=wesleywiser Reland - Report coverage `0` of dead blocks Fixes: rust-lang#84018 With `-Z instrument-coverage`, coverage reporting of dead blocks (for example, blocks dropped because a conditional branch is dropped, based on const evaluation) is now supported. Note, this PR relands an earlier, reverted PR that failed when compiling generators. The prior issues with generators has been resolved and a new test was added to prevent future regressions. Check out the resulting changes to test coverage of dead blocks in the test coverage reports in this PR. r? `@tmandry` fyi: `@wesleywiser`
shrinking the deprecated method span part of rust-lang#85403 r? `@estebank`
…nikomatsakis Fix issue 85435 by restricting Fake Read precision This PR fixes the root bug of issue rust-lang#85435 by restricting Fake Read precision in closures and removing the feature gate introduced in PR rust-lang#85564. More info [here](rust-lang#85561 (comment)) and [here](rust-lang#85561 (comment)). Closes rust-lang#85561 r? `@nikomatsakis`
…ikomatsakis Clarify meaning of MachineApplicable suggestions. This documents the meaning of MachineApplicable in case of multiple suggestions, as described in rust-lang#53934 (comment) r? `@nikomatsakis`
Intra doc link-ify a reference to a function
convert assertion on rvalue::threadlocalref to delay bug Closes rust-lang#85768 r? `@oli-obk`
Restoring the `num_def_ids` function in the CStore API ## The context I am the maintainer of https://github.com/hacspec/hacspec, an embedded Rust DSL aimed at cryptographic specifications. As it is normal for an embedded DSL, Hacspec's compiler relies on being plugged to the internal API of the Rust compiler, which is unstable and subject to changes. ## The problem The Hacspec compiler features its own typechecker, that performs an additional, more restrictive typechecking pass over the Rust code of a crate. To complete this typechecking, the Hacspec compiler needs to retrieve the signature of functions defined in non-local imported crates. Rather than retrieving these signatures on-demand, the Hacspec compiler pre-populates its typechecking context with all the Hacspec-compatible symbols defined in non-local crates first. This requires having a way to iterate over all the definitions in a non-local crate. I used to do this with `CrateMetadata::all_def_path_hashes_and_def_ids`, but this function was deleted in 908bf5a. Then, I fellback on `CStore::num_def_ids`, exploiting the fact that all the `DefIds` for a crate have the same `krate_num` and range from `0` to `num_def_ids(krate_num)`. But `num_def_ids` was deleted in b6120bf. I looked to the `Cstore::item_children_untracked` function to replicate the feature of traversing through all the `DefId` for a crate, using `CRATE_DEF_INDEX` as the root, but this does not work as recursive `Cstore::item_children_untracked` calls do not reach all the symbols I was able to reach using the two previous methods. ## Description of this PR This PR simply restores in the public API of `CStore` the `num_def_ids` function, giving the size of the definition table for a given crate.
…onst-default, r=petrochenkov Add test for forward declared const param defaults
Add `Ty::is_union` predicate
…schievink Validate type of locals used as indices
|
@bors r+ rollup=never p=5 |
|
📌 Commit da85cce has been approved by |
bors
added
the
S-waiting-on-bors
|
⌛ Testing commit da85cce with merge 3e53780740863da5995bc26cb8308d8fc13db098... |
|
The job Click to see the possible cause of the failure (guessed by this bot) |
|
💔 Test failed - checks-actions |
bors
added
S-waiting-on-review
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Successful merges:
vecdeque_binary_search#83362 (Stabilizevecdeque_binary_search)0of dead blocks #85385 (Reland - Report coverage0of dead blocks)num_def_idsfunction in the CStore API #85889 (Restoring thenum_def_idsfunction in the CStore API )Ty::is_unionpredicate #85934 (AddTy::is_unionpredicate)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup