loongarch: use "_mcount" as the default mcount symbol
Set the `mcount` field to "_mcount" for all LoongArch targets to match Clang/GCC behavior [1]. This fixes linking failures when using `-Z instrument-mcount`, where the runtime expects "_mcount" instead of "mcount".
[1] https://github.com/llvm/llvm-project/blob/main/clang/lib/Basic/Targets/LoongArch.h#L60
Tweak wording of E0275 WF errors
Modify the main error message to read better:
```
error[E0275]: overflow evaluating whether `&'a mut Bar` is well-formed
```
Make typeck a tcx method which calls typeck_root query
Currently typeck query itself calls `tcx.typeck(tcx.typeck_root_def_id(key))` if its key isn't a type-check root. I thought this might be an overhead and made typeck a tcx method which calls typeck_root query instead.
This is a step to simplify `cache_on_disk_if` query modifier.
@petrochenkov please run perf
simd_fmin/fmax: make semantics and name consistent with scalar intrinsics
This is the SIMD version of https://github.com/rust-lang/rust/pull/153343: change the documented semantics of the SIMD float min/max intrinsics to that of the scalar intrinsics, and also make the name consistent. The overall semantic change this amounts to is that we restrict the non-determinism: the old semantics effectively mean "when one input is an SNaN, the result non-deterministically is a NaN or the other input"; the new semantics say that in this case the other input must be returned. For all other cases, old and new semantics are equivalent. This means all users of these intrinsics that were correct with the old semantics are still correct: the overall set of possible behaviors has become smaller, no new possible behaviors are being added.
In terms of providers of this API:
- Miri, GCC, and cranelift already implement the new semantics, so no changes are needed.
- LLVM is adjusted to use `minimumnum nsz` instead of `minnum`, thus giving us the new semantics.
In terms of consumers of this API:
- Portable SIMD almost certainly wants to match the scalar behavior, so this is strictly a bugfix here.
- Stdarch mostly stopped using the intrinsic, except on nvptx, where arguably the new semantics are closer to what we actually want than the old semantics (https://github.com/rust-lang/stdarch/issues/2056).
Q: Should there be an `f` in the intrinsic name to indicate that it is for floats? E.g., `simd_fminimum_number_nsz`?
Also see https://github.com/rust-lang/rust/issues/153395.
Merge `fabsf16/32/64/128` into `fabs::<F>`
Following [a small conversation on Zulip](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Float.20intrinsics/with/521501401) (and because I'd be interested in starting to contribute on Rust), I thought I'd give a try at merging the float intrinsics :)
This PR just merges `fabsf16`, `fabsf32`, `fabsf64`, `fabsf128`, as it felt like an easy first target.
Notes:
- I'm opening the PR for one intrinsic as it's probably easier if the shift is done one intrinsic at a time, but let me know if you'd rather I do several at a time to reduce the number of PRs.
- Currently this PR increases LOCs, despite being an attempt at simplifying the intrinsics/compilers. I believe this increase is a one time thing as I had to define new functions and move some things around, and hopefully future PRs/commits will reduce overall LoCs
- `fabsf32` and `fabsf64` are `#[rustc_intrinsic_const_stable_indirect]`, while `fabsf16` and `fabsf128` aren't; because `f32`/`f64` expect the function to be const, the generic version must be made indirectly stable too. We'd need to check with T-lang this change is ok; the only other intrinsics where there is such a mismatch is `minnum`, `maxnum` and `copysign`.
- I haven't touched libm because I'm not familiar with how it works; any guidance would be welcome!
resolve: Never lookup glob names in modules from other crates
This is basically rust-lang/rust#151211, but with the check moved one level above and slightly more work skipped.
rust-lang/rust#151211 showed small, but very consistent perf improvements (see "Show non-relevant results"), but I didn't notice back then.
(This change logically falls into my current work on splitting local and external name resolution modules in type system https://github.com/petrochenkov/rust/tree/modmodmod)
EnumSizeOpt: use Allocation::write_scalar instead of manual endianess logic
The first commits makes the test actually show the bytes of the newly generated allocation, so we'd notice if something goes wrong.
The 2nd commit replaces manual endianess handling with use of proper `Allocation` methods.
r? @oli-obk
Emit a pre-expansion feature gate warning for `box`'ed struct field patterns
While the following code triggers a feature gate *warning*:
```rs
fn f() {
#[cfg(false)]
let box x; //~ WARN box pattern syntax is experimental
}
```
the code below does not (on stable & main):
```rs
fn f() {
#[cfg(false)]
let Struct { box x };
}
```
This is an oversight as both are part of the unstable feature `box_patterns` (that isn't properly gated pre expansion for historical reasons). Of course, both forms lead to a feature gate error *post expansion*.
This is a bug fix and doesn't need any input from T-compiler or T-lang. For context, emitting warnings in these cases is legitimized by [MCP 535](https://github.com/rust-lang/compiler-team/issues/535)[^1].
Part of rust-lang/rust#154045.
[^1]: In case you're wondering why the MCP talks about a *lint* even though the feature gate warnings as seen today don't reference any lint by name, read https://github.com/rust-lang/rust/issues/154045#issuecomment-4144034419.
Use the normal arg-parsing machinery for `-Zassert-incr-state`
The flag parser for `-Zassert-incr-state` currently extracts an `Option<String>`, and then performs an ad-hoc parsing step slightly later. From looking at https://github.com/rust-lang/rust/pull/90386, I can't see any reason why it doesn't just use the normal flag-parsing machinery.
A second commit also extracts the underlying implementation to a separate helper function, so that it isn't cluttering up the main control flow.
I found this while working on larger cleanups to incremental-file loading.
Inline and remove `DepGraphData::try_mark_parent_green`.
It has a single call site. And also remove all the `debug!` calls that clutter up the code. The end result is much easier to read, with `try_mark_previous_green` now recursively calling itself directly, instead of indirectly via `try_mark_parent_green`.
r? @oli-obk
interpreter error reporting: remove arguments that are always the same
This `report` function is called twice and both callers use the same `span` and `get_span_and_frames`... so let's just fix those arguments inside the function, no need to be more generic than this.
Rollup of 9 pull requests
Successful merges:
- rust-lang/rust#154357 (uefi: extend comment for TcpStream Send impl)
- rust-lang/rust#154410 (Clean up the API for opening/checking incremental-compilation files )
- rust-lang/rust#154081 (format safety doc of Rc/Arc::from_raw/from_raw_in)
- rust-lang/rust#154110 (Change "error finalizing incremental compilation" text and emit it as a note, not a warning)
- rust-lang/rust#154196 (Make `Ipv6Addr::multicast_scope()` exhaustive)
- rust-lang/rust#154221 (`vec::as_mut_slice()`: use lowercase "isize" in safety comment)
- rust-lang/rust#154234 (Use common Timestamp impl in Hermit (attempt 2))
- rust-lang/rust#154396 (chore(deps): update rust crate tar to v0.4.45)
- rust-lang/rust#154488 (Revert "Unstable book options parser")
Revert "Unstable book options parser"
- Reverts https://github.com/rust-lang/rust/pull/154070
This reverts commit 6fd8466768, reversing changes made to fda6d37bb8.
---
The changes in https://github.com/rust-lang/rust/pull/154070 are well-intentioned, but in their current form they place an unreasonable maintenance burden on the affected part of the compiler, out of proportion to the benefit gained.
- Moving the unstable options to a separate `include!` file is marginally more convenient for the unstable-book-gen tool, but a big hassle for compiler contributors looking to read or modify the list of unstable options. It breaks normal file layout conventions, interferes with navigation, and interferes with IDE features, all without ever being truly necessary.
- The extra `syn`-based parser in unstable-book-gen is quite complicated, almost entirely undocumented, and seemingly buggy. That makes it extremely difficult to understand or modify, which in turn makes it effectively impossible to ever change the `options!` macro on the compiler side.
- The new tests in unstable-book-gen don't appear to be hooked up to run in CI.
- The compiler changes don't appear to have been approved by a T-compiler reviewer.
Before contemplating a revert, I tried to put together a fix-forward to resolve or mitigate some of these issues. But unstable-book-gen in its current state makes that impractical, so unfortunately I believe that the only way forward is to revert the original changes.
---
I do think the reverted functionality is potentially useful, and I'm not fundamentally opposed to a revised version of it landing in the future, if the relevant concerns are addressed.
But I feel strongly that the current version does not justify the real and troublesome maintenance burden that it imposes on compiler contributors.
Clean up the API for opening/checking incremental-compilation files
Returning dedicated structs and enums makes the meaning of each return value more obvious, and provides a more natural home for documentation.
This part of the codebase is fairly crufty, and I doubt anyone feels fully confident about reviewing changes to it, but hopefully these particular cleanups should be fairly straightforward.
I have more changes planned in this area (e.g. cleaning up `LoadResult`), but I stopped here to make review a bit easier.
Avoid ICE in explicit reference cast suggestion for unrelated leaf pr…
Fixesrust-lang/rust#154403
The explicit reference cast suggestion in was enabled based on `main_trait_predicate` being `From`/`TryFrom`, but it then extracted the source type from `leaf_trait_predicate`.
That is only valid when the leaf obligation is also part of the `From`/`TryFrom` conversion family.
Improve doc comment unicode guidance
Fixesrust-lang/rust#153096
This PR does not suggest HTML bidi markup, because doc comments are still Rust source first, not only rendered rustdoc output. HTML only helps in the rendered documentation rather than making them explicit in source.
Unstable book options parser
Parses the `options!` macro in `compiler/rustc_session/src/options.rs` directly to extract the unstable (-Z) compiler flag names and descriptions to generate documentation for the unstable book.
I took notice from the previous attempt which ran `rustc -Zhelp` and parsed the output and used this approach that reads the source directly.
Used claude for the tedious char by char parsing parts but verified the code, I hope that's ok!
Jacob Pratt