Implement the MCP 932: Promote riscv64a23-unknown-linux-gnu to Tier 2
Implement the [MCP 932](https://github.com/rust-lang/compiler-team/issues/932): Promote riscv64a23-unknown-linux-gnu to Tier 2 without host tools.
Closesrust-lang/rust#148353.
Changes:
- Update target tier from 3 to 2 in target specification
- Update platform documentation
- Add CI/CD support for automatic building and distribution via rustup
r? jieyouxu
cc `@davidtwco` `@Noratrieb`
Fix typo in unstable-book link
This prevented the links from being rendered. Sorry for not noticing this before my changes were merged yesterday.
Introduced in https://github.com/rust-lang/rust/pull/147935
cc ``@petrochenkov``
tidy: Don't bypass stderr output capture in unit tests
In unit tests, writes to stderr that don't use `eprint!` or `eprintln!` will not be captured, and instead interfere with test harness output, making it unreadable.
<details>
<summary><b>Detailed before/after</b></summary>
## Before
```text
$ x test tidyselftest --no-doc
Building bootstrap
Finished `dev` profile [unoptimized] target(s) in 0.03s
Testing stage1 tidy (aarch64-apple-darwin)
Compiling tidy v0.1.0 (/Users/stuart/Dev/rust/rust/src/tools/tidy)
Finished `release` profile [optimized + debuginfo] target(s) in 0.23s
Running unittests src/lib.rs (build/aarch64-apple-darwin/bootstrap-tools/aarch64-apple-darwin/release/deps/tidy-c33a0cc08cf46c66)
running 20 tests
tidy [alphabetical-test]: bad:3 found `tidy-alphabetical-start` expecting `tidy-alphabetical-end`
tidy [alphabetical-test]: FAIL
tidy [alphabetical-test]: bad: reached end of file expecting `tidy-alphabetical-end`tidy [alphabetical-test]: bad:4: line not in alphabetical order
tidy [alphabetical-test]: bad:5 found `tidy-alphabetical-end` expecting `tidy-alphabetical-start`
tidy [alphabetical-test]: FAIL
tidy [alphabetical-test]: FAIL
tidy [alphabetical-test].: tidy [alphabetical-test...bad:4: line not in alphabetical order..]: tidy [alphabetical-test]: ..
bad:7: line not in alphabetical order
tidy [tidy [bad:2 found `tidy-alphabetical-end` expecting `tidy-alphabetical-start`
alphabetical-testtidy [tidy [alphabetical-test]: bad:4: line not in alphabetical order
.tidy [alphabetical-test]..]alphabetical-testtidy []: bad:4: line not in alphabetical orderalphabetical-testalphabetical-test]: tidy [FAILalphabetical-test
]: FAIL
]: FAIL
: FAIL
: bad:4: line not in alphabetical order
tidy [alphabetical-test]: FAIL
tidy [.alphabetical-test]: FAIL
.tidy [alphabetical-test]: FAIL
..tidy [alphabetical-test]: bad:3: line not in alphabetical order
tidy [alphabetical-test]: FAIL
tidy [alphabetical-test]: bad:3: line not in alphabetical order
tidy [alphabetical-test]: FAIL
.....
test result: ok. 20 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 1.01ms
Running unittests src/main.rs (build/aarch64-apple-darwin/bootstrap-tools/aarch64-apple-darwin/release/deps/rust_tidy-25232a69af4dd751)
running 0 tests
test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 26.88µs
finished in 0.255 seconds
Build completed successfully in 0:00:00
```
## After
```text
$ x test tidyselftest --no-doc
Building bootstrap
Finished `dev` profile [unoptimized] target(s) in 0.03s
Testing stage1 tidy (aarch64-apple-darwin)
Compiling tidy v0.1.0 (/Users/stuart/Dev/rust/rust/src/tools/tidy)
Finished `release` profile [optimized + debuginfo] target(s) in 1.74s
Running unittests src/lib.rs (build/aarch64-apple-darwin/bootstrap-tools/aarch64-apple-darwin/release/deps/tidy-c33a0cc08cf46c66)
running 20 tests
....................
test result: ok. 20 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 1.35ms
Running unittests src/main.rs (build/aarch64-apple-darwin/bootstrap-tools/aarch64-apple-darwin/release/deps/rust_tidy-25232a69af4dd751)
running 0 tests
test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 27.17µs
finished in 1.764 seconds
Build completed successfully in 0:00:02
```
</details>
bootstrap: Render doctest timing reports as text, not JSON
These doctest timing reports were added to libtest/rustdoc in https://github.com/rust-lang/rust/pull/144909, but bootstrap's custom test-output renderer wasn't taught about them, so they were being printed as raw JSON instead.
Before:
```text
{ "type": "report", "total_time": 0.738403958, "compilation_time": 0.731513292 }
```
After:
```text
all doctests ran in 0.73s; merged doctests compilation took 0.72s
```
<details>
<summary><b>Detailed before/after in context</b></summary>
## Before
```text
$ x test rustc_mir_transform --doc
Building bootstrap
Finished `dev` profile [unoptimized] target(s) in 0.03s
Testing stage1 {rustc_mir_transform} (aarch64-apple-darwin)
Finished `release` profile [optimized + debuginfo] target(s) in 0.12s
Doc-tests rustc_mir_transform
running 19 tests
iiiiiiiiiiii.......
test result: ok. 7 passed; 0 failed; 12 ignored; 0 measured; 0 filtered out; finished in 3.28ms
running 7 tests
iiiiiii
test result: ok. 0 passed; 0 failed; 7 ignored; 0 measured; 0 filtered out; finished in 403.67µs
{ "type": "report", "total_time": 0.738403958, "compilation_time": 0.731513292 }
finished in 1.505 seconds
Build completed successfully in 0:00:01
```
## After
```text
$ x test rustc_mir_transform --doc
Building bootstrap
Finished `dev` profile [unoptimized] target(s) in 0.03s
Testing stage1 {rustc_mir_transform} (aarch64-apple-darwin)
Finished `release` profile [optimized + debuginfo] target(s) in 0.12s
Doc-tests rustc_mir_transform
running 19 tests
iiiiiiiiiiii.......
test result: ok. 7 passed; 0 failed; 12 ignored; 0 measured; 0 filtered out; finished in 3.12ms
running 7 tests
iiiiiii
test result: ok. 0 passed; 0 failed; 7 ignored; 0 measured; 0 filtered out; finished in 395.67µs
all doctests ran in 0.73s; merged doctests compilation took 0.72s
finished in 1.493 seconds
Build completed successfully in 0:00:01
```
</details>
mgca: Finish implementation of `#[type_const]`
tracking issue: rust-lang/rust#132980fixesrust-lang/rust#140729fixesrust-lang/rust#140860
- **Fix `#[type_const]` attribute placement validation**
- **Perform WF-checking on type_const RHS's**
- **Check type_const type is ConstParamTy_ and that RHS matches it**
- **Check that impls of `#[type_const]` consts also have the attr**
r? ```@BoxyUwU```
fix: disable self-contained linker when bootstrap-override-lld is set
Part of rust-lang/rust#148708.
Makes `rust.bootstrap-override-lld` set to `true` or `"external"` disable self-contained linker — actually using linker from one's system.
Remove `#[const_trait]`
Remove `#[const_trait]` since we now have `const trait`. Update all structured diagnostics that still suggested the attribute.
r? ```@rust-lang/project-const-traits```
Encode cfg trace, not its early counterpart to fix cross-crate `doc(auto_cfg)`
Fixesrust-lang/rust#141301.
<details><summary>Rambling about <code>target_feature</code> which I didn't touch here</summary>
Regarding https://github.com/rust-lang/rust/issues/141301#issuecomment-3390100259 (`#[target_feature(enable = …)]` on inlined cross-crate re-exports), it has the same underlying cause (namely, we neither encode `target_feature` nor `AttributeKind::TargetFeature` in the crate metadata). However, I didn't make that change because I first want to experiment with querying `TyCtxt::codegen_fn_attrs` in rustdoc instead which already works cross-crate (and also use to it for reconstructing `no_mangle`, `export_name`, `link_section` to avoid encoding these attributes unnecessarily (basically reverting rust-lang/rust#144050) as suggested in https://github.com/rust-lang/rust/issues/144004#issuecomment-3077725837).
</details>
r? GuillaumeGomez
In unit tests, writes to stderr that don't use `eprint!` or `eprintln!` will
not be captured, and instead interfere with test harness output, making it
unreadable.
Recover `[T: N]` as `[T; N]`
`;` is similar and (keyboard-wise) next to `:`, so a verbose suggestion may help to see the difference.
Parent PR: rust-lang/rust#143905
---
`@rustbot` label +A-parser +A-array +A-diagnostics +A-suggestion-diagnostics +D-papercut
Remove a remnant of `dyn*` from the parser
Follow-up to https://github.com/rust-lang/rust/pull/146664 and https://github.com/rust-lang/rust/pull/143036.
`is_explicit_dyn_type` still checked for `TokenKind::Star` which made no sense now that `dyn*` is no more.
Removing it doesn't represent a functional change and merely affects diagnostics. That's because the check only dictated whether to interpret `dyn` as the start of a trait object type in Rust 2015 (where this identifier is only a *contextual* keyword). However, we would still fail at the `*` later on as it doesn't start a bound.
While at it, I also took the time to clean up in the vicinity.
don't completely reset `HeadUsages`
This is really subtle ☠️ I've actually went and added testing for `search_graph.ignore_candidate_head_usages` to https://github.com/lcnr/search_graph_fuzz now. I should have done that when I originally implemented but didn't quite know how to do so back then.
The search graph is far too subtle to think through it manually. I've added the affected proof tree to https://github.com/rust-lang/trait-system-refactor-initiative/blob/main/notes/next-solver/search-graph/general.md#keeping-provisional-cache-entries-on-rerun. It's
- A
- B
- C (depends on B and gets dropped when rerunning)
- D (does not depend on B so we keep it around when rerunning)
- C (irrevant candidate)
- A
- B
- D
- C (irrevant candidate)
- D
- A
- rerun
- C (use provisional cache entry which doesn't depend on B)
- D (use provisional cache entry which doesn't depend on B)
Fixes the ICE in https://github.com/rust-lang/trait-system-refactor-initiative/issues/246#issuecomment-3497832902. I think this issue is brittle enough that adding that as a test isn't really useful. Any small change to the search graph will prevent it from testing this. We do test this fix via the fuzzer.
r? `````@BoxyUwU`````
Enable std locking functions on AIX
This patch enables the std locking functions on AIX by including AIX on the list of supported targets for the locking functions. Excluding AIX from the std locking functions results to compilation errors such as: ("try_lock() not supported").
Add note for identifier with attempted hygiene violation
Fixesrust-lang/rust#148580
I changed the original test to make sure we are pointing to the right scope.
rustc_builtin_macros: rename bench parameter to avoid collisions with user-defined function names
Resolvesrust-lang/rust#148275 by preventing name collisions in the `#[bench]` macro.
Previously, a user-defined function named "b" could not be benchmarked because
the macro-generated lambda identity collided with the same name. We now generate
the lambda ident as `__bench_<function_name>`, ensuring it is always distinct
from the user’s function.
Because the prefix is applied recursively (e.g. benchmarking `__bench_b`
produces a lambda ident `__bench___bench_b`), there is no possible function
name that can equal its corresponding lambda ident. This guarantees that
the user can safely bench a function of any valid name without risk of
identifier collision.
Modify contributor email entries in .mailmap
This adds mailmap entries for duplicates I found in https://thanks.rust-lang.org/rust/all-time/
If I added an entry for you and it is not correct, then please let me know! See the comments at the start of https://github.com/rust-lang/thanks/blob/master/mailmap/src/lib.rs for understanding these entries.
After this gets into the repo, the thanks page will be regenerated within a day, and your double entries will be merged.
cc ````````@aochagavia````````
cc ````````@fasterthanlime````````
cc ````````@jackh726````````
cc ````````@jakubadamw````````
cc ````````@yaahc````````
cc ````````@jackpot51````````
cc ````````@jonhoo````````
cc ````````@marcoieni````````
cc ````````@onur-ozkan````````
cc ````````@rylev````````
cc ````````@willcrichton````````
cc ````````@yoshuawuyts````````
Fix rust stdlib build failing for VxWorks
Fixesrust-lang/rust#148125.
O_NOFOLLOW is not supported on VxWorks. All the other defines/functions have been added to libc(0cd5032671)
Show packed field alignment in mir_transform_unaligned_packed_ref
Fixesrust-lang/rust#147528
I left the expected padding for the field out of the error message so the message would be the same on all platforms. It also isn't always possible to know the expected alignment, so this makes the message simpler.
[DebugInfo] Fix container types failing to find template args
This is a less pervasive (but also less powerful) alternative to https://github.com/rust-lang/rust/pull/144394.
This change *only* provides benefits to container types on MSVC. The TL;DR is that nodes that don't populate/aren't discoverable in the PDB for various reasons are given an alternate lookup path that generates the nodes by acquiring the base-type via some gross string manipulation and then asking clang for the node it wants (e.g. `"ref$<i32>"` -> `"i32"` -> `target.FindFirstType("i32").GetPointerType()` -> `i32 *`, which is a valid type for the container to use)
The before/afters are the same as in the above PR's `*-msvc` LLDB screenshots. This works as a stopgap while the above PR is evaluated, but I think that PR is still a much better solution.
Add correct suggestion for multi-references for self type in method
Currently the suggestion for this code
```rust
fn main() {}
struct A {
field: i32,
}
impl A {
fn f(&&self) {}
}
```
looks like this, which is incorrect and missleading
```rust
Compiling playground v0.0.1 (/playground)
error: expected one of `!`, `(`, `...`, `..=`, `..`, `::`, `:`, `{`, or `|`, found `)`
--> src/main.rs:8:16
|
8 | fn f(&&self) {}
| ^ expected one of 9 possible tokens
|
= note: anonymous parameters are removed in the 2018 edition (see RFC 1685)
help: explicitly ignore the parameter name
|
8 | fn f(_: &&self) {}
| ++
```
So this fixes it and make more correct suggestions
```rust
error: expected one of `!`, `(`, `...`, `..=`, `..`, `::`, `:`, `{`, or `|`, found `)`
--> /home/gh-Kivooeo/test_/src/main.rs:8:16
|
8 | fn f(&&self) {}
| ^ expected one of 9 possible tokens
|
help: `self` should be `self`, `&self` or `&mut self`, please remove extra references
|
8 - fn f(&&self) {}
8 + fn f(&self) {}
```
Implementation is pretty self-documenting, but if you have suggestions on how to improve this (according to current test, which may be not fully covering all cases, this is works very well) or have some funny edge cases to show, I would appreciate it
r? compiler
Add `overflow_checks` intrinsic
This adds an intrinsic which allows code in a pre-built library to inherit the overflow checks option from a crate depending on it. This enables code in the standard library to explicitly change behavior based on whether `overflow_checks` are enabled, regardless of the setting used when standard library was compiled.
This is very similar to the `ub_checks` intrinsic, and refactors the two to use a common mechanism.
The primary use case for this is to allow the new `RangeFrom` iterator to yield the maximum element before overflowing, as requested [here](https://github.com/rust-lang/rust/issues/125687#issuecomment-2151118208). This PR includes a working `IterRangeFrom` implementation based on this new intrinsic that exhibits the desired behavior.
[Prior discussion on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Ability.20to.20select.20code.20based.20on.20.60overflow_checks.60.3F)
mgca: Add ConstArg representation for const items
tracking issue: rust-lang/rust#132980fixesrust-lang/rust#131046fixesrust-lang/rust#134641
As part of implementing `min_generic_const_args`, we need to distinguish const items that can be used in the type system, such as in associated const equality projections, from const items containing arbitrary const code, which must be kept out of the type system. Specifically, all "type consts" must be either concrete (no generics) or generic with a trivial expression like `N` or a path to another type const item.
To syntactically distinguish these cases, we require, for now at least, that users annotate all type consts with the `#[type_const]` attribute. Then, we validate that the const's right-hand side is indeed eligible to be a type const and represent it differently in the HIR.
We accomplish this representation using a new `ConstItemRhs` enum in the HIR, and a similar but simpler enum in the AST. When `#[type_const]` is **not** applied to a const (e.g. on stable), we represent const item right-hand sides (rhs's) as HIR bodies, like before. However, when the attribute is applied, we instead lower to a `hir::ConstArg`. This syntactically distinguishes between trivial const args (paths) and arbitrary expressions, which are represented using `AnonConst`s. Then in `generics_of`, we can take advantage of the existing machinery to bar the `AnonConst` rhs's from using parent generics.
