setup typos check in CI
This allows to check typos in CI, currently for compiler only (to reduce commit size with fixes). With current setup, exclude list is quite short, so it worth trying?
Also includes commits with actual typo fixes.
MCP: https://github.com/rust-lang/compiler-team/issues/817
typos check currently turned for:
* ./compiler
* ./library
* ./src/bootstrap
* ./src/librustdoc
After merging, PRs which enables checks for other crates (tools) can be implemented too.
Found typos will **not break** other jobs immediately: (tests, building compiler for perf run). Job will be marked as red on completion in ~ 20 secs, so you will not forget to fix it whenever you want, before merging pr.
Check typos: `python x.py test tidy --extra-checks=spellcheck`
Apply typo fixes: `python x.py test tidy --extra-checks=spellcheck:fix` (in case if there only 1 suggestion of each typo)
Current fail in this pr is expected and shows how typo errors emitted. Commit with error will be removed after r+.
Rename `mingw-*` CI jobs to `pr-*`
The name `mingw` confuses people because these CI jobs now do much more than just cross-compile to mingw.
This is basically a find/replace. I chose the name `pr-` because it's job is to do general PR checks,
miri: improve errors for type validity assertion failures
Miri has pretty nice errors for type validity violations, printing which field in the type the problem occurs at and so on.
However, we don't see these errors when using e.g. `mem::zeroed` as that uses `assert_zero_valid` to bail out before Miri can detect the UB.
Similar to what we did with `@saethlin's` UB checks, I think we should disable such language UB checks in Miri so that we can get better error messages. If we go for this we should probably say this in the intrinsic docs as well so that people don't think they can rely on these intrinsics catching anything.
Furthermore, I slightly changed `MaybeUninit::assume_init` so that the `.value` field does not show up in error messages any more.
`@rust-lang/miri` what do you think?
interpret: move the native call preparation logic into Miri
`@nia-e` has to do a bunch of changes to this logic for her native call ptrace work, and it's getting annoying that the logic is split between Miri and rustc. So this moves the logic to Miri, keeping just the generic traversal part in rustc. It is unfortunate that this means we have to expose `get_alloc_raw`/`get_alloc_raw_mut`... I hope the function name is scary enough to reduce the risk of misuse.
r? `@oli-obk`
Add bootstrap check snapshot tests
Split off from https://github.com/rust-lang/rust/pull/143048, so that we get a baseline of how check behaved before we make changes to it. Note that the output of the check snapshot tests is suboptimal in many places, as we're missing information about stages and the build compiler. That will be changed in https://github.com/rust-lang/rust/pull/143048.
r? `@jieyouxu`
Improve CSS for source code block line numbers
Extract some changes from https://github.com/rust-lang/rust/pull/137229 to make the PR smaller (thanks `@yotamofek` for the suggestion!).
r? notriddle
Rollup of 11 pull requests
Successful merges:
- rust-lang/rust#131923 (Derive `Copy` and `Hash` for `IntErrorKind`)
- rust-lang/rust#138340 (Remove some unsized tuple impls now that we don't support unsizing tuples anymore)
- rust-lang/rust#141219 (Change `{Box,Arc,Rc,Weak}::into_raw` to only work with `A = Global`)
- rust-lang/rust#142212 (bootstrap: validate `rust.codegen-backends` & `target.<triple>.codegen-backends`)
- rust-lang/rust#142237 (Detect more cases of unused_parens around types)
- rust-lang/rust#142964 (Attribute rework: a parser for single attributes without arguments)
- rust-lang/rust#143070 (Rewrite `macro_rules!` parser to not use the MBE engine itself)
- rust-lang/rust#143235 (Assemble const bounds via normal item bounds in old solver too)
- rust-lang/rust#143261 (Feed `explicit_predicates_of` instead of `predicates_of`)
- rust-lang/rust#143276 (loop match: handle opaque patterns)
- rust-lang/rust#143306 (Add `track_caller` attributes to trace origin of Clippy lints)
r? `@ghost`
`@rustbot` modify labels: rollup
try-job: aarch64-apple
try-job: x86_64-msvc-1
try-job: x86_64-gnu
try-job: dist-i586-gnu-i586-i686-musl
try-job: test-various
Rollup of 9 pull requests
Successful merges:
- rust-lang/rust#141847 (Explain `TOCTOU` on the top of `std::fs`, and reference it in functions)
- rust-lang/rust#142138 (Add `Vec::into_chunks`)
- rust-lang/rust#142321 (Expose elf abi on ppc64 targets)
- rust-lang/rust#142886 (ci: aarch64-gnu: Stop skipping `panic_abort_doc_tests`)
- rust-lang/rust#143194 (fix bitcast of single-element SIMD vectors)
- rust-lang/rust#143231 (Suggest use another lifetime specifier instead of underscore lifetime)
- rust-lang/rust#143232 ([COMPILETEST-UNTANGLE 3/N] Use "directives" consistently within compiletest)
- rust-lang/rust#143258 (Don't recompute `DisambiguatorState` for every RPITIT in trait definition)
- rust-lang/rust#143274 (ci: support optional jobs)
r? `@ghost`
`@rustbot` modify labels: rollup
Add `track_caller` attributes to trace origin of Clippy lints
This allows the use of `-Z track-diagnostics` to see the origin of Clippy lints emission, as is already the case for lints coming from rustc.
[COMPILETEST-UNTANGLE 3/N] Use "directives" consistently within compiletest
Instead of using *both* "headers" and "directives" within compiletest to refer to the same thing. This of course induces some churn, but it's been bugging me for a while, and I rather do the self-consistency changes now than later.
The first commit tries to be mostly move-only to help per-file git history.
I intend to revisit rustc-dev-guide's testing docs, but I don't want to do it on rust-lang/rust side because it would need syncing and might conflict.
Remove let_chains unstable feature
Per https://github.com/rust-lang/rust/issues/53667#issuecomment-3016742982 (but then I also noticed rust-lang/rust#140722)
This replaces the feature gate with a parser error that says let chains require 2024.
A lot of tests were using the unstable feature. I either added edition:2024 to the test or split out the parts that require 2024.
compiletest has confusingly two terminology to refer to the same concept
-- "headers" and "directives". To make this more self-consistent and
less confusing, stick with "directives" only.
This commit **intentionally** tries to be limited to move-only (modulo
some key usage reference renames) to help git history.
Remove support for `dyn*` from the compiler
This PR removes support for `dyn*` (https://github.com/rust-lang/rust/issues/102425), which are a currently un-RFC'd experiment that was opened a few years ago to explore a component that we thought was necessary for AFIDT (async fn in dyn trait).
It doesn't seem like we are going to need `dyn*` types -- even in an not-exposed-to-the-user way[^1] -- for us to implement AFIDT. Given that AFIDT was the original motivating purpose of `dyn*` types, I don't really see a compelling reason to have to maintain their implementation in the compiler.
[^1]: Compared to, e.g., generators whih are an unstable building block we use to implement stable syntax like `async {}`.
We've learned quite a lot from `dyn*`, but I think at this point its current behavior leads to more questions than answers. For example, `dyn*` support today remains somewhat fragile; it ICEs in many cases where the current "normal" `dyn Trait` types rely on their unsizedness for their vtable-based implementation to be sound I wouldn't be surprised if it's unsound in other ways, though I didn't play around with it too much. See the examples below.
```rust
#![feature(dyn_star)]
trait Foo {
fn hello(self);
}
impl Foo for usize {
fn hello(self) {
println!("hello, world");
}
}
fn main() {
let x: dyn* Foo = 1usize;
x.hello();
}
```
And:
```rust
#![feature(dyn_star)]
trait Trait {
type Out where Self: Sized;
}
fn main() {
let x: <dyn* Trait as Trait>::Out;
}
```
...and probably many more problems having to do with the intersection of dyn-compatibility and `Self: Sized` bounds that I was too lazy to look into like:
* GATs
* Methods with invalid signatures
* Associated consts
Generally, `dyn*` types also end up getting in the way of working with [normal `dyn` types](https://github.com/rust-lang/rust/issues/102425#issuecomment-1712604409) to an extent that IMO outweighs the benefit of experimentation.
I recognize that there are probably other, more creative usages of `dyn*` that are orthogonal to AFIDT. However, I think any work along those lines should first have to think through some of the more fundamental interactions between `dyn*` and dyn-compatibility before we think about reimplementing them in the type system.
---
I'm planning on removing the `DynKind` enum and the `PointerLike` built-in trait from the compiler after this PR lands.
Closesrust-lang/rust#102425.
cc `@eholk` `@rust-lang/lang` `@rust-lang/types`
Closesrust-lang/rust#116979.
Closesrust-lang/rust#119694.
Closesrust-lang/rust#134591.
Closesrust-lang/rust#104800.
Remove `ItemKind::descr` method
Follow-up of rust-lang/rust#143234.
After this PR is merged, it will remain two `descr` methods:
* `hir::GenericArg::descr`
* `hir::AssocItemConstraintKind::descr`
For both these enums, I don't think there is the right equivalent in `hir::DefKind` so unless I missed something, we can't remove these two methods because we can't convert these enums into `hir::DefKind`.
r? `@oli-obk`
Do not enable LLD by default in the dist profile
History of us building & shipping LLD for `dist` builds:
1) We used to unconditionally build & ship LLD in bootstrap
2) This was causing problems for people doing custom `dist` builds (https://rust-lang.zulipchat.com/#narrow/stream/326414-t-infra.2Fbootstrap/topic/MSVC.20Runtime.20mismatch.20when.20building.20LLD)
3) https://github.com/rust-lang/rust/pull/126701 made shipping of LLD optional, but to preserve previous behavior, it forcefully enabled `rust.lld = true` in the `dist` profile by default, and overwrote the default to `false` on our CI for external LLVM builds.
- This also didn't match the documentation of `rust.lld` in `bootstrap.example.toml`, which I previously missed.
4) However, since the external LLVM opt-out was only implemented for our CI, and not for all `dist` users, this started causing issues for people `dist`ing with external LLVM (https://github.com/rust-lang/rust/issues/143076). The problem is that the default shouldn't be "true", but "LLD is enabled when LLVM isn't external", but this is not possible to do only in TOML.
So this PR reverses the behavior. LLD is not enabled by default in `dist` anymore. We switch our CI to *opt into* disting LLD, unless an external LLVM is used. External `dist` users can still opt into enabling LLD, but if they do so while also using external LLVM, they will now get a [hard error](https://github.com/rust-lang/rust/pull/143175).
r? `@jieyouxu`
try-job: `x86_64-mingw*`
try-job: dist-x86_64-linux
Jana Dönszelmann