Add missing --set rust.codegen-backends=["gcc"] in the gcc codegen Dockerfile for the core tests
The CI would use cranelift instead of the gcc codegen.
This fixes it and was tested in rust-lang/rust#156964.
r? @Kobzol
cc @GuillaumeGomez
fix breakpoint callback registration in `lldb_batchmode`
We'd been failing to register the callback for a while now, because it couldn't find the specified function. This change imports `lldb_batchmode` and uses the namespaced name of the function.
As an aside, I'm relatively sure this breakpoint callback isn't necessary anymore. Whenever lldb stops at a breakpoint, it updates the selected thread/frame automatically. I don't want to remove it quite yet because I *might* need it for some bookkeeping with the `lldb-repr` directive (and `--bless` behavior)
rustc_on_unimplemented: introduce format specifiers
...as printing options for the annotated item.
See also the test and dev guide prose. This only affects rustc_on_unimplemented, not (yet) the other diagnostic attributes. I plan to do that in some later PR.
```rust
#![feature(rustc_attrs)]
#[rustc_on_unimplemented(
message = "normal: {This}, path: {This:path}, resolved: {This:resolved}"
)]
pub trait Trait<'lifetime, const CONST_GENERIC: usize, A, B> where A: Send {}
```
will do:
```
normal: Trait, path: Trait<'lifetime, CONST_GENERIC, A, B>, resolved: Trait<'_, 6, u8, _>
```
compiletest: sort unexpected and unimportant errors
Sort unexpected errors before printing in tests, this helps inserting annotations manually from bottom to top and searching for errors is a bit simpler.
Output before:
```rust
tests/ui/delegation/explicit-paths.rs:47:9: ERROR: method `foo3` is not a member of trait `Trait` [E0407]
tests/ui/delegation/explicit-paths.rs:48:9: ERROR: method `foo4` is not a member of trait `Trait` [E0407]
tests/ui/delegation/explicit-paths.rs:27:14: ERROR: cannot find function `foo4` in `S` [E0425]
tests/ui/delegation/explicit-paths.rs:37:18: ERROR: cannot find function `foo4` in `F` [E0425]
tests/ui/delegation/explicit-paths.rs:48:18: ERROR: cannot find function `foo4` in `F` [E0425]
tests/ui/delegation/explicit-paths.rs:59:18: ERROR: cannot find function `foo4` in `F` [E0425]
tests/ui/delegation/explicit-paths.rs:67:5: ERROR: conflicting implementations of trait `Trait` for type `S` [E0119]
tests/ui/delegation/explicit-paths.rs:56:36: ERROR: mismatched types [E0308]
tests/ui/delegation/explicit-paths.rs:68:16: ERROR: the trait bound `S2: Trait` is not satisfied [E0277]
tests/ui/delegation/explicit-paths.rs:68:30: ERROR: mismatched types [E0308]
```
Output after:
```rust
tests/ui/delegation/explicit-paths.rs:27:14: ERROR: cannot find function `foo4` in `S` [E0425]
tests/ui/delegation/explicit-paths.rs:37:18: ERROR: cannot find function `foo4` in `F` [E0425]
tests/ui/delegation/explicit-paths.rs:47:9: ERROR: method `foo3` is not a member of trait `Trait` [E0407]
tests/ui/delegation/explicit-paths.rs:48:9: ERROR: method `foo4` is not a member of trait `Trait` [E0407]
tests/ui/delegation/explicit-paths.rs:48:18: ERROR: cannot find function `foo4` in `F` [E0425]
tests/ui/delegation/explicit-paths.rs:56:36: ERROR: mismatched types [E0308]
tests/ui/delegation/explicit-paths.rs:59:18: ERROR: cannot find function `foo4` in `F` [E0425]
tests/ui/delegation/explicit-paths.rs:67:5: ERROR: conflicting implementations of trait `Trait` for type `S` [E0119]
tests/ui/delegation/explicit-paths.rs:68:16: ERROR: the trait bound `S2: Trait` is not satisfied [E0277]
tests/ui/delegation/explicit-paths.rs:68:30: ERROR: mismatched types [E0308]
```
r? @petrochenkov
compiletest: Simplify `//@ needs-asm-mnemonic: ret` to just `//@ needs-asm-ret`
- Simplification of https://github.com/rust-lang/rust/pull/155692.
---
The `needs-asm-mnemonic` directive was very general, but in practice was only being used for `ret`. There are very few other mnemonics that it could plausibly be useful for (e.g. `nop`), because any instruction that requires arguments is probably going to be non-portable.
This PR replaces `needs-asm-mnemonic` with a simpler `needs-asm-ret` directive that uses the same machinery as other simple needs directives.
If we happend to need more mnemonics in the future, we can just add more simple directives as appropriate (e.g. `needs-asm-nop`).
Replace rustfmt code of conduct with link
In rust-lang/rust#65141 we replaced the CoC file and linked the "authoritative source" on the website. I noticed that the rustfmt directory still has the CoC original file.
I *think* for consistency it makes sense to have all of them linked but I'd like to hear from @calebcartwright first :-)
r? @Mark-Simulacrum
The `needs-asm-mnemonic` directive was very general, but in practice was only
being used for `ret`. There are very few other mnemonics that it could
plausibly be useful for (e.g. `nop`), because any instruction that requires
arguments is probably going to be non-portable.
This PR replaces `needs-asm-mnemonic` with a simpler `needs-asm-ret` directive
that uses the same machinery as other simple needs directives.
If we happend to need more mnemonics in the future, we can just add more simple
directives as appropriate (e.g. `needs-asm-nop`).
compiletest: Prepare all simple `//@ needs-*` conditions in advance
This PR makes compiletest check almost all `//@ needs-*` conditions in advance, separate from individual tests or directives. The results of these checks are stored in a prepared hashmap that can then be inspected by individual tests when encountering a needs-* directive.
This is *similar* to how `ignore-*`/`only-*` directives work (as of https://github.com/rust-lang/rust/pull/149470), though currently the two mechanisms don't share code, as they have subtly different requirements.
r? jieyouxu
Fix jump to def link generation on primitive type associated methods
Fixesrust-lang/rust#156707.
Interestingly enough, the inference fails on primitive type, so instead I go around a bit by generating a `PrimitiveType` and then tweak a bit the `href` generation.
r? @fmease
Also emit "Dyn Compatibility" section for traits that *are* dyn compatible
I was using the std docs to check if a trait was dyn compatible, and was very confused that it had no info about dyn compatibility. I had to go look at a trait that I knew for certain was *not* dyn compatible (`Clone`) to verify that we still had the dyn compatibility section, and that its omission meant a trait *was* compatible.
(also removed the "..., so this trait is not object safe" text because it seemed pretty redundant)
r? @fmease
rustfmt: format const trait impls to `const impl` for syntax transition
Because this concerns rustc development (we want this in next beta) so that we can ensure by the next beta rustc can remove the parser support for `impl const Trait`, this PR is made against the r-l/r repo :)
Install additional LLVM DLL on Windows
Fixes https://github.com/rust-lang/rust/issues/155268
The problem is that with shared linking to LLVM lib we have binaries requiring it in `$sysroot/bin` and `$sysroot/lib/rustlib/triple/bin`, but place the DLL only in the first location. On Unix systems rpath would take care of that, but on Windows the required DLL must be next to the binary or be found in PATH.
This PR puts another copy of the library into that second location. The size overhead of such copy compared to static linking is much lower than I anticipated even though I couldn't manage to make bootstrap create hard links.
The sizes without and with `llvm-tools` component:
```
❯ du --summarize -h .rustup/toolchains/{additional-dll,static}*
638M .rustup/toolchains/additional-dll
800M .rustup/toolchains/additional-dll-tools
608M .rustup/toolchains/static-link
1.1G .rustup/toolchains/static-link-tools
```
Statically linked LLD sits at 139M while dynamically linked one is 7.5M + 150M for the libLLVM, so the difference is minor.
Alternatively, we could require that on Windows, binaries located in `$sysroot/lib/rustlib/triple/bin` must always be called with `$sysroot/bin` in the PATH. However, that sounds like something that would require an announcement and some grace period.
[Debug Info] Gracefully handle invalid `String`/`Vec`
Somewhat related to https://github.com/rust-lang/rust/issues/150392.
Currently the handling can throw an exception, which we should absolutely not do. It causes issues with debugger adapters (e.g. CodeLLDB will hang forever. Trying to stop the debugger via vscode's interface causes a CodeLLDB to leak memory constantly until RAM is depleted and the OS starts killing processes). The exception has been replaced with a printed error message and a placeholder value.
Additionally, if a String/Vec is in an "invalid" state due to niche optimization (`capacity >= (1 << 63)`, common with `Option<String>`/`Option<Vec<T>>`), the pointer and length values will be meaningless, but are not guaranteed to be 0'd. The debugger will happily proceed as if they are useful values, and often do things like \<try to read multiple GB of data from the debugee\>.
I added simple checks to ensure that the capacity and length are within bounds, and that the pointer is non-null. If any check fails, the string/vec just acts as if it's empty.
Eventually this problem will be solved on LLDB's end via https://github.com/llvm/llvm-project/pull/188487/ or similar, but preventing issues on our end in the short term will help a lot.
---
try-job: aarch64-apple
Revert tearing changes to `dbg!`
Since the primary change to `dbg!` in rust-lang/rust#149869, we've been chasing a few regressions:
* rust-lang/rust#153850, fixed by rust-lang/rust#154074
* rust-lang/rust#154988, fixed by rust-lang/rust#154994
* rust-lang/rust#155902, proposed fix in rust-lang/rust#155915
We already reverted this once, on beta only to prevent these regressions from shipping in 1.95.
In that most recent PR, we decided that it would be better to revert `dbg!` to its original state everywhere (`main` and 1.96-`beta`), and then we can consider it from scratch later. So here I've reverted the change and its fixes, but kept the regression tests, including the pending one.
cc @joboet @dianne @rust-lang/libs
@rustbot label beta-nominated
[rustdoc] Move `span_map` file to the right folder
This file should at the same level as `highlight.rs` and `macro_expansion.rs` as it doesn't do anything in `render`.
r? @yotamofek
Add support for xray in aarch64 unknown none targets
I am currently working on an embedded project and use the target `aarch64-unknown-none`, which I want to profile.
I found the following compiler flag `-Z instrument-xray` (https://doc.rust-lang.org/unstable-book/compiler-flags/instrument-xray.html) available and I locally built a toolchain that sets the `supports_xray: true` option in `TargetOptions` for `compiler/rustc_target/src/spec/targets/aarch64_unknown_none.rs`.
Using this toolchain in `rustup` I am able to use the instrumentation pass and I verified that the disassembly looks as what I want.
I understand that it isn't available upstream while being supported due to the separate runtime library which has to be linked (e.g., https://www.llvm.org/docs/XRay.html#xray-runtime-library), which is not available for `aarch64-unknown-none`.
I argue that someone who cross-compiles for `aarch64-unknown-none` would be okay with writing a separate runtime library themselves, which I intend to do.
As far as I understood it is not necessarily required to have a runtime library at this point, i.e., the user of this API should link it, e.g., from their `build.rs` file using `cargo::rustc-link-lib=LIB` if there is an XRay LIB available for the respective target, e.g., `clang+llvm-19.1.1-aarch64-linux-gnu/lib/clang/19/lib/aarch64-unknown-linux-gnu/libclang_rt.xray-fdr.a` (which afaik there isn't for `aarch64-unknown-none`) and do "configuration as code" of XRay's options.
It should not be part of the compiler, because the instrumentation and the runtime library are completely decoupled. One can modify the instrumented code by the compiler pass however one wants to, this again pushes me into the direction of telling the developer to bring his own runtime library.
I would like to bring my change that enables this instrumentation back into upstream to facilitate my developer experience.
ci: Add dist-aarch64-freebsd
Add scripts to build the aarch64-unknown-freebsd target in CI.
Implements MCP: https://github.com/rust-lang/compiler-team/issues/961
There is currently the issue of FreeBSD version support. See the following thread for more details:
https://github.com/rust-lang/rust/pull/132228
The current version supported by rust is FreeBSD 12, which is already EOL. This means it is no longer possible to download FreeBSD releases from their servers. The aarch64 build is not mirrored on the Rust servers, which is why I couldn't match the version used by already existing CI scripts and had to change this one to FreeBSD 13. FreeBSD 13 itself will be EOL a month from now, on April 30th. We might want to put aarch64 FreeBSD builds on the Rust mirror and update the support across the board to FreeBSD 14 prior to merging this.
1. Blocking `connect`s which fail no longer only return EINPROGRESS but
instead return the correct error code.
2. Manually reading SO_ERROR outside of `ensure_connected` no longer
allows the socket to be upgraded to `Connected` despite the `connect`
failing.
3. Introduced new `ConnectionFailed` state to disallow actions on
sockets with a failed `connect`.
bors