Simplify implementation of Rust intrinsics by using type parameters in the cache
The current implementation of intrinsics have a lot of duplication to handle different overloads of overloaded LLVM intrinsic. This PR uses the **base name and the type parameters** in the cache instead of the full, overloaded name. This has the benefit that `call_intrinsic` doesn't need to provide the full name, rather the type parameters (which is most of the time more available). This uses `LLVMIntrinsicCopyOverloadedName2` to get the overloaded name from the base name and the type parameters, and only uses it to declare the function.
(originally was part of rust-lang/rust#140763, split off later)
`@rustbot` label A-codegen A-LLVM
r? codegen
Rollup of 9 pull requests
Successful merges:
- rust-lang/rust#140593 (Temporary lifetime extension through tuple struct and tuple variant constructors)
- rust-lang/rust#141399 ([rustdoc] Give more information into extracted doctest information)
- rust-lang/rust#141493 (Delegate `<SocketAddr as Debug>` to `ByteStr`)
- rust-lang/rust#141811 (Unimplement unsized_locals)
- rust-lang/rust#142243 (float tests: deduplicate min, max, and rounding tests)
- rust-lang/rust#142464 (variadic functions: remove list of supported ABIs from error)
- rust-lang/rust#142477 (Fix incorrect suggestion when calling an associated type with a type anchor)
- rust-lang/rust#142484 (Remove unneeded lifetime bound from signature of BTreeSet::extract_if)
- rust-lang/rust#142489 (Update the `compiler-builtins` subtree)
r? `@ghost`
`@rustbot` modify labels: rollup
Fix incorrect suggestion when calling an associated type with a type anchor
`sugg_span` here is the span of the call expression.
That span here is the `<Self>::Assoc`, which is exactly what we need here (even though I would expect it to include the arguments, but I guess it doesn't)
r? ``@WaffleLapkin``
One commit with failing tests and one that fixes it for reviewability
closesrust-lang/rust#142473
variadic functions: remove list of supported ABIs from error
I think this list is problematic for multiple reasons:
- It is bound to go out-of-date as it is in a very different place from where we actually define which functions support varagrs (`fn supports_varargs`).
- Many of the ABIs we list only work on some targets; it makes no sense to mention "aapcs" as a possible ABI when building for x86_64. (This led to a lot of confusion in https://github.com/rust-lang/rust/issues/110505 where the author thought they should use "cdecl" and then were promptly told that "cdecl" is not a legal ABI on their target.)
- Typically, when the programmer wrote `extern "foobar"`, it is because they need the "foobar" ABI. It is of little use to tell them that there are other ABIs with which varargs would work.
Cc ``@workingjubilee``
float tests: deduplicate min, max, and rounding tests
Part of https://github.com/rust-lang/rust/issues/141726
Best reviewed commit-by-commit.
- Use `assert_biteq!` in the `mod.rs` tests. This requires some trickery to make shadowing macros with imports work.
- The min, max, minimum, maximum tests in `tests/floats/f*.rs` are entirely subsumed by what we already have in `tests/float/mod.rs`, so I just removed them.
- The rounding tests (floor etc) in `f*.rs` had more test points, so I copied them over. They didn't have `0.5` and `-0.5` though which seem like interesting points in particular regarding the sign of the resulting zero if that's what it sounds to, and they didn't max min/max/inf/nan tests, so this was really a merger of both tests.
r? ``@tgross35``
Unimplement unsized_locals
Implements https://github.com/rust-lang/compiler-team/issues/630
Tracking issue here: https://github.com/rust-lang/rust/issues/111942
Note that this just removes the feature, not the implementation, and does not touch `unsized_fn_params`. This is because it is required to support `Box<dyn FnOnce()>: FnOnce()`.
There may be more that should be removed (possibly in follow up prs)
- the `forget_unsized` function and `forget` intrinsic.
- the `unsized_locals` test directory; I've just fixed up the tests for now
- various codegen support for unsized values and allocas
cc ``@JakobDegen`` ``@oli-obk`` ``@Noratrieb`` ``@programmerjake`` ``@bjorn3``
``@rustbot`` label F-unsized_locals
Fixesrust-lang/rust#79409
[rustdoc] Give more information into extracted doctest information
Follow-up of https://github.com/rust-lang/rust/pull/134531.
This update fragment the doctest code into its sub-parts to give more control to the end users on how they want to use it.
The new JSON looks like this:
```json
{
"format_version":2,
"doctests":[
{
"file":"$DIR/extract-doctests-result.rs",
"line":8,
"doctest_attributes":{
"original":"",
"should_panic":false,
"no_run":false,
"ignore":"None",
"rust":true,
"test_harness":false,
"compile_fail":false,
"standalone_crate":false,
"error_codes":[],
"edition":null,
"added_css_classes":[],
"unknown":[]
},
"original_code":"let x = 12;\nOk(())",
"doctest_code":{
"crate_level":"#![allow(unused)]\n",
"code":"let x = 12;\nOk(())",
"wrapper":{
"before":"fn main() { fn _inner() -> core::result::Result<(), impl core::fmt::Debug> {\n",
"after":"\n} _inner().unwrap() }",
"returns_result":true
}
},
"name":"$DIR/extract-doctests-result.rs - (line 8)"
}
]
}
```
for this doctest:
```rust
let x = 12;
Ok(())
```
With this, I think it matches what you need ``@ojeda?`` If so, once merged I'll update the patch I sent to RfL.
r? ``@aDotInTheVoid``
Temporary lifetime extension through tuple struct and tuple variant constructors
This makes temporary lifetime extension work for tuple struct and tuple variant constructors, such as `Some()`.
Before:
```rust
let a = &temp(); // Extended
let a = Some(&temp()); // Not extended :(
let a = Some { 0: &temp() }; // Extended
```
After:
```rust
let a = &temp(); // Extended
let a = Some(&temp()); // Extended
let a = Some { 0: &temp() }; // Extended
```
So, with this change, this works:
```rust
let a = Some(&String::from("hello")); // New: String lifetime now extended!
println!("{a:?}");
```
Until now, we did not extend through tuple struct/variant constructors (like `Some`), because they are function calls syntactically, and we do not want to extend the String lifetime in:
```rust
let a = some_function(&String::from("hello")); // String not extended!
```
However, it turns out to be very easy to distinguish between regular functions and constructors at the point where we do lifetime extension.
In practice, constructors nearly always use UpperCamelCase while regular functions use lower_snake_case, so it should still be easy to for a human programmer at the call site to see whether something qualifies for lifetime extension or not.
This needs a lang fcp.
---
More examples of what will work after this change:
```rust
let x = Person {
name: "Ferris",
job: Some(&Job { // `Job` now extended!
title: "Chief Rustacean",
organisation: "Acme Ltd.",
}),
};
dbg!(x);
```
```rust
let file = if use_stdout {
None
} else {
Some(&File::create("asdf")?) // `File` now extended!
};
set_logger(file);
```
```rust
use std::path::Component;
let c = Component::Normal(&OsString::from(format!("test-{num}"))); // OsString now extended!
assert_eq!(path.components.first().unwrap(), c);
```
Build rustc with assertions in `dist-alt` jobs
Revival of https://github.com/rust-lang/rust/pull/131077, to check CI times now that we don't do PGO/BOLT anymore on Linux `-alt` builds.
r? `@ghost`
try-job: dist-x86_64-msvc-alt
try-job: dist-x86_64-linux-alt
Look at proc-macro attributes when encountering unknown attribute
```
error: cannot find attribute `sede` in this scope
--> $DIR/missing-derive-2.rs:22:7
|
LL | #[sede(untagged)]
| ^^^^
|
help: the derive macros `Deserialize` and `Serialize` accept the similarly named `serde` attribute
|
LL | #[serde(untagged)]
| +
error: cannot find attribute `serde` in this scope
--> $DIR/missing-derive-2.rs:16:7
|
LL | #[serde(untagged)]
| ^^^^^
|
note: `serde` is imported here, but it is a crate, not an attribute
--> $DIR/missing-derive-2.rs:5:1
|
LL | extern crate serde;
| ^^^^^^^^^^^^^^^^^^^
help: `serde` is an attribute that can be used by the derive macros `Serialize` and `Deserialize`, you might be missing a `derive` attribute
|
LL + #[derive(Serialize, Deserialize)]
LL | enum B {
|
```
Partially address #47608. This PR doesn't find [macros that haven't yet been imported by name](af945cb86e).
Upgrade `object`, `addr2line`, and `unwinding` in the standard library
Object:
0.37.0 is a semver-breaking release but the only breakage is in `elf::R_RISCV_GNU_*` and `pe::IMAGE_WEAK_EXTERN_*` constants, as well as Mach-O dyld. This API is not used by `std`, so we should be fine to upgrade.
This new version also includes functionality for parsing Wasm object files that we may eventually like to make use of.
Changelog: https://github.com/gimli-rs/object/blob/master/CHANGELOG.md#0370
Addr2line:
0.25.0 is a breaking change only because it upgrades the `gimli` version. It also includes a change to the `compiler-builtins` dependency that helps with [1].
Changelog: https://github.com/gimli-rs/addr2line/blob/master/CHANGELOG.md#0250-20250611
[1]: https://github.com/rust-lang/rust/issues/142265
Update dependencies in `library/Cargo.lock`
This removes the `compiler_builtins` dependency from a handful of library dependencies, which is progress toward [1].
[1]: https://github.com/rust-lang/rust/issues/142265
assert more in release in `rustc_ast_lowering`
My understanding of the compiler's architecture is that in the `ast_lowering` crate, we are constructing the HIR as a one-time thing per crate. This is after tokenizing, parsing, resolution, expansion, possible reparsing, reresolution, reexpansion, and so on. In other words, there are many reasons that perf-focused PRs spend a lot of time touching `rustc_parse`, `rustc_expand`, `rustc_ast`, and then `rustc_hir` and "onwards", but `ast_lowering` is a little bit of an odd duck.
In this crate, we have a number of debug assertions. Some are clearly expensive checks that seem like they are prohibitive to run in actual optimized compiler builds, but then there are a number that are simple asserts on integer equalities, `is_empty`, or the like. I believe we should do some of them even in release builds, because the correctness gain is worth the performance cost: almost zero.
tests: Split dont-shuffle-bswaps along opt-levels and arches
This duplicates dont-shuffle-bswaps in order to make each opt level its own test. Then -opt3.rs gets split into a revision per arch we want to test, with certain architectures gaining new target-cpu minimums.
add `extern "custom"` functions
tracking issue: rust-lang/rust#140829
previous discussion: https://github.com/rust-lang/rust/issues/140566
In short, an `extern "custom"` function is a function with a custom ABI, that rust does not know about. Therefore, such functions can only be defined with `#[unsafe(naked)]` and `naked_asm!`, or via an `extern "C" { /* ... */ }` block. These functions cannot be called using normal rust syntax: calling them can only be done from inline assembly.
The motivation is low-level scenarios where a custom calling convention is used. Currently, we often pick `extern "C"`, but that is a lie because the function does not actually respect the C calling convention.
At the moment `"custom"` seems to be the name with the most support. That name is not final, but we need to pick something to actually implement this.
r? `@traviscross`
cc `@tgross35`
try-job: x86_64-apple-2
retpoline and retpoline-external-thunk flags (target modifiers) to enable retpoline-related target features
`-Zretpoline` and `-Zretpoline-external-thunk` flags are target modifiers (tracked to be equal in linked crates).
* Enables target features for `-Zretpoline-external-thunk`:
`+retpoline-external-thunk`, `+retpoline-indirect-branches`, `+retpoline-indirect-calls`.
* Enables target features for `-Zretpoline`:
`+retpoline-indirect-branches`, `+retpoline-indirect-calls`.
It corresponds to clang -mretpoline & -mretpoline-external-thunk flags.
Also this PR forbids to specify those target features manually (warning).
Issue: rust-lang/rust#116852
Add bootstrap option to compile a tool with features
Add an option to specify which features to build a tool with, e.g. it will be useful to build Miri with tracing enabled:
```toml
tool-config.miri.features = ["tracing"]
```
See [this Zulip thread](https://rust-lang.zulipchat.com/#narrow/channel/326414-t-infra.2Fbootstrap/topic/Passing.20--features.20to.20Miri.20build.20using.20.2E.2Fx.2Epy/with/523564773) for the options considered. If the final decision will be different than what I wrote now, I will update the code as needed. The reason why the option is `tool-config.miri.features` instead of something like `tool-features.miri` is to possibly allow adding more tool-specific configurations in the future.
I didn't do any validation of the keys of the `tool-config` hashmap, since I saw that no validation is done on the `tools` hashset either.
I don't like much the fact that features can be chosen by various places of the codebase: `Step`s can have some fixed `extra_features`, `prepare_tool_cargo` will add features depending on some bootstrapping options, and the newly added option can also contribute features to tools. However I think it is out of scope of this PR to try to refactor all of that (if it even is refactorable), so I left a comment in the codebase explaining all of the sources of features I could find.
[AIX] strip underlying xcoff object
When stripping, we need to strip the archive member first before archiving. Otherwise, the shared library remain untouched, only the archive symbol table will be modified.
Tracking the old name of renamed unstable library features
This PR resolves the first problem of rust-lang/rust#141617 : tracking renamed unstable features. The first commit is to add a ui test, and the second one tracks the changes. I will comment on the code for clarification.
r? `@jdonszelmann`
There have been a lot of PR's reviewed by you lately, thanks for your time!
cc `@jyn514`
Merge `Cfg::render_long_html` and `Cfg::render_long_plain` methods common code
Follow-up of https://github.com/rust-lang/rust/pull/141747.
Thanks `@camelid` for spotting it!
r? `@camelid`
Implement asymmetrical precedence for closures and jumps
I have been through a series of asymmetrical precedence designs in Syn, and finally have one that I like and is worth backporting into rustc. It is based on just 2 bits of state: `next_operator_can_begin_expr` and `next_operator_can_continue_expr`.
Asymmetrical precedence is the thing that enables `(return 1) + 1` to require parentheses while `1 + return 1` does not, despite `+` always having stronger precedence than `return` [according to the Rust Reference](https://doc.rust-lang.org/1.83.0/reference/expressions.html#expression-precedence). This is facilitated by `next_operator_can_continue_expr`.
Relatedly, it is the thing that enables `(return) - 1` to require parentheses while `return + 1` does not, despite `+` and `-` having exactly the same precedence. This is facilitated by `next_operator_can_begin_expr`.
**Example:**
```rust
macro_rules! repro {
($e:expr) => {
$e - $e;
$e + $e;
};
}
fn main() {
repro!{return}
repro!{return 1}
}
```
`-Zunpretty=expanded` **Before:**
```console
fn main() {
(return) - (return);
(return) + (return);
(return 1) - (return 1);
(return 1) + (return 1);
}
```
**After:**
```console
fn main() {
(return) - return;
return + return;
(return 1) - return 1;
(return 1) + return 1;
}
```
compiler: Ease off the accelerator on `unsupported_calling_conventions`
This is to give us more time to discuss rust-lang/rust#142330 without the ecosystem having an anxiety attack. I have withdrawn `unsupported_calling_conventions` from report-in-deps
I believe we should consider this a simple suspension of the decision in rust-lang/rust#141435 to start this process, rather than a reversal. That is, we may continue with linting again. But I believe we are about to get a... reasonable amount of feedback just from currently available information and should allow ourselves time to process it.
Apply nested goals certainty to `InspectGoals` for normalizes-to
...so that normalizes-to goals don't have `Certainty::Yes` even if they have nested goals which don't hold.
r? lcnr
Faster fmt::Display of 128-bit integers, without unsafe pointer
In followup of #135265, hereby the 128-bit part.
* Batches per 16 instead of 19 digits
* Buffer access as array insteaf of unsafe pointer
* Added test coverage for i128 and u128
r? tgross35 ChrisDenton
feat: Add `bit_width` for unsigned integer types
- Accepted ACP: rust-lang/libs-team#598
- Tracking issue: rust-lang/rust#142326
This PR adds methods to the primitive unsigned integer types that return the minimum number of bits required to represent an unsigned integer.
Implement `//@ needs-target-std` compiletest directive
Closesrust-lang/rust#141863.
Needed to unblock rust-lang/rust#139244 and rust-lang/rust#141856.
### Summary
This PR implements a `//@ needs-target-std` compiletest directive that gates test execution based on whether the target supports std or not. For some cases, this should be preferred over e.g. some combination of `//@ ignore-none`, `//@ ignore-nvptx` and more[^none-limit].
### Implementation limitation
Unfortunately, since there is currently [no reliable way to determine from metadata whether a given target supports std or not](https://github.com/rust-lang/rust/issues/142296), we have to resort to a hack. Bootstrap currently determines whether or not a target supports std by a naive target tuple substring comparison: a target supports std if its target tuple does *not* contain one of `["-none", "nvptx", "switch"]` substrings. This PR simply pulls that hack out into `build_helpers` to avoid reimplementing the same hack in compiletest, and uses that logic to inform `//@ needs-target-std`.
### Auxiliary changes
This PR additionally changes a few run-make tests to use `//@ needs-target-std` over an inconsistent combination of target-based `ignore`s. This should help with rust-lang/rust#139244.
---
r? bootstrap
[^none-limit]: Notably, `target_os = "none"` is **not** a sufficient condition for "target does not support std"
Tshepang Mbambo
bors
Matthias Krüger
Trevor Gross
xizheyin
mejrs
Lukas Wirth
The rustc-dev-guide Cronjob Bot