Rustc pull update #2244
Merged
Rustc pull update #2244
Conversation
This file contains hidden or 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
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
…,saethlin Target modifiers (special marked options) are recorded in metainfo Target modifiers (special marked options) are recorded in metainfo and compared to be equal in different linked crates. PR for this RFC: rust-lang/rfcs#3716 Option may be marked as `TARGET_MODIFIER`, example: `regparm: Option<u32> = (None, parse_opt_number, [TRACKED TARGET_MODIFIER]`. If an TARGET_MODIFIER-marked option has non-default value, it will be recorded in crate metainfo as a `Vec<TargetModifier>`: ``` pub struct TargetModifier { pub opt: OptionsTargetModifiers, pub value_name: String, } ``` OptionsTargetModifiers is a macro-generated enum. Option value code (for comparison) is generated using `Debug` trait. Error example: ``` error: mixing `-Zregparm` will cause an ABI mismatch in crate `incompatible_regparm` --> $DIR/incompatible_regparm.rs:10:1 | LL | #![crate_type = "lib"] | ^ | = help: the `-Zregparm` flag modifies the ABI so Rust crates compiled with different values of this flag cannot be used together safely = note: `-Zregparm=1` in this crate is incompatible with `-Zregparm=2` in dependency `wrong_regparm` = help: set `-Zregparm=2` in this crate or `-Zregparm=1` in `wrong_regparm` = help: if you are sure this will not cause problems, use `-Cunsafe-allow-abi-mismatch=regparm` to silence this error error: aborting due to 1 previous error ``` `-Cunsafe-allow-abi-mismatch=regparm,reg-struct-return` to disable list of flags.
…oli-obk fix autodiff compile time regression Tries to fix the regression from rust-lang/rust#133429 Tracking: - rust-lang/rust#124509
Add a couple of missing `ensure_sufficient_stacks` r? `@saethlin` I hope you didn't spend time on this already. (I couldn't sleep, opened `check_tail_calls`, there was a single call where it could happen, might as well fix it) This PR adds a couple of missing `ensure_sufficient_stack`s: - one in `check_tail_calls` that prevented the #135709 backport on some targets. - after that was fixed, the test still didn't pass starting at 4MB, so I also added one in `check_unsafety` and that made it pass. I didn't add an `rmake` test purposefully limiting the min stack size on `issue-74564-if-expr-stack-overflow.rs`, but we could if we wanted to. On `apple-aarch64-darwin`, this is enough to make `RUST_MIN_STACK=$((1024*1024*3)) ./x test tests/ui --test-args tests/ui/issues/issue-74564-if-expr-stack-overflow.rs` pass for me locally, and it does stack overflow otherwise.
Explicitly choose x86 softfloat/hardfloat ABI Part of rust-lang/rust#135408: Instead of choosing this based on the target features listed in the target spec, make that choice explicit. All built-in targets are being updated here; custom (JSON-defined) x86 (32bit and 64bit) softfloat targets need to explicitly set `rustc-abi` to `x86-softfloat`.
…enton Display of integers without raw pointers and without overflowing_literals The benchmarks as is measure formatting speed of literals. The first commit `black_box`-es input to simulate runtime speed instead. The second commit replaces `unsafe` pointer optimizations with plain array indices. The performance is equivalent on Apple M1. Needs peer review on Intel. Happy to do the 128-bit version too if such change is welcome.
Add `unchecked_disjoint_bitor` per ACP373 Following the names from libs-api in rust-lang/libs-team#373 (comment) Includes a fallback implementation so this doesn't have to update cg_clif or cg_gcc, and overrides it in cg_llvm to use `or disjoint`, which [is available in LLVM 18](https://releases.llvm.org/18.1.0/docs/LangRef.html#or-instruction) so hopefully we don't need any version checks.
Shard AllocMap Lock This improves performance on many-seed parallel (-Zthreads=32) miri executions from managing to use ~8 cores to using 27-28 cores, which is about the same as what I see with the data structure proposed in rust-lang/rust#136105 - I haven't analyzed but I suspect the sharding might actually work out better if we commonly insert "densely" since sharding would split the cache lines and the OnceVec packs locks close together. Of course, we could do something similar with the bitset lock too. Either way, this seems like a very reasonable starting point that solves the problem ~equally well on what I can test locally. r? `@RalfJung`
Upgrade elsa to the newest version. This was locked to 1.7.1 because of an error in the elsa release process that has since been fixed. Upgrading has the advantage that the elsa code runs properly in miri, at least with tree borrows. This was spawned from rust-lang/rust#135870 (comment)
Avoid calling the layout_of query in lit_to_const We got all the information available locally
rustdoc: run css and html minifier at build instead of runtime This way, adding a bunch of comments to the JS files won't make rustdoc slower. Meant to address rust-lang/rust#136161 (comment)
rustdoc: use ThinVec for generic arg parts This reduces the size of both these args, and of path segments, so should measurably help with memory use.
Use `widening_mul` instead of a separate function A helper function became obsolete after `widening_mul` became available for `u128` values.
github-actions
bot
force-pushed
the
rustc-pull
branch
from
4329965 to
23e9e4b
Compare
tree-wide: parallel: Fully removed all `Lrc`, replaced with `Arc` tree-wide: parallel: Fully removed all `Lrc`, replaced with `Arc` This is continuation of rust-lang/rust#132282 . I'm pretty sure I did everything right. In particular, I searched all occurrences of `Lrc` in submodules and made sure that they don't need replacement. There are other possibilities, through. We can define `enum Lrc<T> { Rc(Rc<T>), Arc(Arc<T>) }`. Or we can make `Lrc` a union and on every clone we can read from special thread-local variable. Or we can add a generic parameter to `Lrc` and, yes, this parameter will be everywhere across all codebase. So, if you think we should take some alternative approach, then don't merge this PR. But if it is decided to stick with `Arc`, then, please, merge. cc "Parallel Rustc Front-end" ( rust-lang/rust#113349 ) r? SparrowLii `@rustbot` label WG-compiler-parallel
Ensure that we never try to monomorphize the upcasting or vtable calls of impossible dyn types Check for impossible obligations in the `dyn Trait` type we're trying to compute its the vtable upcasting and method call slots. r? lcnr
Use short ty string for binop and unop errors ``` error[E0369]: cannot add `(..., ..., ..., ...)` to `(..., ..., ..., ...)` --> $DIR/binop.rs:10:7 | LL | x + x; | - ^ - (..., ..., ..., ...) | | | (..., ..., ..., ...) | = note: the full name for the type has been written to '$TEST_BUILD_DIR/$FILE.long-type-hash.txt' = note: consider using `--verbose` to print the full type name to the console ``` ``` error[E0600]: cannot apply unary operator `!` to type `(..., ..., ..., ...)` --> $DIR/binop.rs:14:5 | LL | !x; | ^^ cannot apply unary operator `!` | = note: the full name for the type has been written to '$TEST_BUILD_DIR/$FILE.long-type-hash.txt' = note: consider using `--verbose` to print the full type name to the console ``` CC #135919.
Simplify some code for lowering THIR patterns I've been playing around with some radically different ways of storing THIR patterns, and while those experiments haven't yet produced a clear win, I have noticed various smaller things in the existing code that can be made a bit nicer. Some of the more significant changes: - With a little bit of extra effort (and thoughtful use of Arc), we can completely remove an entire layer of `'pat` lifetimes from the intermediate data structures used for match lowering. - In several places, lists of THIR patterns were being double-boxed for no apparent reason.
implement `eat_until` leveraging memchr in lexer
Rollup of 7 pull requests
Successful merges:
- #136073 (Always compute coroutine layout for eagerly emitting recursive layout errors)
- #136235 (Pretty print pattern type values with transmute if they don't satisfy their pattern)
- #136311 (Ensure that we never try to monomorphize the upcasting or vtable calls of impossible dyn types)
- #136315 (Use short ty string for binop and unop errors)
- #136393 (Fix accidentally not emitting overflowing literals lints anymore in patterns)
- #136435 (Simplify some code for lowering THIR patterns)
- #136630 (Change two std process tests to not output to std{out,err}, and fix test suite stat reset in bootstrap CI test rendering)
r? `@ghost`
`@rustbot` modify labels: rollup
try-job: aarch64-gnu-debug
Don't install msys2 in CI windows-msvc doesn't need it and windows-gnu [installs its own version](https://github.com/rust-lang/rust/blob/master/src/ci/scripts/install-mingw.sh) try-job: dist-x86_64-msvc try-job: dist-i686-msvc try-job: dist-aarch64-msvc try-job: dist-i686-mingw try-job: dist-x86_64-mingw try-job: dist-x86_64-msvc-alt
Windows: remove readonly files When calling `remove_file`, we shouldn't fail to delete readonly files. As the test makes clear, this make the Windows behaviour consistent with other platforms. This also makes us internally consistent with `remove_dir_all`. try-job: x86_64-msvc-ext1
Allow Rust to use a number of libc filesystem calls This allows Rust on Fuchsia to use a number of function calls from libc: * dirfd * fdatasync * flock with LOCK_EX, LOCK_SH, LOCK_NB, LOCK_UN * fstatat cc #120426 try-job: dist-various-2
Implement `x perf` directly in bootstrap Discussed [here](https://rust-lang.zulipchat.com/#narrow/channel/326414-t-infra.2Fbootstrap/topic/Turning.20.60x.20perf.60.20into.20a.20first.20class.20command). Implementing the command directly in bootstrap let's us correctly build the compiler toolchain based on input arguments (such as include rustdoc in the toolchain [only] when needed), and it also makes the CLI interface nicer. r? ``@onur-ozkan``
Detect (non-raw) borrows of null ZST pointers in CheckNull Fixes #136568. Ensures that we check that borrows of derefs are non-null in the `CheckNull` pass **even if** it's a ZST pointee. I'm actually surprised that this is UB in Miri, but if it's certainly UB, then this PR modifies the null check to be stricter. I couldn't find anywhere in https://doc.rust-lang.org/reference/behavior-considered-undefined.html that discusses this case specifically, but I didn't read it too closely, or perhaps it's just missing a bullet point. On the contrary, if this is actually erroneous UB in Miri, then I'm happy to close this (and perhaps fix the null check in Miri to exclude ZSTs?) On the double contrary, if this is still an "open question", I'm also happy to close this and wait for a decision to be made. r? ``@saethlin`` cc ``@RalfJung`` (perhaps you feel strongly about this change)
…r, r=jieyouxu Pick the max DWARF version when LTO'ing modules with different versions Currently, when rustc compiles code with `-Clto` enabled that was built with different choices for `-Zdwarf-version`, a warning will be reported. It's very easy to observe this by compiling most anything (eg, "hello world") and specifying `-Clto -Zdwarf-version=5` since the standard library is distributed with `-Zdwarf-version=4`. This behavior isn't actually useful for a few reasons: - From observation, LLVM chooses to pick the highest DWARF version anyway after issuing the warning. - Clang specifies that in this case, the max version should be picked without a warning and as a general principle, we want to support x-lang LTO with Clang which implies using the same module flag merge behaviors. - Debuggers need to be able to handle a variety of versions within the same debugging session as you can easily have some parts of a binary (or some dynamic libraries within an application) all compiled with different DWARF versions. This commit changes the module flag merge behavior to match Clang and use the highest version of DWARF. It also adds a test to ensure this behavior is respected in the case of two crates being LTO'd together and adds a test to ensure no warning is printed. Fixes #130041 which fails due to these warnings being printed cc #103057
Rollup of 5 pull requests Successful merges: - #134679 (Windows: remove readonly files) - #136213 (Allow Rust to use a number of libc filesystem calls) - #136530 (Implement `x perf` directly in bootstrap) - #136601 (Detect (non-raw) borrows of null ZST pointers in CheckNull) - #136659 (Pick the max DWARF version when LTO'ing modules with different versions ) r? `@ghost` `@rustbot` modify labels: rollup
Update bootstrap compiler and rustfmt The rustfmt version we previously used formats things differently from what the latest nightly rustfmt does. This causes issues for subtrees that get formatted both in-tree and in their own repo. Updating the rustfmt used in-tree solves those issues. Also bumped the bootstrap compiler as the stage0 update command always updates both at the same time.
github-actions
bot
force-pushed
the
rustc-pull
branch
from
23e9e4b to
26a4c95
Compare
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.
Latest update from rustc.