[pull] master from rust-lang:master #14
Open
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
Rollup of 6 pull requests Successful merges: - #136419 (adding autodiff tests) - #136628 (ci: upgrade to crosstool-ng 1.27.0) - #136681 (resolve `llvm-config` path properly on cross builds) - #136714 (Update `compiler-builtins` to 0.1.146) - #136731 (rustc_middle: parallel: TyCtxt: remove "unsafe impl DynSend/DynSync") - #136791 (Disable DWARF in linker options for i686-unknown-uefi) Failed merges: - #136767 (improve host/cross target checking) r? `@ghost` `@rustbot` modify labels: rollup
We cannot produce anything useful if asked to compile unknown targets. We should handle the error immediately at the point of discovery instead of propagating it upward, and preferably in the simplest way: Die. This allows cleaning up our "error-handling" spread across 5 crates.
This text was placed in the wrong column.
```
error[E0610]: `{integer}` is a primitive type and therefore doesn't have fields
--> $DIR/attempted-access-non-fatal.rs:7:15
|
LL | let _ = 2.l;
| ^
|
help: if intended to be a floating point literal, consider adding a `0` after the period and a `f64` suffix
|
LL - let _ = 2.l;
LL + let _ = 2.0f64;
|
```
Pointers for variables all need to be in the same address space for
correct compilation. Therefore ensure that even if an `alloca` is
created in a different address space, it is casted to the default
address space before its value is used.
This is necessary for the amdgpu target and others where the default
address space for `alloca`s is not 0.
For example the following code compiles incorrectly when not casting the
address space to the default one:
```rust
fn f(p: *const i8 /* addrspace(0) */) -> *const i8 /* addrspace(0) */ {
let local = 0i8; /* addrspace(5) */
let res = if cond { p } else { &raw const local };
res
}
```
results in
```llvm
%local = alloca addrspace(5) i8
%res = alloca addrspace(5) ptr
if:
; Store 64-bit flat pointer
store ptr %p, ptr addrspace(5) %res
else:
; Store 32-bit scratch pointer
store ptr addrspace(5) %local, ptr addrspace(5) %res
ret:
; Load and return 64-bit flat pointer
%res.load = load ptr, ptr addrspace(5) %res
ret ptr %res.load
```
For amdgpu, `addrspace(0)` are 64-bit pointers, `addrspace(5)` are
32-bit pointers.
The above code may store a 32-bit pointer and read it back as a 64-bit
pointer, which is obviously wrong and cannot work. Instead, we need to
`addrspacecast %local to ptr addrspace(0)`, then we store and load the
correct type.
…imulacrum,jieyouxu Always set the deployment target when building std `cc` has [a bug/feature](rust-lang/cc-rs#1171) (I guess depending on how you look at it) where the default deployment target is taken from the SDK instead of from `rustc`. This causes `compiler-builtins` to build `compiler-rt` with the wrong deployment target on iOS. I've been meaning to change how `cc` works in this regard, but that's a lengthy process, so let's fix it in bootstrap for now. The behaviour can be seen locally with `./x build library --set build.optimized-compiler-builtins=true` for various target triples, and then inspecting with `otool -l build/host/stage1/lib/rustlib/*/lib/libcompiler_builtins-*.rlib | rg 'minos|version'`. I have added a rmake test that ensures that we now have the same version everywhere. Fixes #128419 Fixes rust-lang/compiler-builtins#650 Fixes #136523 See also rust-lang/cargo#13115, rust-lang/cc-rs#1171, #136113 See #133092 (comment) for a description of how the change works. try-job: i686-gnu-1 try-job: i686-gnu-2 try-job: x86_64-apple-1 try-job: aarch64-apple try-job: dist-apple-various try-job: dist-aarch64-apple try-job: dist-various-2 try-job: x86_64-fuchsia
… r=compiler-errors Introduce CoercePointeeWellformed for coherence checks at typeck stage Fix #135206 This is the first PR to introduce the "wellformedness" check for `derive(CoercePointee)`. This patch introduces a new error code to cover all the prerequisites of the said macro. The checks that is enforced with this patch is whether the data is indeed `struct` and whether the layout is set to `repr(transparent)`. A following series of patch will arrive later to address the following concern. 1. #135217 so that we would only admit one single coercion on one type parameter, and leave the rest for future consideration in tandem of development of other coercion rules. 1. Enforcement of data field requirements. **An open question** is whether there is a good schema to encode the `#[pointee]` as well, so that we could also check if the `#[pointee]` type parameter is indeed `?Sized`. ``@rustbot`` label F-derive_coerce_pointee
…lacrum Enable sanitizers on MSVC CI jobs Previously MSVC CI would ignore all tests annotated with needs-sanitizer-support header.
Delay bug when method confirmation cannot upcast object pick of self Justification is on the test comment. Simply delays a bug that we were previously ICEing on. cc ``@adetaylor`` since this is a `arbitrary_self_types` ICE.
Prevent generic pattern types from being used in libstd Pattern types should follow the same rules that patterns follow. So a pattern type range must not wrap and not be empty. While we reject such invalid ranges at layout computation time, that only happens during monomorphization in the case of const generics. This is the exact same issue as other const generic math has, and since there's no solution there yet, I put these pattern types behind a separate incomplete feature. These are not necessary for the pattern types MVP (replacing the layout range attributes in libcore and rustc). cc #136574 (new tracking issue for the `generic_pattern_types` feature gate) r? ``@lcnr`` cc ``@scottmcm`` ``@joshtriplett``
…, r=compiler-errors
compiler: gate `extern "{abi}"` in ast_lowering
I don't believe low-level crates like `rustc_abi` should have to know or care about higher-level concerns like whether the ABI string is stable for users. These implementation details can be made less open to public inspection. This way the code that governs stability is near the code that enforces stability, and compiled together.
It also abstracts away certain error messages instead of constantly repeating them.
A few error messages are simply deleted outright, instead of made uniform, because they are either too dated to be useful or redundant with other diagnostic improvements we could make. These can be pursued in followups: my first concern was making sure there wasn't unnecessary diagnostics-related code in `rustc_abi`, which is not well-positioned to understand what kind of errors are going to be generated based on how it is used.
r? ``@ghost``
assign marcoieni and jdno to infra-ci PRs
Update books ## rust-lang/edition-guide 1 commits in f56aecc3b036dff16404b525a83b00f911b9bbea..8dbdda7cae4fa030f09f8f5b63994d4d1dde74b9 2025-02-06 20:06:58 UTC to 2025-02-06 20:06:58 UTC - Correct spelling error in `static-mut-references.md` (rust-lang/edition-guide#358) ## rust-embedded/book 1 commits in ddbf1b4e2858fedb71b7c42eb15c4576517dc125..0b8219ac23a3e09464e4e0166c768cf1c4bba0d5 2025-02-07 08:26:59 UTC to 2025-02-07 08:26:59 UTC - Update gcc toolchain download link for windows (rust-embedded/book#384) ## rust-lang/reference 3 commits in 4249fb411dd27f945e2881eb0378044b94cee06f..de2d5289e45506b11dd652bef4f99de64be70e1c 2025-02-08 22:12:20 UTC to 2025-02-06 19:02:01 UTC - Add trait_upcasting related languages changes (rust-lang/reference#1622) - fixup `»` insertion for rules (rust-lang/reference#1730) - doc `cenum_impl_drop_cast` (rust-lang/reference#1713) ## rust-lang/rust-by-example 2 commits in 743766929f1e53e72fab74394ae259bbfb4a7619..66543bbc5b7dbd4e679092c07ae06ba6c73fd912 2025-02-06 12:38:08 UTC to 2025-02-04 01:46:09 UTC - Add more examples @ drop.md (rust-lang/rust-by-example#1912) - es translation to 3100 (rust-lang/rust-by-example#1911)
Show diff suggestion format on verbose replacement
```
error[E0610]: `{integer}` is a primitive type and therefore doesn't have fields
--> $DIR/attempted-access-non-fatal.rs:7:15
|
LL | let _ = 2.l;
| ^
|
help: if intended to be a floating point literal, consider adding a `0` after the period and a `f64` suffix
|
LL - let _ = 2.l;
LL + let _ = 2.0f64;
|
```
before:
```
error[E0610]: `{integer}` is a primitive type and therefore doesn't have fields
--> $DIR/attempted-access-non-fatal.rs:7:15
|
LL | let _ = 2.l;
| ^
|
help: if intended to be a floating point literal, consider adding a `0` after the period and a `f64` suffix
|
LL + let _ = 2.0f64;
| ~~~~
```
r? `@oli-obk`
The following is a weird pattern for a file within `rustc_middle`:
```
use rustc_middle::aaa;
use crate::bbb;
```
More sensible and standard would be this:
```
use crate::{aaa, bbb};
```
I.e. we generally prefer using `crate::` to using a crate's own name.
(Exceptions are things like in macros where `crate::` doesn't work
because the macro is used in multiple crates.)
This commit fixes a bunch of these weird qualifiers.
rework rigid alias handling Necessary for #136824 if we treat coinductive cycles as errors as we otherwise don't emit an error for ```rust trait Overflow { type Assoc; } impl<T> Overflow for T { type Assoc = <T as Overflow>::Assoc; } ``` The important part is that we only add a `RigidAlias` candidate in cases where the alias is actually supposed to be rigid: - its trait bound has been proven via a `ParamEnv` or `ItemBound` candidate - it's one of the special builtin traits which have a blanket impl with a `default` assoc type This means that we now more explicitly control which aliases should rigid to avoid accidentally accepting cyclic aliases. This requires changes to diagnostics as we no longer enter an explicit `RigidAlias` candidate for `NormalizesTo` goals whose trait bound doesn't hold. To fix this I've modified the `BestObligation` visitor always ignore `RigidAlias` candidates and to instead manually check these requirements if there are no applicable candidates. I also removed the hack for handling `structurally_normalize_ty` failures. This fixes #134905 as we no longer continue to use the `EvalCtxt` even though a nested goal failed. r? ``@compiler-errors``
…=estebank Fix diagnostic when using = instead of : in let binding Fixes #133713 r? ``@estebank``
debuginfo: Set bitwidth appropriately in enum variant tags Previously, we unconditionally set the bitwidth to 128-bits, the largest an enum would possibly be. Then, LLVM would cut down the constant by chopping off leading zeroes before emitting the DWARF. LLVM only supported 64-bit enumerators, so this would also have occasionally resulted in truncated data. LLVM added support for 128-bit enumerators in llvm/llvm-project#125578 That patchset trusts the constant to describe how wide the variant tag is, so the high 64-bits of zeros are considered potentially load-bearing. As a result, we went from emitting tags that looked like: DW_AT_discr_value (0xfe) (because `dwarf::BestForm` selected `data1`) to emitting tags that looked like: DW_AT_discr_value (<0x10> fe ff ff ff 00 00 00 00 00 00 00 00 00 00 00 00 ) This makes the `DW_AT_discr_value` encode at the bitwidth of the tag, which: 1. Is probably closer to our intentions in terms of describing the data. 2. Doesn't invoke the 128-bit support which may not be supported by all debuggers / downstream tools. 3. Will result in smaller debug information.
eagerly prove WF when resolving fully qualified paths fixes rust-lang/trait-system-refactor-initiative#161. This hopefully shouldn't impact perf. I do think we need to deal with at least part of the fallout here, opening for vibes. r? ``@compiler-errors``
Move `llvm.ccache` to `build.ccache` (S)ccache can be useful for more things that just LLVM. For example, we will soon want to use it also for GCC, and theoretically also for building stage0 Rust tools (#136921, https://rust-lang.zulipchat.com/#narrow/channel/242791-t-infra/topic/Using.20sccache.20for.20Rust). r? ``@onur-ozkan``
…GuillaumeGomez rustdoc: use better, consistent SVG icons for scraped examples ## Screenshots     ## Description This continues two ongoing projects - Replacing ascii art with real icons that don't look like syntax, are understandable to people who're familiar with desktop computers and smart devices, and aren't ugly. - Using labels and tooltips to clarify these icons, when the limits of popular iconography hit us. In this case, I've added tooltips, because, unfortunately, there's not room for always-visible labels. r? ``@GuillaumeGomez``
coverage: Eliminate more counters by giving them to unreachable nodes When preparing a function's coverage counters and metadata during codegen, any part of the original coverage graph that was removed by MIR optimizations can be treated as having an execution count of zero. Somewhat counter-intuitively, if we give those unreachable nodes a _higher_ priority for receiving physical counters (instead of counter expressions), that ends up reducing the total number of physical counters needed. This works because if a node is unreachable, we don't actually create a physical counter for it. Instead that node gets a fixed zero counter, and any other node that would have relied on that physical counter in its counter expression can just ignore that term completely.
Compiletest should not inherit all host RUSTFLAGS I told ``@rhelmot`` to do this in #134913. But it's not correct; compiletest shouldn't inherit RUSTFLAGS at all. Pass a single new --host-rustcflags to compiletest instead, without overwriting any existing arguments. Fixes the following failure, which only happens when building llvm from source and then running `x test --stage 1 ui-fulldeps`: ``` diff --git a/tests/ui-fulldeps/fluent-messages/test.stderr b/tests/ui-fulldeps/fluent-messages/test.stderr index 0b3bb14ce51..978ac46c5a2 100644 --- a/tests/ui-fulldeps/fluent-messages/test.stderr +++ b/tests/ui-fulldeps/fluent-messages/test.stderr ``@@`` -1,3 +1,8 ``@@`` +warning[E0602]: unknown lint: `linker_messages` + | + = note: requested on the command line with `-A linker_messages` + = note: `#[warn(unknown_lints)]` on by default ``` See https://rust-lang.zulipchat.com/#narrow/channel/182449-t-compiler.2Fhelp/topic/.E2.9C.94.20unknown.20lint.3A.20.60linker_messages.60.20when.20blessing.20tests.20on.20.2E.2E.2E for more context.
unify LLVM version finding logic kind a self-explanatory
ci: move `x86_64-gnu-debug` job to the free runner try-job: x86_64-gnu-debug
Fix `x test --stage 1 ui-fulldeps` on macOS (until the next beta bump) "stage 1" for fulldeps means "compile with stage 0, link against stage 1". But this code wanted to switch on the compiler that's building, not the compiler that's being tested. Fix the check. Previously, it would fail with a warning about linker-messages: ``` --- stderr ------------------------------- warning[E0602]: unknown lint: `linker_messages` | = note: requested on the command line with `-A linker_messages` = note: `#[warn(unknown_lints)]` on by default ``` cc https://rust-lang.zulipchat.com/#narrow/channel/182449-t-compiler.2Fhelp/topic/unknown.20lint.3A.20.60linker_messages.60.20when.20blessing.20tests.20on.20.2E.2E.2E, #136960
Rollup of 11 pull requests Successful merges: - #136863 (rework rigid alias handling ) - #136869 (Fix diagnostic when using = instead of : in let binding) - #136895 (debuginfo: Set bitwidth appropriately in enum variant tags) - #136928 (eagerly prove WF when resolving fully qualified paths) - #136941 (Move `llvm.ccache` to `build.ccache`) - #136950 (rustdoc: use better, consistent SVG icons for scraped examples) - #136957 (coverage: Eliminate more counters by giving them to unreachable nodes) - #136960 (Compiletest should not inherit all host RUSTFLAGS) - #136962 (unify LLVM version finding logic) - #136970 (ci: move `x86_64-gnu-debug` job to the free runner) - #136973 (Fix `x test --stage 1 ui-fulldeps` on macOS (until the next beta bump)) r? `@ghost` `@rustbot` modify labels: rollup
There's an old note in the code to do this, and now that LLVM-C has an API for it, we might as well.
Make `-O` mean `OptLevel::Aggressive` Implementation of this MCP: rust-lang/compiler-team#828, changing the meaning of `-O` from `-Copt-level=2` to `-Copt-level=3`. This also renames `OptLevel::Default` to `OptLevel::More`, as `Default` no longer makes sense.
…ratrieb Simplify `rustc_span` `analyze_source_file` Simplifies the logic to what the code *actually* does, which is to just record newlines and multibyte characters. Checking for other ASCII control characters is unnecessary because the generic fallback doesn't do anything for those cases. Also uses a simpler (and more efficient) means of iterating the set bits of the mask.
add `IntoBounds` trait for `range_into_bounds` feature Tracking issue: #136903 ACP: rust-lang/libs-team#538
[AIX] expect `EINVAL` for `pthread_mutex_destroy` Calling `pthread_mutex_destory` on a mutex initalized with the static initializer macro `PTHREAD_MUTEX_INITIALIZER` will result in `EINVAL` if the mutex is not lock/unlocked prior to calling `pthread_mutex_destroy`.
Add profiling of bootstrap commands using Chrome events Since we now have support for tracing in bootstrap, and the execution of most commands is centralized within a few functions, it's quite trivial to also trace command execution, and visualize it using the Chrome profiler. This can be helpful both to profile what takes time in bootstrap and also to get a visual idea of what happens in a given bootstrap invocation (since the execution of external commands is usually the most interesting thing). This is how it looks:  I first tried to use [tracing-flame](https://github.com/tokio-rs/tracing/tree/master/tracing-flame), but the output wasn't very useful, because the event/stackframe names were bootstrap code locations, instead of the command contents. r? ``@jieyouxu``
Use the right binder for rebinding `PolyTraitRef` Fixes #136940 I committed a slightly different test which still demonstrates the issue.
ci: switch loongarch jobs to free runners try-job: dist-loongarch64-linux try-job: dist-loongarch64-musl
Update backtrace This updates the backtrace submodule. 6 commits in f8cc6ac9acc4e663ecd96f9bcf1ff4542636d1b9..9d2c34e7e63afe1e71c333b247065e3b7ba4d883 2025-01-04 03:37:47 +0100 to 2025-02-13 14:14:18 -0800 - Various cleanups: rust-lang/backtrace-rs#673 - libunwind: Use builtin _Unwind_GetIP for NuttX on ARM platform: rust-lang/backtrace-rs#692 - remove outdated docs part on Dbghelp::ensure_open: rust-lang/backtrace-rs#696 - Cleanup Windows trace modules: rust-lang/backtrace-rs#697 - Attempt to fix ARM32 Windows: rust-lang/backtrace-rs#685 - Prepare backtrace for Rust 2024: rust-lang/backtrace-rs#700
[cg_llvm] Remove dead error message Part of #135502 Discovered a dead error message in rustc_codegen_llvm, so removing it. r? ``@Zalathar``
Rollup of 9 pull requests Successful merges: - #135439 (Make `-O` mean `OptLevel::Aggressive`) - #136460 (Simplify `rustc_span` `analyze_source_file`) - #136904 (add `IntoBounds` trait) - #136908 ([AIX] expect `EINVAL` for `pthread_mutex_destroy`) - #136924 (Add profiling of bootstrap commands using Chrome events) - #136951 (Use the right binder for rebinding `PolyTraitRef`) - #136981 (ci: switch loongarch jobs to free runners) - #136992 (Update backtrace) - #136993 ([cg_llvm] Remove dead error message) r? `@ghost` `@rustbot` modify labels: rollup
`transmute` should also assume non-null pointers Previously it only did integer-ABI things, but this way it does data pointers too. That gives more information in general to the backend, and allows slightly simplifying one of the helpers in slice iterators.
Set both `nuw` and `nsw` in slice size calculation There's an old note in the code to do this, and now that [LLVM-C has an API for it](https://github.com/llvm/llvm-project/blob/f0b8ff12519270adcfef93410abff76ab073476a/llvm/include/llvm-c/Core.h#L4403-L4408), we might as well. And it's been there since what looks like LLVM 17 llvm/llvm-project@de9b6aa so doesn't even need to be conditional. (There's other places, like `RawVecInner` or `Layout`, that might want to do things like this too, but I'll leave those for a future PR.)
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.
See Commits and Changes for more details.
Created by
pull[bot]
Can you help keep this open source service alive? 💖 Please sponsor : )