ci: loongarch64: use medium code model to avoid relocation overflows
The LoongArch C/C++ cross toolchain defaults to the `normal` code model, which can cause relocation overflows when linking LLVM after upgrading to verion 22. This change uses the `medium`code model for `loongarch64-linux-gnu` and `loongarch64-linux-musl` builds to avoid these linking errors.
compiletest: show output in debug logging
I had a test I was confused by; the root issue is that `error-pattern` runs before normalization, even though `//~ ERROR` runs after normalization. This logging caught the issue immediately.
Mark desugared range expression spans with DesugaringKind::RangeExpr
This is a prerequisite to removing `QPath::LangItem` (rust-lang/rust#115178) because otherwise there would be no way to detect a range expression in the HIR.
There are some non-obvious Clippy changes so a Clippy team review would be good.
The LoongArch C/C++ cross toolchain defaults to the `normal` code model, which
can cause relocation overflows when linking LLVM after upgrading to verion 22.
This change uses the `medium`code model for `loongarch64-linux-gnu` and
`loongarch64-linux-musl` builds to avoid these linking errors.
Improve source code for `highlight.rs`
I was very bothered by the complexity of this file, in particular the handling of `pending_elems` which was very tricky to follow.
So instead, here comes a more sane approach: the content is store in a stack-like type which handles "levels" of HTML (ie, a macro expansion can contain other HTML tags which can themselves contain other, etc). Making it much simpler to keep track of what's going on.
r? `@lolbinarycat`
compiletest: pass rustdoc mode as param, rather than implicitly
Spun out of https://github.com/rust-lang/rust/pull/142642
In the future, I want the rustdoc-json test suite to invoke rustdoc twice, once with `--output-format=json`, and once with the (not yet implemented) `--output-format=postcard` flag.
Doing that requires being able to explicitly tell the `.document()` function which format to use, rather then implicitly using json in the rustdoc-json suite, and HTML in all others.
r? `@jieyouxu`
CC `@jalil-salame`
Example
---
```rust
fn main() {
let x = Some(1);
let cond = true;
if cond && x.is_som$0e() {}
}
```
**Before this PR**
Assist not applicable
**After this PR**
```rust
fn main() {
let x = Some(1);
let cond = true;
if cond && let Some(${0:x1}) = x {}
}
```
compiletest: Simplify passing arguments to spawned test threads
The current code structure was heavily influenced by wanting to match the libtest executor as closely as possible.
Now that the libtest executor has been removed, we can get rid of some complexity that no longer serves a purpose in the new executor.
---
The renaming of `ShouldPanic` is only semi-related, but I included it here because it's small, and as a separate PR it would have conflicted with this one.
r? jieyouxu
Example
---
```rust
fn f() {
if $0foo.bar() {}
}
```
**Before this PR**
"let" not in completion list
**After this PR**
```rust
fn f() {
if let $1 = $0foo.bar() {}
}
```
compiletest: Add concrete examples for some config/test path fields
Seeing a specific example path can be much more enlightening than trying to figure out what the prose is gesturing towards.
Also, in some cases the existing comments were incorrect or misleading, as demonstrated by the example paths.
The example paths were determined by dumping them directly out of the config with `dbg!`, and then lightly anonymizing them for example purposes.
---
No functional changes.
r? jieyouxu
Remove needs-asm-support directive in tests with explicit targets
The `needs-asm-support` directive checks whether the host architecture supports inline assembly, not the target architecture. For tests that explicitly specify a target via `--target` in their compile-flags, this directive is incorrect and unnecessary.
These tests are cross-compiling to specific targets (like x86_64, arm, aarch64, riscv, etc.) that are already known to have stable asm support. The directive was causing these tests to be incorrectly skipped on hosts that don't support asm, even though the target does.
Tests with explicit targets should rely on `needs-llvm-components` to ensure the appropriate backend is available, rather than checking host asm support.
