Always allow rustdoc-json tests to contain long lines
The rustdoc-json test syntax often requires very long lines, so the checks for long lines aren't really useful.
`@aDotInTheVoid` told me she'd like this and
r? jieyouxu
you're gonna tell me that the implementation is terrible. at least the performance seems reasonable: 2.5s after and 2.5s before.
A few cleanups after the removal of `cfg(not(parallel))`
I noticed a few small things that are no longer needed after the removal of `cfg(not(parallel))` in #132282.
One of the later changes adjusts several imports, so viewing the changes individually is recommended.
r? SparrowLii (or reroll)
do not build additional stage on compiler paths
When calling `x build compiler (or rustc) --stage N` bootstrap builds stage N+1 compiler, which is clearly not what we requested. This doesn't happen when running `x build --stage N` without explicitly targeting the compiler.
The changes applied fix this issue.
r? ghost
Fix pretty printing of unsafe binders
We used to render `unsafe<> i32` as `i32`, and `unsafe<'a> &'a i32` as `for<'a> &'a i32`.
r? oli-obk
Review with whitespace b/c adding a new argument changes some the wrapping of some function calls.
Future incompatibility warning `unsupported_fn_ptr_calling_conventions`: Also warn in dependencies
Tracking issue: https://github.com/rust-lang/rust/issues/130260
As discussed [in the previous PR](https://github.com/rust-lang/rust/pull/128784/files#r1752533758) now the future incompatibility warning is enabled in dependencies.
The warning was added in 1.83, while this change will get into stable in 1.86, which gives crate authors three versions to fix the warning.
r? compiler-errors
This was left to only warn in the current crate to give users
a chance to update their code. Now for 1.86 we also warn users
depending on those crates.
Optimize empty provenance range checks.
Currently it gets the pointers in the range and checks if the result is empty, but it can be done faster if you combine those two steps.
r? `@oli-obk`
For consistency with `rustc_lexer::TokenKind::Bang`, and because other
`ast::TokenKind` variants generally have syntactic names instead of
semantic names (e.g. `Star` and `DotDot` instead of `Mul` and `Range`).
`BinOpToken` is badly named, because it only covers the assignable
binary ops and excludes comparisons and `&&`/`||`. Its use in
`ast::TokenKind` does allow a small amount of code sharing, but it's a
clumsy factoring.
This commit removes `ast::TokenKind::BinOp{,Eq}`, replacing each one
with 10 individual variants. This makes `ast::TokenKind` more similar to
`rustc_lexer::TokenKind`, which has individual variants for all
operators.
Although the number of lines of code increases, the number of chars
decreases due to the frequent use of shorter names like `token::Plus`
instead of `token::BinOp(BinOpToken::Plus)`.
`name()` and `trimmed_name()` for `stable_mir::crate_def::DefId`
Resolves https://github.com/rust-lang/project-stable-mir/issues/91
* Added `stable_mir::crate_def::DefId::name()` and `stable_mir::crate_def::DefId::trimmed_name()` methods
* Changed `CrateDef` and `DefId` `Debug` implementations to use new methods instead of copy-paste call to `Context::def_name`
* Updated docs to avoid duplicating description of what `name` and `trimmed_name` do
Adjust triagebot.toml entries for `rustc_mir_build/src/builder/`
I only just noticed that these paths were silently broken by the renaming of `build` to `builder` in #134365.
This is *possibly* OK to just self-approve, but I would prefer to get a second set of eyes on it just in case.
Disable `f16` on Aarch64 without `neon`
LLVM has crashes at some `half` operations when built with assertions enabled if fp-armv8 is not available [1]. Things seem to usually work, but we are reaching LLVM undefined behavior so this needs to be disabled.
[1]: https://github.com/llvm/llvm-project/issues/129394
improve `simd_select` error message when used with invalid mask type
followup to https://github.com/rust-lang/rust/pull/137828
This PR improves the error message for an invalid `simd_select` mask type, and adds testing for `simd_scatter` and `simd_gather` being used with invalid mask types.
the `simd_masked_load` and `simd_masked_store` intrinsics already generated a better error message:
0c72c0d11a/tests/ui/simd/masked-load-store-build-fail.rs (L24-L37)
r? `@workingjubilee`
doc: update Wasmtime flags
Wasmtime's `--wasm-features` and `--wasi-modules` flags have been renamed since these docs were initially written.
Additionally, from my testing I don't believe `--wasm threads` is needed if `--wasi threads` is passed already.
More precisely document `Global::deallocate()`'s safety.
There is a subtlety which "other conditions must be upheld by the caller" does not capture: `GlobalAlloc`/`alloc::dealloc()` require that the provided layout will be *equal*, not just that it "fits", the layout used to allocate. This is always true here due to how `allocate()`, `grow()`, and `shrink()` are implemented (they never return a larger allocation than requested), but that is a non-local property of the implementation, so it should be documented explicitly.
r? libs
`@rustbot` label A-allocators
Minor internal comments fix for `BufRead::read_line`
Just a little fix that came up while I was reading through this source code, and had to search for a few minutes to find out what was actually *meant* here.
This field in the server capabilities instructs the client to maintain
the diagnostics received from a `textDocument/diagnostic` pull request
as a separate set from other diagnostics: namely those sent with classic
"push" diagnostics, `textDocument/publishDiagnostic`. rust-analyzer
emits "native" diagnostics (computed by rust-analyzer itself) in pull
diagnostics and separately emits cargo-based diagnostics with push, so
push and pull diagnostics should be different sets. Setting this field
instructs the client to avoid clearing push diagnostics when new pull
diagnostics arrive and vice versa.
