Rollup of 7 pull requests #92471
Merged
Rollup of 7 pull requests #92471
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
Before this commit all vtables would have the same name "vtable" in debuginfo. Now they get a name that identifies the implementing type and the trait that is being implemented.
…info, r=wesleywiser Create more accurate debuginfo for vtables. Before this PR all vtables would have the same name (`"vtable"`) in debuginfo. Now they get an unambiguous name that identifies the implementing type and the trait that is being implemented. This is only one of several possible improvements: - This PR describes vtables as arrays of `*const u8` pointers. It would nice to describe them as structs where function pointer is represented by a field with a name indicative of the method it maps to. However, this requires coming up with a naming scheme that avoids clashes between methods with the same name (which is possible if the vtable contains multiple traits). - The PR does not update the debuginfo we generate for the vtable-pointer field in a fat `dyn` pointer. Right now there does not seem to be an easy way of getting ahold of a vtable-layout without also knowing the concrete self-type of a trait object. r? `@wesleywiser`
…verification failure (rust-lang#100)
* impl bitwise and & or
As per the libs team decision in rust-lang#58935. Closes rust-lang#58935
This commit adds LLVM Control Flow Integrity (CFI) support to the Rust compiler. It initially provides forward-edge control flow protection for Rust-compiled code only by aggregating function pointers in groups identified by their number of arguments. Forward-edge control flow protection for C or C++ and Rust -compiled code "mixed binaries" (i.e., for when C or C++ and Rust -compiled code share the same virtual address space) will be provided in later work as part of this project by defining and using compatible type identifiers (see Type metadata in the design document in the tracking issue rust-lang#89653). LLVM CFI can be enabled with -Zsanitizer=cfi and requires LTO (i.e., -Clto).
Add LLVM CFI support to the Rust compiler This PR adds LLVM Control Flow Integrity (CFI) support to the Rust compiler. It initially provides forward-edge control flow protection for Rust-compiled code only by aggregating function pointers in groups identified by their number of arguments. Forward-edge control flow protection for C or C++ and Rust -compiled code "mixed binaries" (i.e., for when C or C++ and Rust -compiled code share the same virtual address space) will be provided in later work as part of this project by defining and using compatible type identifiers (see Type metadata in the design document in the tracking issue rust-lang#89653). LLVM CFI can be enabled with -Zsanitizer=cfi and requires LTO (i.e., -Clto). Thank you, `@eddyb` and `@pcc,` for all the help!
* Rebase fallout. * Move rustc_middle::middle::cstore to rustc_session. * Create more accurate debuginfo for vtables. Before this commit all vtables would have the same name "vtable" in debuginfo. Now they get a name that identifies the implementing type and the trait that is being implemented. * Remove alloc::prelude As per the libs team decision in rust-lang#58935. Closes rust-lang#58935 * Make hash_result an Option. * Properly check `target_features` not to trigger an assertion * Add LLVM CFI support to the Rust compiler This commit adds LLVM Control Flow Integrity (CFI) support to the Rust compiler. It initially provides forward-edge control flow protection for Rust-compiled code only by aggregating function pointers in groups identified by their number of arguments. Forward-edge control flow protection for C or C++ and Rust -compiled code "mixed binaries" (i.e., for when C or C++ and Rust -compiled code share the same virtual address space) will be provided in later work as part of this project by defining and using compatible type identifiers (see Type metadata in the design document in the tracking issue rust-lang#89653). LLVM CFI can be enabled with -Zsanitizer=cfi and requires LTO (i.e., -Clto). * Update to nightly-2021-10-30 * Add deduplication of constant values as rustc relies on LLVM doing that Co-authored-by: Camille GILLOT <gillot.camille@gmail.com> Co-authored-by: Michael Woerister <michaelwoerister@posteo> Co-authored-by: Amanieu d'Antras <amanieu@gmail.com> Co-authored-by: Yuki Okushi <yuki.okushi@huawei.com> Co-authored-by: Ramon de C Valle <rcvalle@users.noreply.github.com>
fix sparc64 ABI for aggregates with floating point members Fixes rust-lang#86163
We already use the object crate for generating uncompressed .rmeta metadata object files. This switches the generation of compressed .rustc object files to use the object crate as well. These have slightly different requirements in that .rmeta should be completely excluded from any final compilation artifacts, while .rustc should be part of shared objects, but not loaded into memory. The primary motivation for this change is rust-lang#90326: In LLVM 14, the current way of setting section flags (and in particular, preventing the setting of SHF_ALLOC) will no longer work. There are other ways we could work around this, but switching to the object crate seems like the most elegant, as we already use it for .rmeta, and as it makes this independent of the codegen backend. In particular, we don't need separate handling in codegen_llvm and codegen_gcc. codegen_cranelift should be able to reuse the implementation as well, though I have omitted that here, as it is not based on codegen_ssa. This change mostly extracts the existing code for .rmeta handling to allow using it for .rustc as well, and adjust the codegen infrastructure to handle the metadata object file separately: We no longer create a backend-specific module for it, and directly produce the compiled module instead. This does not fix rust-lang#90326 by itself yet, as .llvmbc will need to be handled separately.
Also restricts r8-r14 from being used on Thumb1 targets as per rust-lang#90736.
Use object crate for .rustc metadata generation We already use the object crate for generating uncompressed .rmeta metadata object files. This switches the generation of compressed .rustc object files to use the object crate as well. These have slightly different requirements in that .rmeta should be completely excluded from any final compilation artifacts, while .rustc should be part of shared objects, but not loaded into memory. The primary motivation for this change is rust-lang#90326: In LLVM 14, the current way of setting section flags (and in particular, preventing the setting of SHF_ALLOC) will no longer work. There are other ways we could work around this, but switching to the object crate seems like the most elegant, as we already use it for .rmeta, and as it makes this independent of the codegen backend. In particular, we don't need separate handling in codegen_llvm and codegen_gcc. codegen_cranelift should be able to reuse the implementation as well, though I have omitted that here, as it is not based on codegen_ssa. This change mostly extracts the existing code for .rmeta handling to allow using it for .rustc as well, and adjusts the codegen infrastructure to handle the metadata object file separately: We no longer create a backend-specific module for it, and directly produce the compiled module instead. This does not `fix` rust-lang#90326 by itself yet, as .llvmbc will need to be handled separately. r? `@nagisa`
…plett Remove the reg_thumb register class for asm! on ARM Also restricts r8-r14 from being used on Thumb1 targets as per rust-lang#90736. cc ``@Lokathor`` r? ``@joshtriplett``
Remove redundant [..]s
They are also removed from the prelude as per the decision in rust-lang#87228. stdarch and compiler-builtins are updated to work with the new, stable asm! and global_asm! macros.
The resulting profile will include the crate name and will be stored in the `--out-dir` directory. This implementation makes it convenient to use LLVM time trace together with cargo, in the contrast to the previous implementation which would overwrite profiles or store them in `.cargo/registry/..`.
These only finish in reasonable time with optimizations enabled. This patch file is copied from cg_clif.
rustc_interface already calls it for you
Prevent spurious build failures and other bugs caused by parallel runs of x.py. We back the lock with sqlite, so that we have a cross-platform locking strategy, and which can be done nearly first in the build process (from Python), which helps move the lock as early as possible.
Remove existing problematic cases.
…Simulacrum Lock bootstrap (x.py) build directory Closes rust-lang#76661, closes rust-lang#80849, `x.py` creates a lock file at `project_root/lock.db` r? `@jyn514` , because he was one that told me about this~
…8472 Implement split_at_spare_mut without Deref to a slice so that the spare slice is valid ~I'm not sure I understand what's going on here correctly. And I'm pretty sure this safety comment needs to be changed. I'm just referring to the same thing that `as_mut_ptr_range` does.~ (Thanks `@RalfJung` for the guidance and clearing things up) I tried to run https://github.com/rust-lang/miri-test-libstd on alloc with -Zmiri-track-raw-pointers, and got a failure on the test `vec::test_extend_from_within`. I minimized the test failure into this program: ```rust #![feature(vec_split_at_spare)] fn main() { Vec::<i32>::with_capacity(1).split_at_spare_mut(); } ``` The problem is that the existing implementation is actually getting a pointer range where both pointers are derived from the initialized region of the Vec's allocation, but we need the second one to be valid for the region between len and capacity. (thanks Ralf for clearing this up)
Fix double space in pretty printed TryBlock Follow-up to rust-lang#92238 fixing one of the FIXMEs. ```rust macro_rules! repro { ($expr:expr) => { stringify!($expr) }; } fn main() { println!("{}", repro!(try {})); } ``` Before: <code>try {}</code> After: <code>try {}</code> The `head` helper already appends a space: https://github.com/rust-lang/rust/blob/2b67c30bfece00357d5fc09d99b49f21066f04ba/compiler/rustc_ast_pretty/src/pprust/state.rs#L654-L664 so doing `head` followed by `space` resulted in a double space: https://github.com/rust-lang/rust/blob/2b67c30bfece00357d5fc09d99b49f21066f04ba/compiler/rustc_ast_pretty/src/pprust/state.rs#L2241-L2242
Fix whitespace in pretty printed PatKind::Range Follow-up to rust-lang#92238 fixing one of the FIXMEs. ```rust macro_rules! repro { ($pat:pat) => { stringify!($pat) }; } fn main() { println!("{}", repro!(0..=1)); } ``` Before: `0 ..=1` After: `0..=1` The canonical spacing applied by rustfmt has no space after the lower expr. Rustc's parser diagnostics also do not put a space there: https://github.com/rust-lang/rust/blob/df96fb166f59431e3de443835e50d5b8a7a4adb0/compiler/rustc_parse/src/parser/pat.rs#L754
…toyo Sync rustc_codegen_gcc r? `@ghost` cc `@antoyo` `@rustbot` label +A-codegen +A-gcc +T-compiler
[rustc_builtin_macros] add indices to format_foreign::printf::Substitution::Escape Fixes rust-lang#92267. The problem was that the escape string "%%" does not need to appear at the very beginning of the format string, but the iterator implementation assumed that it did. The solution follows the pattern used by `format_foregin::shell::Subtitution::Escape`: https://github.com/rust-lang/rust/blob/8ed935e92dfb09ae388344b12284bf5110cf9265/compiler/rustc_builtin_macros/src/format_foreign.rs#L629
…k-Simulacrum Make tidy check for magic numbers that spell things Remove existing problematic cases. r? `@Mark-Simulacrum`
rustbot
added
T-compiler
|
@bors r+ rollup=never p=7 |
|
📌 Commit 4bd4e27 has been approved by |
bors
added
the
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
|
Finished benchmarking commit (028c6f1): comparison url. Summary: This benchmark run did not return any relevant changes. If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. @rustbot label: -perf-regression |
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:
Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup