This PR adds a minimal `triagebot.toml` config to make contributions to
this repository respect upstream rust-lang/rust conventions and avoid
issues when syncing this subtree.
Out-of-tree testing is broken with the most recent update from
rust-lang/rust because it makes `compiler-builtins` depend on `core` by
path, which isn't usually available. In order to enable testing outside
of rust-lang/rust, add a new crate `builtins-shim` that uses the same
source as `compiler-builtins` but drops the `core` dependency. This has
replaced `compiler-builtins` as the workspace member and entrypoint for
tests.
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](https://github.com/rust-lang/rust/pull/109278/commits/af945cb86e03b44a4b6dc4d54ec1424b00a2349e).
Use a consistent ordering for top-level manifest keys, and remove those
that are now redundant (`homapage` isn't supposed to be the same as
`repository`, and `documentation` automatically points to docs.rs now).
After adding tests, the current implementation for fminimum fails when
provided a negative zero and NaN as inputs:
---- math::fminimum_fmaximum_num::tests::fmaximum_num_spec_tests_f64 stdout ----
thread 'math::fminimum_fmaximum_num::tests::fmaximum_num_spec_tests_f64' panicked at libm/src/math/fminimum_fmaximum_num.rs:240:13:
fmaximum_num(-0x0p+0, NaN)
l: NaN (0x7ff8000000000000)
r: -0.0 (0x8000000000000000)
---- math::fminimum_fmaximum_num::tests::fmaximum_num_spec_tests_f32 stdout ----
thread 'math::fminimum_fmaximum_num::tests::fmaximum_num_spec_tests_f32' panicked at libm/src/math/fminimum_fmaximum_num.rs:240:13:
fmaximum_num(-0x0p+0, NaN)
l: NaN (0x7fc00000)
r: -0.0 (0x80000000)
Add more thorough spec tests for these functions and correct the
implementations.
Canonicalization is also moved to a trait method to centralize
documentation about what it does and doesn't do.
So this is funny, the query `tcx.module_children` was top 3 in most
time consuming functions in Clippy, it was being called 24384 times in
tokio. "Unacceptable!" I thought. Digging a bit around, turns out that
`clippy::strlen_on_c_strings` was calling for `get_def_path` via
`match_libc_symbol`. This query pretty-prints things and performs some
analysis.
Yes, we were running early lint checks to see if symbols were from
`libc`.
I don't really trust callgrind when it says I've turn 81 billion
instructions
into like 10 million. So I benchmarked this the good ol' "compiling 20
times
without incr" method and it went from 0.31s-0.45s to 0.25s
constistently.
(Profiled, and "benchmarked") on tokio.
What I can get behind is via `strlen_on_c_strings` changing from 31
million instructions into 76k. 🎉🥳
changelog: [`strlen_on_c_strings`]: Optimize it by 99.75%
Rollup of 6 pull requests
Successful merges:
- rust-lang/rust#138016 (Added `Clone` implementation for `ChunkBy`)
- rust-lang/rust#141162 (refactor `AttributeGate` and `rustc_attr!` to emit notes during feature checking)
- rust-lang/rust#141474 (Add `ParseMode::Diagnostic` and fix multiline spans in diagnostic attribute lints)
- rust-lang/rust#141947 (Specify that "option-like" enums must be `#[repr(Rust)]` to be ABI-compatible with their non-1ZST field.)
- rust-lang/rust#142252 (Improve clarity of `core::sync::atomic` docs about "Considerations" in regards to CAS operations)
- rust-lang/rust#142337 (miri: add flag to suppress float non-determinism)
r? `@ghost`
`@rustbot` modify labels: rollup
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
intrinsics: rename min_align_of to align_of
Now that `pref_align_of` is gone (https://github.com/rust-lang/rust/pull/141803), we can give the intrinsic backing `align_of` its proper name.
r? `@workingjubilee` or `@bjorn3`
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`
Introduce `-Zmacro-stats`
Introduce `-Zmacro-stats`.
It collects data about macro expansions and prints them in a table after expansion finishes. It's very useful for detecting macro bloat, especially for proc macros.
r? `@petrochenkov`
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.
So this is funny, the query `tcx.module_children` was top 3 in most
time consuming functions in Clippy, it was being called 24384 times in
tokio. "Unacceptable!" I thought. Digging a bit around, turns out that
`clippy::strlen_on_c_strings` was calling for `get_def_path` via
`match_libc_symbol`. This query pretty-prints things and performs some
analysis.
Yes, we were running early lint checks to see if symbols were from `libc`.
I don't really trust callgrind when it says I've turn 81 billion instructions
into like 10 million. So I benchmarked this the good ol' "compiling 20 times
without incr" method and it went from 0.31s-0.45s to 0.25s constistently.
(Profiled, and "benchmarked") on tokio.
Closesrust-lang/rust-clippy#14692
The suggestion of `manual_flatten` does not includes the replacement of
`if let` so far despite of `.flatten()` suggestion.
This PR eliminates a redundant `if let`.
changelog: [`manual_flatten`] the suggestion removes `if let`
Rollup of 9 pull requests
Successful merges:
- rust-lang/rust#134536 (Lint on fn pointers comparisons in external macros)
- rust-lang/rust#141069 (Suggest mut when possbile for temporary value dropped while borrowed)
- rust-lang/rust#141934 (resolve: Tweak `private_macro_use` lint to be compatible with upcoming macro prelude changes)
- rust-lang/rust#142034 (Detect method not being present that is present in other tuple types)
- rust-lang/rust#142402 (chore(doctest): Remove redundant blank lines)
- rust-lang/rust#142406 (Note when enum variants shadow an associated function)
- rust-lang/rust#142407 (Remove bootstrap adhoc group)
- rust-lang/rust#142408 (Add myself (WaffleLapkin) to review rotation)
- rust-lang/rust#142418 (Remove lower_arg_ty as all callers were passing `None`)
r? `@ghost`
`@rustbot` modify labels: rollup
```
error: cannot find attribute `empty_helper` in this scope
--> $DIR/derive-helper-legacy-limits.rs:17:3
|
LL | #[empty_helper]
| ^^^^^^^^^^^^
|
help: `empty_helper` is an attribute that can be used by the derive macro `Empty`, you might be missing a `derive` attribute
|
LL + #[derive(Empty)]
LL | struct S2;
|
```
Look at proc-macro attributes when encountering unknown attribute
```
error: cannot find attribute `sede` in this scope
--> src/main.rs:18:7
|
18 | #[sede(untagged)]
| ^^^^
|
help: the derive macros `Serialize` and `Deserialize` accept the similarly named `serde` attribute
|
18 | #[serde(untagged)]
| ~~~~~
error: cannot find attribute `serde` in this scope
--> src/main.rs:12:7
|
12 | #[serde(untagged)]
| ^^^^^
|
= note: `serde` is in scope, but it is a crate, not an attribute
help: `serde` is an attribute that can be used by the derive macros `Serialize` and `Deserialize`, you might be missing a `derive` attribute
|
10 | #[derive(Serialize, Deserialize)]
|
```
