Rustc pull update #2512
Merged
Rustc pull update #2512
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}
feat: Generate `new` for tuple struct
feat: support folding multiline arg list & fn body in one folding range
minor: Sync from downstream
chore: Cleanup cargo config queries
Implement unstable trait impl This PR allows marking impls of stable trait with stable type as unstable. ## Approach In std/core, an impl can be marked as unstable by annotating it with ``#[unstable_feature_bound(feat_name)]``. This will add a ``ClauseKind::Unstable_Feature(feat_name)`` to the list of predicates in ``predicates_of`` . When an unstable impl's function is called, we will first iterate through all the goals in ``param_env`` to check if there is any ``ClauseKind::UnstableFeature(feat_name)`` in ``param_env``. The existence of ``ClauseKind::Unstable_Feature(feat_name)`` in ``param_env`` means an``#[unstable_feature_bound(feat_name)]`` is present at the call site of the function, so we allow the check to succeed in this case. If ``ClauseKind::UnstableFeature(feat_name)`` does not exist in ``param_env``, we will still allow the check to succeed for either of the cases below: 1. The feature is enabled through ``#[feature(feat_name)]`` outside of std / core. 2. We are in codegen because we may be monomorphizing a body from an upstream crate which had an unstable feature enabled that the downstream crate do not. For the rest of the case, it will fail with ambiguity. ## Limitation In this PR, we do not support: 1. using items that need ``#[unstable_feature_bound]`` within stable APIs 2. annotate main function with ``#[unstable_feature_bound]`` 3. annotate ``#[unstable_feature_bound]`` on items other than free function and impl ## Acknowledgement The design and mentoring are done by `@BoxyUwU`
Only inherit local hash for paths `DefPathHash`, as the counterpart of `DefId` that is stable across compiler invocations, is comprised of 2 parts. The first one is the `StableCrateId`, stable form of `CrateNum`. The second is 64 complementary bits to identify the crate-local definition. The current implementation always hashes the full 128 bits when (1) trying to create a new child `DefPathHash` or (2) hashing a `CrateNum` or a `LocalDefId`. But we only need half that information: `LocalDefId` means that the `StableCrateId` is always the current crate's ; `CrateNum` means that we do not care about the local part. As stable hashing is very hot in the query system, in particular hashing definitions, this is a big deal. We still want the local part to change when the `StableCrateId` changes, to make incr-compilation errors less painful, ie. increase the likelihood that if will magically disappear by changing some code. This PR sprinkles some `#[inline]` attributes on small functions that appeared in profiles.
examples: add `minimal_lsp.rs` and FIFO test script
parse `const trait Trait` r? oli-obk or anyone from project-const-traits cc `@rust-lang/project-const-traits`
Unify `CoroutineWitness` sooner in typeck, and stall coroutine obligations based off of `TypingEnv` * Stall coroutine obligations based off of `TypingMode` in the old solver. * Eagerly assign `TyKind::CoroutineWitness` to the witness arg of coroutines during typeck, rather than deferring them to the end of typeck. r? lcnr This is part of rust-lang/rust#143017.
Add ide-assist, generate single field struct From
`-Zhigher-ranked-assumptions`: Consider WF of coroutine witness when proving outlives assumptions ### TL;DR This PR introduces an unstable flag `-Zhigher-ranked-assumptions` which tests out a new algorithm for dealing with some of the higher-ranked outlives problems that come from auto trait bounds on coroutines. See: * rust-lang/rust#110338 While it doesn't fix all of the issues, it certainly fixed many of them, so I'd like to get this landed so people can test the flag on their own code. ### Background Consider, for example: ```rust use std::future::Future; trait Client { type Connecting<'a>: Future + Send where Self: 'a; fn connect(&self) -> Self::Connecting<'_>; } fn call_connect<C>(c: C) -> impl Future + Send where C: Client + Send + Sync, { async move { c.connect().await } } ``` Due to the fact that we erase the lifetimes in a coroutine, we can think of the interior type of the async block as something like: `exists<'r, 's> { C, &'r C, C::Connecting<'s> }`. The first field is the `c` we capture, the second is the auto-ref that we perform on the call to `.connect()`, and the third is the resulting future we're awaiting at the first and only await point. Note that every region is uniquified differently in the interior types. For the async block to be `Send`, we must prove that both of the interior types are `Send`. First, we have an `exists<'r, 's>` binder, which needs to be instantiated universally since we treat the regions in this binder as *unknown*[^exist]. This gives us two types: `{ &'!r C, C::Connecting<'!s> }`. Proving `&'!r C: Send` is easy due to a [`Send`](https://doc.rust-lang.org/nightly/std/marker/trait.Send.html#impl-Send-for-%26T) impl for references. Proving `C::Connecting<'!s>: Send` can only be done via the item bound, which then requires `C: '!s` to hold (due to the `where Self: 'a` on the associated type definition). Unfortunately, we don't know that `C: '!s` since we stripped away any relationship between the interior type and the param `C`. This leads to a bogus borrow checker error today! ### Approach Coroutine interiors are well-formed by virtue of them being borrow-checked, as long as their callers are invoking their parent functions in a well-formed way, then substitutions should also be well-formed. Therefore, in our example above, we should be able to deduce the assumption that `C: '!s` holds from the well-formedness of the interior type `C::Connecting<'!s>`. This PR introduces the notion of *coroutine assumptions*, which are the outlives assumptions that we can assume hold due to the well-formedness of a coroutine's interior types. These are computed alongside the coroutine types in the `CoroutineWitnessTypes` struct. When we instantiate the binder when proving an auto trait for a coroutine, we instantiate the `CoroutineWitnessTypes` and stash these newly instantiated assumptions in the region storage in the `InferCtxt`. Later on in lexical region resolution or MIR borrowck, we use these registered assumptions to discharge any placeholder outlives obligations that we would otherwise not be able to prove. ### How well does it work? I've added a ton of tests of different reported situations that users have shared on issues like rust-lang/rust#110338, and an (anecdotally) large number of those examples end up working straight out of the box! Some limitations are described below. ### How badly does it not work? The behavior today is quite rudimentary, since we currently discharge the placeholder assumptions pretty early in region resolution. This manifests itself as some limitations on the code that we accept. For example, `tests/ui/async-await/higher-ranked-auto-trait-11.rs` continues to fail. In that test, we must prove that a placeholder is equal to a universal for a param-env candidate to hold when proving an auto trait, e.g. `'!1 = 'a` is required to prove `T: Trait<'!1>` in a param-env that has `T: Trait<'a>`. Unfortunately, at that point in the MIR body, we only know that the placeholder is equal to some body-local existential NLL var `'?2`, which only gets equated to the universal `'a` when being stored into the return local later on in MIR borrowck. This could be fixed by integrating these assumptions into the type outlives machinery in a more first-class way, and delaying things to the end of MIR typeck when we know the full relationship between existential and universal NLL vars. Doing this integration today is quite difficult today. `tests/ui/async-await/higher-ranked-auto-trait-11.rs` fails because we don't compute the full transitive outlives relations between placeholders. In that test, we have in our region assumptions that some `'!1 = '!2` and `'!2 = '!3`, but we must prove `'!1 = '!3`. This can be fixed by computing the set of coroutine outlives assumptions in a more transitive way, or as I mentioned above, integrating these assumptions into the type outlives machinery in a more first-class way, since it's already responsible for the transitive outlives assumptions of universals. ### Moving forward I'm still quite happy with this implementation, and I'd like to land it for testing. I may work on overhauling both the way we compute these coroutine assumptions and also how we deal with the assumptions during (lexical/nll) region checking. But for now, I'd like to give users a chance to try out this new `-Zhigher-ranked-assumptions` flag to uncover more shortcomings. [^exist]: Instantiating this binder with infer regions would be incomplete, since we'd be asking for *some* instantiation of the interior types, not proving something for *all* instantiations of the interior types.
…eLapkin Disable `tests/run-make/mte-ffi` because no CI runners have MTE extensions enabled This PR disables the `tests/run-make/mte-ffi` run-make test because it is (1) broken, and (2) no CI runners have suitable MTE extensions enabled to run it correctly. This test being broken is tracked by rust-lang/rust#141600. The first commit also reverts `mte-ffi` changes introduced in rust-lang/rust#141576, as those fixes potentially changes the meaning of the test. cc ```````@dheaton-arm``````` (as this test was introduced in rust-lang/rust#128384) ### Context In rust-lang/rust#141576 when converting PR CI runners from x86_64 to aarch64 runners, it was noticed that this test failed on `aarch64-gnu-llvm-19-1` but not `aarch64-gnu`. It turns out that: - `aarch64-gnu-llvm-19-1` - Uses `gcc version 14.2.0 (Ubuntu 14.2.0-4ubuntu2)` - Based on `lscpu` output, the hardware that was used for this runner does not have MTE enabled. - `aarch64-gnu` - Uses `gcc version 11.4.0 (Ubuntu 11.4.0-1ubuntu1~22.04)` - Based on `lscpu` output, the hardware that was used for this runner does not have MTE enabled. Based on [this comment](rust-lang/rust#141576 (comment)), it seems like the test *requires* hardware with MTE extensions enabled to run properly (on ARMv8.5 or higher). Furthermore, I believe this test does indeed have mismatched pointer type issues, i.e. ``` bar_string.c: In function ‘main’: bar_string.c:36:9: error: assignment to ‘char *’ from incompatible pointer type ‘unsigned int *’ [-Wincompatible-pointer-types] 36 | ptr = (unsigned int *)((uintptr_t)ptr | 0x1fl << 56); | ^ ``` Which is only exposed by `aarch64-gnu-llvm-19-1` because `aarch64-gnu-llvm-19-1` uses **gcc 14.2.0** whereas `aarch64-gnu` uses **gcc 11.14.0**. ### Details <details> <summary>aarch64-gnu-llvm-19-1</summary> ``` gcc_version: Using built-in specs. COLLECT_GCC=aarch64-linux-gnu-gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/aarch64-linux-gnu/14/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none OFFLOAD_TARGET_DEFAULT=1 Target: aarch64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 14.2.0-4ubuntu2' --with-bugurl=file:///usr/share/doc/gcc-14/README.Bugs --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2,rust --prefix=/usr --with-gcc-major-version-only --program-suffix=-14 --program-prefix=aarch64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/libexec --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-libstdcxx-backtrace --enable-gnu-unique-object --disable-libquadmath --disable-libquadmath-support --enable-plugin --enable-default-pie --with-system-zlib --enable-libphobos-checking=release --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --enable-fix-cortex-a53-843419 --disable-werror --enable-offload-targets=nvptx-none=/build/gcc-14-T7YiXd/gcc-14-14.2.0/debian/tmp-nvptx/usr --enable-offload-defaulted --without-cuda-driver --enable-checking=release --build=aarch64-linux-gnu --host=aarch64-linux-gnu --target=aarch64-linux-gnu --with-build-config=bootstrap-lto-lean --enable-link-serialization=2 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 14.2.0 (Ubuntu 14.2.0-4ubuntu2) lscpu: Architecture: aarch64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 4 On-line CPU(s) list: 0-3 Vendor ID: ARM Model name: Neoverse-N2 Model: 0 Thread(s) per core: 1 Core(s) per socket: 4 Socket(s): 1 Stepping: r0p0 BogoMIPS: 2000.00 Flags: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm jscvt fcma lrcpc dcpop sha3 sm3 sm4 asimddp sha512 sve asimdfhm uscat ilrcpc flagm sb paca pacg dcpodp sve2 sveaes svebitperm svesha3 svesm4 flagm2 frint svei8mm svebf16 i8mm bf16 L1d cache: 256 KiB (4 instances) L1i cache: 256 KiB (4 instances) L2 cache: 4 MiB (4 instances) L3 cache: 128 MiB (1 instance) NUMA node(s): 1 NUMA node0 CPU(s): 0-3 Vulnerability Gather data sampling: Not affected Vulnerability Itlb multihit: Not affected Vulnerability L1tf: Not affected Vulnerability Mds: Not affected Vulnerability Meltdown: Not affected Vulnerability Mmio stale data: Not affected Vulnerability Reg file data sampling: Not affected Vulnerability Retbleed: Not affected Vulnerability Spec rstack overflow: Not affected Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl Vulnerability Spectre v1: Mitigation; __user pointer sanitization Vulnerability Spectre v2: Mitigation; CSV2, BHB Vulnerability Srbds: Not affected Vulnerability Tsx async abort: Not affected ``` </details> <details> <summary>aarch64-gnu</summary> ``` gcc_version: Using built-in specs. COLLECT_GCC=aarch64-linux-gnu-gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/aarch64-linux-gnu/11/lto-wrapper Target: aarch64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 11.4.0-1ubuntu1~22.04' --with-bugurl=file:///usr/share/doc/gcc-11/README.Bugs --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-11 --program-prefix=aarch64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libquadmath --disable-libquadmath-support --enable-plugin --enable-default-pie --with-system-zlib --enable-libphobos-checking=release --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --enable-fix-cortex-a53-843419 --disable-werror --enable-checking=release --build=aarch64-linux-gnu --host=aarch64-linux-gnu --target=aarch64-linux-gnu --with-build-config=bootstrap-lto-lean --enable-link-serialization=2 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 11.4.0 (Ubuntu 11.4.0-1ubuntu1~22.04) lscpu: Architecture: aarch64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 4 On-line CPU(s) list: 0-3 Vendor ID: ARM Model: 0 Thread(s) per core: 1 Core(s) per socket: 4 Socket(s): 1 Stepping: r0p0 BogoMIPS: 2000.00 Flags: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm jscvt fcma lrcpc dcpop sha3 sm3 sm4 asimddp sha512 sve asimdfhm uscat ilrcpc flagm sb paca pacg dcpodp sve2 sveaes svebitperm svesha3 svesm4 flagm2 frint svei8mm svebf16 i8mm bf16 L1d cache: 256 KiB (4 instances) L1i cache: 256 KiB (4 instances) L2 cache: 4 MiB (4 instances) L3 cache: 128 MiB (1 instance) NUMA node(s): 1 NUMA node0 CPU(s): 0-3 Vulnerability Gather data sampling: Not affected Vulnerability Itlb multihit: Not affected Vulnerability L1tf: Not affected Vulnerability Mds: Not affected Vulnerability Meltdown: Not affected Vulnerability Mmio stale data: Not affected Vulnerability Reg file data sampling: Not affected Vulnerability Retbleed: Not affected Vulnerability Spec rstack overflow: Not affected Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl Vulnerability Spectre v1: Mitigation; __user pointer sanitization Vulnerability Spectre v2: Mitigation; CSV2, BHB Vulnerability Srbds: Not affected Vulnerability Tsx async abort: Not affected ``` </details> ### References - https://www.kernel.org/doc/html/v5.10/arm64/memory-tagging-extension.html --- cc ```````@marcoieni``````` as this PR reverts the `tests/run-make/mte-ffi` changes from rust-lang/rust#141576.
Store the type of each GVN value MIR is fully typed, so type information is an integral part of what defines a value. GVN currently tries to circumvent storing types, which creates all sorts of complexities. This PR stores the type along with the enum `Value` when defining a value index. This allows to simplify a lot of code. Fixes rust-lang/rust#128094 Fixes rust-lang/rust#135128 r? ``````@ghost`````` for perf
…errors fix `-Zsanitizer=kcfi` on `#[naked]` functions fixes rust-lang/rust#143266 With `-Zsanitizer=kcfi`, indirect calls happen via generated intermediate shim that forwards the call. The generated shim preserves the attributes of the original, including `#[unsafe(naked)]`. The shim is not a naked function though, and violates its invariants (like having a body that consists of a single `naked_asm!` call). My fix here is to match on the `InstanceKind`, and only use `codegen_naked_asm` when the instance is not a `ReifyShim`. That does beg the question whether there are other `InstanceKind`s that could come up. As far as I can tell the answer is no: calling via `dyn` seems to work find, and `#[track_caller]` is disallowed in combination with `#[naked]`. r? codegen ````@rustbot```` label +A-naked cc ````@maurer```` ````@rcvalle````
Emit warning when there is no space between `-o` and arg Closes rust-lang/rust#142812 `getopt` doesn't seem to have an API to check this, so we have to check the args manually. r? compiler
pass --gc-sections if -Zexport-executable-symbols is enabled and improve tests Exported symbols are added as GC roots in linking, so `--gc-sections` won't hurt `-Zexport-executable-symbols`. Fixes the run-make test to work on Linux. Enable the ui test on more targets. cc rust-lang/rust#84161
Port `#[coverage]` to the new attribute system r? ``````@jdonszelmann``````
constify `Option` methods r? ```````@fee1-dead``````` tracking issue: rust-lang/rust#143956 these unblock making `PartialOrd` and `Ord` const without resorting to inlining some of these at call sites.
…errors Fix false positive double negations with macro invocation This PR fixes false positive double_negations lint when macro expansion has negation and macro caller also has negations. Fix rust-lang/rust#143980
…=clubby789 Boostrap: add warning on `optimize = false` I recently came across a bug that can be traced back to the use of `optimize = false` in `bootstrap.toml` in combination with other settings. Following [this](https://rust-lang.zulipchat.com/#narrow/channel/182449-t-compiler.2Fhelp/topic/Missing.20box-related.20symbols.20with.20panic.20.3D.20'abort'/with/528992909) conversation, this PR adds a warning from `bootstrap` when `optimize = false` is used. I notice that in the same file I edited there are two different styles for warnings (`WARN`, `Warning`). I used `WARNING` because, by happenstance, when testing I got a `WARNING` that I didn't set a change id: let me know if I can unify the styles in the file I edited.
rustc-dev-guide subtree update r? ghost
Copy GCC sources into the build directory even outside CI It takes ~3.5s on my Linux notebook to perform the copy, but it should only be executed when we actually go build GCC, and that will almost certainly take much longer :) So I think it should be fine. At least we won't be polluting the source directory for local builds. Fixes: rust-lang/rust#143986 r? `````@nikic`````
Rollup of 11 pull requests Successful merges: - rust-lang/rust#142300 (Disable `tests/run-make/mte-ffi` because no CI runners have MTE extensions enabled) - rust-lang/rust#143271 (Store the type of each GVN value) - rust-lang/rust#143293 (fix `-Zsanitizer=kcfi` on `#[naked]` functions) - rust-lang/rust#143719 (Emit warning when there is no space between `-o` and arg) - rust-lang/rust#143846 (pass --gc-sections if -Zexport-executable-symbols is enabled and improve tests) - rust-lang/rust#143891 (Port `#[coverage]` to the new attribute system) - rust-lang/rust#143967 (constify `Option` methods) - rust-lang/rust#144008 (Fix false positive double negations with macro invocation) - rust-lang/rust#144010 (Boostrap: add warning on `optimize = false`) - rust-lang/rust#144049 (rustc-dev-guide subtree update) - rust-lang/rust#144056 (Copy GCC sources into the build directory even outside CI) r? `@ghost` `@rustbot` modify labels: rollup
Subtree update of `rust-analyzer` r? `@ghost`
Split-up stability_index query
This PR aims to move deprecation and stability processing away from the monolithic `stability_index` query, and directly implement `lookup_{deprecation,stability,body_stability,const_stability}` queries.
The basic idea is to:
- move per-attribute sanity checks into `check_attr.rs`;
- move attribute compatibility checks into the `MissingStabilityAnnotations` visitor;
- progressively dismantle the `Annotator` visitor and the `stability_index` query.
The first commit contains functional change, and now warns when `#[automatically_derived]` is applied on a non-trait impl block. The other commits should not change visible behaviour.
Perf in rust-lang/rust#143845 (comment) shows small but consistent improvement, except for unused-warnings case. That case being a stress test, I'm leaning towards accepting the regression.
This PR changes `check_attr`, so has a high conflict rate on that file. This should not cause issues for review.
Simplify discriminant codegen for niche-encoded variants which don't wrap across an integer boundary Inspired by rust-lang/rust#139729, this attempts to be a much-simpler and more-localized change while still making a difference. (Specifically, this does not try to solve the problem with select-sinking, leaving that to be fixed by llvm/llvm-project#134024 -- once it gets released -- instead of in rustc's codegen.) What this *does* improve is checking for the variant in a 3+ variant enum when that variant is the type providing the niche. Something like `if let Foo::WithBool(_) = ...` previously compiled to `ugt(add(x, -2), 2)`, which is non-trivial to think about because it's depending on the unsigned wrapping to shift the 0/1 up above 2. With this PR it compiles to just `ult(x, 2)`, which is probably what you'd have written yourself if you were doing it by hand to look for "is this byte a bool?". That's done by leaving most of the codegen alone, but adding a couple new special cases to the `is_niche` check. The default looks at the relative discriminant, but in the common cases where there's no wraparound involved, we can just check the original value, rather than the offsetted one. The first commit just adds some tests, so the best way to see the effect of this change is to look at the second commit and how it updates the test expectations.
Add `ToolTarget` to bootstrap Oh, you thought I'm done with refactoring bootstrap tools? Na-ah, think again! After the failure of rust-lang/rust#143581, `ToolTarget` is back with a vengeance. This time, I implemented the test changes and tool cleanups without forcing these tools to be built with the stage0 compiler. There are still some small wins though, `LlvmBitcodeLinker` now starts at stage 1, and not stage 2. Cargo should also be ported to this new mode, but I'm leaving that for a follow-up PR. Hopefully X-th time's the charm 🤞 r? `@jieyouxu`
…t ok) And introduce two new directives for ui tests: * `run-crash` * `run-fail-or-crash` Normally a `run-fail` ui test like tests that panic shall not be terminated by a signal like `SIGABRT`. So begin having that as a hard requirement. Some of our current tests do terminate by a signal/crash however. Introduce and use `run-crash` for those tests. Note that Windows crashes are not handled by signals but by certain high bits set on the process exit code. Example exit code for crash on Windows: `0xc000001d`. Because of this, we define "crash" on all platforms as "not exit with success and not exit with a regular failure code in the range 1..=127". Some tests behave differently on different targets: * Targets without unwind support will abort (crash) instead of exit with failure code 101 after panicking. As a special case, allow crashes for `run-fail` tests for such targets. * Different sanitizer implementations handle detected memory problems differently. Some abort (crash) the process while others exit with failure code 1. Introduce and use `run-fail-or-crash` for such tests.
…etrochenkov tests: Require `run-fail` ui tests to have an exit code (`SIGABRT` not ok) And introduce two new directives for ui tests: * `run-crash` * `run-fail-or-crash` Normally a `run-fail` ui test like tests that panic shall not be terminated by a signal like `SIGABRT`. So begin having that as a hard requirement. Some of our current tests do terminate by a signal/crash however. Introduce and use `run-crash` for those tests. Note that Windows crashes are not handled by signals but by certain high bits set on the process exit code. Example exit code for crash on Windows: `0xc000001d` (`STATUS_ILLEGAL_INSTRUCTION`). Because of this, we define "crash" on all platforms as "not exit with success and not exit with a regular failure code in the range 1..=127". Some tests behave differently on different targets: * Targets without unwind support will abort (crash) instead of exit with failure code 101 after panicking. As a special case, allow crashes for `run-fail` tests for such targets. * Different sanitizer implementations handle detected memory problems differently. Some abort (crash) the process while others exit with failure code 1. Introduce and use `run-fail-or-crash` for such tests. This adds further (cc rust-lang/rust#142304, rust-lang/rust#142886) protection against the regression in rust-lang/rust#123733 since that bug also manifested as `SIGABRT` in `tests/ui/panics/panic-main.rs` (shown as `Aborted (core dumped)` in the logs attached to that issue, and I have also been able to reproduce this locally). ### TODO - [x] **Q:** what about on Windows? **A:** we'll treat any exit code outside of 1 - 127 as "crashed", and we'll do the same on unix. - [x] test all permutations of actual vs expected **Done:** See rust-lang/rust#143002 (comment). - [x] Handle targets without unwind support - [x] Add `run-fail-or-crash` for some sanitizer tests - [x] remote-test-client. See rust-lang/rust#143448 ### Zulip discussion See https://rust-lang.zulipchat.com/#narrow/channel/122651-general/topic/compiletest.3A.20terminate.20by.20signal.20vs.20exit.20with.20error/with/525611235 try-job: aarch64-apple try-job: x86_64-msvc-1 try-job: x86_64-gnu try-job: dist-i586-gnu-i586-i686-musl try-job: test-various try-job: armhf-gnu
Add `uX::strict_sub_signed` rust-lang/rust#116090 missed `strict_sub_signed`, adding it here. Part of rust-lang/rust#118260. r? ``@m-ou-se``
address clippy formatting nits - int_log10.rs: change top level doc comments to outer - collect.rs: remove empty line after doc comment - clippy fix: markdown indentation for indented items after line break: a markdown list item continued over multiples lines, but those following lines which are part of the same item are not indented - clippy fix: bound in one place: when there is a bound in angle brackets and another bound on the same variable in a where clause
Allow `Rvalue::Repeat` to return true in `rvalue_creates_operand` too The conversation in rust-lang/rust#143502 (comment) made be realize how easy this is to handle, since the only possibilty is ZSTs -- everything else ends up with the destination being `LocalKind::Memory` and thus doesn't call `codegen_rvalue_operand` at all. This gets us perilously close to a world where `rvalue_creates_operand` only ever returns true. (See rust-lang/rust#143860 for more.)
bootstrap: Don't trigger an unnecessary LLVM build from check builds Coming back to r-l/r development after a few weeks away, I found a major regression in my dev workflows: running `x check compiler` (either manually or via rust-analyzer) would have the side-effect of building LLVM, even though that shouldn't be necessary. For my main build directory this would be a minor annoyance, but for my separate rust-analyzer build directory it's a huge problem because it causes a completely separate build of LLVM, which takes a long time and should be completely unnecessary. --- After some investigation, I tracked down the problem to the `can_skip_build` check in this code: https://github.com/rust-lang/rust/blob/3014e79f9c8d5510ea7b3a3b70d171d0948b1e96/src/bootstrap/src/core/build_steps/compile.rs#L1382-L1396 Historically, this would skip the LLVM build for stage 0 check builds. But after the recent stage 0 std redesign and some associated check stage renumbering (e.g. rust-lang/rust#143048), the condition `builder.top_stage == build_stage` is now false, because `top_stage` is 1 (due to the renumbering) but `build_stage` is 0 (because a “stage 1” non-library check build still uses the stage 0 compiler). --- Because this is a critical contributor roadblock for me, I have tried to fix this in a relatively narrow way. It's possible that all of this surrounding logic could be greatly simplified (especially in light of the stage redesign changes), but I didn't want this fix to be held back by scope creep. --- (Zulip thread: https://rust-lang.zulipchat.com/#narrow/channel/326414-t-infra.2Fbootstrap/topic/Bootstrap.20incorrectly.20building.20LLVM.20for.20check.20builds/near/528991035)
…ulacrum bootstrap: Ignore `rust.debuginfo-level-tests` for codegen tests As dicussed in rust-lang/rust#61117 (comment), codegen tests typically depend on the raw LLVM IR output and are sensitive to debuginfo level. So do not apply `rust.debuginfo-level-tests` for codegen tests. Before this commit: $ ./x test --set rust.debuginfo-level-tests=2 tests/codegen --force-rerun test result: FAILED. 654 passed; 136 failed; 75 ignored; 0 measured; 0 filtered out; finished in 3.22s After this commit: $ ./x test --set rust.debuginfo-level-tests=2 tests/codegen --force-rerun NOTE: ignoring `rust.debuginfo-level-tests=2` for codegen tests test result: ok. 790 passed; 0 failed; 75 ignored; 0 measured; 0 filtered out; finished in 3.21s ### Run this in CI? Maybe it will make sense to add this to CI later but I think it is too early to do now before more non-codegen tests work with `rust.debuginfo-level-tests=2`.
Add new `ignore-backends` and `needs-backends` tests annotations Part of rust-lang/compiler-team#891. Next step will be to add these annotations in the files where either the output is different based on the codegen (like `asm` tests) or that are known to fail in the GCC backend. cc `@oli-obk` `@antoyo` r? `@Kobzol`
…fJung Fix `-Ctarget-feature`s getting ignored after `crt-static` The current behaviour introduced by commit a50a3b8e318594c41783294e440d864763e412ef would discard any target features specified after `crt-static` (the only member of `RUSTC_SPECIFIC_FEATURES`). This is because it returned instead of continuing processing the next feature. I wasn't entirely sure how the regression test should look like, but this one should do. If anyone has some suggestions, I'm happy to learn, it's my first test :) I've confirmed that the test fails without the fix on `powerpc64le-unknown-linux-musl` and `x86_64-unknown-linux-gnu`. cc ``@RalfJung``
tests: assembly: cstring-merging: Disable GlobalMerge pass The test relies on LLVM not merging all the globals into one and would currently otherwise fail on powerpc64le. See https://github.com/llvm/llvm-project/blob/release/20.x/llvm/lib/CodeGen/GlobalMerge.cpp and here's the assembly generated prior to disabling the pass: <details> <summary>Expand me</summary> ```asm .abiversion 2 .file "cstring_merging.5aa81ea7b99b31fe-cgu.0" .section .text.cstr,"ax",``@progbits`` .globl cstr .p2align 4 .type cstr,``@function`` cstr: .Lfunc_begin0: .cfi_startproc .Lfunc_gep0: addis 2, 12, .TOC.-.Lfunc_gep0@ha addi 2, 2, .TOC.-.Lfunc_gep0@l .Lfunc_lep0: .localentry cstr, .Lfunc_lep0-.Lfunc_gep0 addis 3, 2, .L_MergedGlobals@toc@ha li 4, 4 addi 3, 3, .L_MergedGlobals@toc@l addi 3, 3, 4 blr .long 0 .quad 0 .Lfunc_end0: .size cstr, .Lfunc_end0-.Lfunc_begin0 .cfi_endproc .section .text.manual_cstr,"ax",``@progbits`` .globl manual_cstr .p2align 4 .type manual_cstr,``@function`` manual_cstr: .Lfunc_begin1: .cfi_startproc .Lfunc_gep1: addis 2, 12, .TOC.-.Lfunc_gep1@ha addi 2, 2, .TOC.-.Lfunc_gep1@l .Lfunc_lep1: .localentry manual_cstr, .Lfunc_lep1-.Lfunc_gep1 addis 3, 2, .L_MergedGlobals@toc@ha li 4, 4 addi 3, 3, .L_MergedGlobals@toc@l addi 3, 3, 8 blr .long 0 .quad 0 .Lfunc_end1: .size manual_cstr, .Lfunc_end1-.Lfunc_begin1 .cfi_endproc .type CSTR,``@object`` .section .data.rel.ro.CSTR,"aw",``@progbits`` .globl CSTR .p2align 3, 0x0 CSTR: .quad .L_MergedGlobals .size CSTR, 8 .type .L_MergedGlobals,``@object`` .section .rodata..L_MergedGlobals,"a",``@progbits`` .L_MergedGlobals: .asciz "foo" .asciz "bar" .asciz "baz" .size .L_MergedGlobals, 12 .set .Lanon.a643e9a6bba67b7953be2b5f96e0e802.0, .L_MergedGlobals .size .Lanon.a643e9a6bba67b7953be2b5f96e0e802.0, 4 .set .Lanon.a643e9a6bba67b7953be2b5f96e0e802.1, .L_MergedGlobals+4 .size .Lanon.a643e9a6bba67b7953be2b5f96e0e802.1, 4 .set .Lanon.a643e9a6bba67b7953be2b5f96e0e802.2, .L_MergedGlobals+8 .size .Lanon.a643e9a6bba67b7953be2b5f96e0e802.2, 4 .ident "rustc version 1.90.0-dev" .section ".note.GNU-stack","",``@progbits`` ``` </details>
…r=RalfJung Give a message with a span on MIR validation error It was handy to get a source+line link for rust-lang/rust#143833, even if it's just to the function and not necessarily to the statement. r? mir
Rollup of 9 pull requests Successful merges: - rust-lang/rust#143282 (Add `uX::strict_sub_signed`) - rust-lang/rust#143423 (address clippy formatting nits) - rust-lang/rust#143720 (Allow `Rvalue::Repeat` to return true in `rvalue_creates_operand` too) - rust-lang/rust#144011 (bootstrap: Don't trigger an unnecessary LLVM build from check builds) - rust-lang/rust#144112 (bootstrap: Ignore `rust.debuginfo-level-tests` for codegen tests) - rust-lang/rust#144125 (Add new `ignore-backends` and `needs-backends` tests annotations) - rust-lang/rust#144143 (Fix `-Ctarget-feature`s getting ignored after `crt-static`) - rust-lang/rust#144150 (tests: assembly: cstring-merging: Disable GlobalMerge pass) - rust-lang/rust#144190 (Give a message with a span on MIR validation error) r? `@ghost` `@rustbot` modify labels: rollup
Weekly `cargo update`
Automation to keep dependencies in `Cargo.lock` current.
r? dep-bumps
The following is the output from `cargo update`:
```txt
compiler & tools dependencies:
Locking 15 packages to latest compatible versions
Updating chrono-tz v0.10.3 -> v0.10.4
Removing chrono-tz-build v0.4.1
Updating clap v4.5.40 -> v4.5.41
Updating clap_builder v4.5.40 -> v4.5.41
Updating clap_derive v4.5.40 -> v4.5.41
Updating crc32fast v1.4.2 -> v1.5.0
Updating derive_setters v0.1.7 -> v0.1.8
Updating libredox v0.1.4 -> v0.1.6
Updating measureme v12.0.1 -> v12.0.3
Removing parse-zoneinfo v0.3.1
Adding phf v0.12.1
Adding phf_shared v0.12.1
Updating rustix v1.0.7 -> v1.0.8
Updating serde_json v1.0.140 -> v1.0.141
Updating sysinfo v0.36.0 -> v0.36.1
Updating wasi-preview1-component-adapter-provider v34.0.1 -> v34.0.2
Updating winnow v0.7.11 -> v0.7.12
note: pass `--verbose` to see 39 unchanged dependencies behind latest
library dependencies:
Locking 0 packages to latest compatible versions
note: pass `--verbose` to see 3 unchanged dependencies behind latest
rustbook dependencies:
Locking 13 packages to latest compatible versions
Updating ammonia v4.1.0 -> v4.1.1
Updating cc v1.2.29 -> v1.2.30
Updating clap v4.5.40 -> v4.5.41
Updating clap_builder v4.5.40 -> v4.5.41
Updating clap_complete v4.5.54 -> v4.5.55
Updating clap_derive v4.5.40 -> v4.5.41
Updating crc32fast v1.4.2 -> v1.5.0
Updating html5ever v0.31.0 -> v0.35.0
Updating markup5ever v0.16.2 -> v0.35.0
Updating match_token v0.1.0 -> v0.35.0
Updating rustix v1.0.7 -> v1.0.8
Updating serde_json v1.0.140 -> v1.0.141
Updating winnow v0.7.11 -> v0.7.12
```
This updates the rust-version file to 460259d14de0274b97b8801e08cb2fe5f16fdac5.
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: 460259d14de0274b97b8801e08cb2fe5f16fdac5 Filtered ref: 599ee17 This merge was created using https://github.com/rust-lang/josh-sync.
|
Thanks for the PR. If you have write access, feel free to merge this PR if it does not need reviews. You can request a review using |
rustbot
added
the
S-waiting-on-review
rustbot
removed
the
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.
Latest update from rustc.