Drop compiletest legacy directive check
Sufficient time has passed (> 6 months) since we migrated from `//` to `//`@`,` so let's drop the
legacy directive check as it causes friction due to false positives.
As a side-effect, dropping the legacy directive check simplifies the directive scanning logic.
The legacy directive check was originally added to help people be aware of the migration.
Blocker for #131382 cc `@ehuss.`
Can be reviewed by any compiler/bootstrap reviewer.
[rustdoc] Remove intra-doc links dead code
While working on https://github.com/rust-lang/rust/pull/130278, I wondered what `resolve_display_text` was doing. I removed it and ran all rustdoc tests, and nothing failed. Are some intra-doc links tests missing or is it really dead code? Couldn't figure it out.
r? `@notriddle`
Sufficient time has passed (> 6 months) since we migrated from `//` to
`//@`, so let's drop the legacy directive check as it causes friction
due to false positives.
[Coverage][MCDC] Adapt mcdc to llvm 19
Related issue: #126672
Also finish task 4 at #124144
[llvm #82448](https://github.com/llvm/llvm-project/pull/82448) has introduced some break changes into mcdc, causing incompatibility between llvm 18 and 19. This draft adapts to that change and gives up supporting for llvm-18.
`Deref`/`DerefMut` can be useful, but they can also obfuscate. I don't
think they're worth it for `RegionConstraintCollector`. They're also not
present on the similar types `OpaqueTypeTable` and `TypeVariableTable`.
`LeakCheck` can own `mini_graph` and `rcc` instead of holding references
to them. This requires inlining `assign_scc_value` to avoid a borrowck
error, but that's fine because it has a single call site.
It's a weird method, and used weirdly:
- It's on `RegionConstraintCollector` but operates on
`RegionConstraintStorage`. So at both call sites we create a temporary
`RegionConstraintCollector`, using `with_log`, to call it.
- It `take`s just two of the six fields in `RegionConstraintStorage`.
At one of the two call sites we unnecessarily clone the entire
`RegionConstraintStorage` just to take those two fields.
This commit just inlines and removes it. We no longer need to `take` the
two fields, we can just use them directly.
`OutlivesEnvironment::new` can call `OutlivesEnvironment::with_bounds`
with an empty `extra_bounds`. And once that's done,
`OutlivesEnvironmentBuilder` has a single use and can be inlined and
removed into `OutlivesEnvironment::with_bounds`.
Fix utf8-bom test
The BOM was accidentally removed in https://github.com/rust-lang/rust/pull/57108
I had to move the run-pass line down, because compiletest doesn't seem to know about BOMs, so it does not parse the header if it is the first line.
Add tests for some old fixed issues
Closes#30867Closes#30472Closes#28994Closes#26719 (and migrates the relevant test to the new run-make)
Closes#23600
cc `@jieyouxu` for the run-make-support changes
try-job: x86_64-msvc
Fix `target_vendor` in non-IDF Xtensa ESP32 targets
`rustc`'s Xtensa ESP32 targets are the following:
- `xtensa-esp32-none-elf`
- `xtensa-esp32-espidf`
- `xtensa-esp32s2-none-elf`
- `xtensa-esp32s2-espidf`
- `xtensa-esp32s3-none-elf`
- `xtensa-esp32s3-espidf`
The ESP-IDF targets already set `target_vendor="espressif"`, however, the ESP32 is, from my understanding, produced by Espressif regardless of whether using the IDF or not, so we should set the target vendor there as well?
Add missing module flags for `-Zfunction-return=thunk-extern`
This fixes a bug in the `-Zfunction-return=thunk-extern` flag. The flag needs to be passed onto LLVM to ensure that functions such as `asan.module_ctor` and `asan.module_dtor` that are created internally in LLVM have the mitigation applied to them.
This was originally discovered [in the Linux kernel](https://lore.kernel.org/all/CANiq72myZL4_poCMuNFevtpYYc0V0embjSuKb7y=C+m3vVA_8g@mail.gmail.com/).
Original flag PR: #116892
PR for similar issue: #129373
Tracking issue: #116853
cc ``@ojeda``
r? ``@wesleywiser``
Add precondition checks to ptr::offset, ptr::add, ptr::sub
All of `offset`, `add`, and `sub` (currently) have the trivial preconditions that the offset in bytes must be <= isize::MAX, and the computation of the new address must not wrap. This adds precondition checks for these, and like in slice indexing, we use intrinsics directly to implement unsafe APIs that have explicit checks, because we get a clearer error message that mentions the misused API not an implementation detail.
Experimentation indicates these checks have 1-2% compile time overhead, due primarily to adding the checks for `add`.
A crater run (https://github.com/rust-lang/rust/pull/130251#issuecomment-2395824565) indicates some people currently have buggy calls to `ptr::offset` that apply a negative offset to a null pointer, but the crater run does not hit the `ptr::add` or `ptr::sub` checks, which seems like an argument for cfg'ing out those checks on account of their overhead.
