add unqualified_local_imports lint
This lint helps deal with https://github.com/rust-lang/rustfmt/issues/4709 by having the compiler detect imports of local items that are not syntactically distinguishable from imports from other cates. Making them syntactically distinguishable ensures rustfmt can consistently apply the desired import grouping.
Use contiguous spans for empty_line_after_* suggestion
Replacing an empty span (which an empty line is) with an empty string triggers a debug assertion in rustc. This fixes the debug assertion by using contiguous spans, with the same resulting suggestion.
r? `@Alexendoo`
This unblocks the sync
changelog: none
Rollup of 7 pull requests
Successful merges:
- #129201 (std: implement the `random` feature (alternative version))
- #130536 (bootstrap: Set the dylib path when building books with rustdoc)
- #130551 (Fix `break_last_token`.)
- #130657 (Remove x86_64-fuchsia and aarch64-fuchsia target aliases)
- #130721 (Add more test cases for block-no-opening-brace)
- #130736 (Add rustfmt 2024 reformatting to git blame ignore)
- #130746 (readd `@tgross35` and `@joboet` to the review rotation)
r? `@ghost`
`@rustbot` modify labels: rollup
Replacing an empty span (which an empty line is) with an empty string triggers a
debug assertion in rustc. This fixes the debug assertion by using contiguous
spans, with the same resulting suggestion.
Add rustfmt 2024 reformatting to git blame ignore
https://github.com/rust-lang/rust/pull/130724 essentially reformatted the world, so we should add it to the git blame ignore list.
Tested with `git blame compiler/rustc_abi/src/lib.rs -L1137,1146`. I first thought that I have to ignore the merge commit, but it seems like the actual commit that did the reformatting should be ignored instead.
r? ``@compiler-errors``
Fix `break_last_token`.
It currently doesn't handle the three-char tokens `>>=` and `<<=` correctly. These can be broken twice, resulting in three individual tokens. This is a latent bug that currently doesn't cause any problems, but does cause problems for #124141, because that PR increases the usage of lazy token streams.
r? `@petrochenkov`
bootstrap: Set the dylib path when building books with rustdoc
The library path is needed when the toolchain has been configured with
`[rust] rpath = false`. Otherwise, building the reference book will get
an error when it tries to run rustdoc, like:
rustdoc: error while loading shared libraries: librustc_driver-2ec457c3b8826b72.so
std: implement the `random` feature (alternative version)
Implements the ACP rust-lang/libs-team#393.
This PR is an alternative version of #129120 that replaces `getentropy` with `CCRandomGenerateBytes` (on macOS) and `arc4random_buf` (other BSDs), since that function is not suited for generating large amounts of data and should only be used to seed other CPRNGs. `CCRandomGenerateBytes`/`arc4random_buf` on the other hand is (on modern platforms) just as secure and uses its own, very strong CPRNG (ChaCha20 on the BSDs, AES on macOS) periodically seeded with `getentropy`.
Subtree sync for rustc_codegen_cranelift
The main highlight this time is a fix for a miscompilation of RwLock on macOS. Also a Cranelift update and a couple of extra vendor intrinsics on arm64.
r? `@ghost`
`@rustbot` label +A-codegen +A-cranelift +T-compiler
Build quine-mc_cluskey with `opt-level=3` in dev builds
While doing some profiling I noticed that debug clippy running on the `clippy_lints` crate spends 35s out of 160s in one specific code path of `nonminimal_bool`, which seemed a bit excessive.
I've found that just enabling optimizations for quine-mc_cluskey (used by nonminimal_bool) cuts down the part that took 35s to 3s
While this doesn't really change anything for users, this helps dogfood a bit as it cuts off about half a minute of runtime (in some of my tests, at least).
Something similar was attempted in #10576, however that involved compiling everything in release mode including clippy itself, whereas this only affects a single dependency that's compiled in parallel with something that takes longer so this should hopefully not have a negative impact in any case (and changing clippy doesn't require recompiling that dependency)
changelog: none
Update to LLVM 19.1.0
This is a branch rebase of the submodule, now that LLVM 19.1.0 is final.
Our *only* extra patch right now is the one we're carrying for SGX unwind.
