Explain why we retroactively change a static initializer to have a different type
I keep getting confused about it and in turn confused `@GuillaumeGomez` while trying to explain it badly
Shorten error message for callable with wrong return type
```
error: expected `{closure@...}` to return `Ret`, but it returns `Other`
```
instead of
```
error: expected `{closure@...}` to be a closure that returns `Ret`, but it returns `Other`
```
Fix malformed error annotations in a UI test
The compiletest DSL still features a historical remnant from the time when its directives were merely prefixed with `//` instead of `//`@`` when unknown directive names weren't rejected since they could just as well be part of prose:
As an "optimization", it stops looking for directives once it stumbles upon a line which starts with either `fn` or `mod`. This allowed a malformed error annotation of the form `//`@[…]~^^^`` to go undetected & unexercised (as it's placed below `fn main() {`).
Obviously a character other than ``@`` would've mangled the error annotation, too (but it might've caught the reviewer's eye). I specifically found this file because I ran `rg '^(fn|mod)[\s\S]*?//`@'` tests/ui --multiline -trust` to check how footgun-y that "special feature" of compiletest is.
CompileTest: Add Directives to Ignore `arm-unknown-*` Targets
In #134626, I want to ignore `arm-unknown-*` targets because the LLVM IR for those looks very different compared to other targets: https://rust.godbolt.org/z/ssYMhdv4x.
I can use `ignore-arm` but, I think, it would exclude large number of Apple devices.
So this PR adds a few directives to ignore `arm-unknown-*` targets specifically.
tests: Port `symbol-mangling-hashed` to rmake.rs
Part of #121876.
This PR supersedes #128567 and is co-authored with `@lolbinarycat.`
### Summary
This PR ports `tests/run-make/symbol-mangling-hashed` to rmake.rs. Notable differences when compared to the Makefile version includes:
- It's no longer limited to linux + x86_64 only. In particular, this now is exercised on darwin and windows (esp. msvc) too.
- The test uses `object` crate to be more precise in the filtering, and avoids relying on parsing the human-readable `nm` output for *some* `nm` in the given environment (which isn't really a thing on msvc anyway, and `llvm-nm` doesn't handle msvc dylibs AFAICT).
- Dump the symbols satisfying various criteria on test failure to make it hopefully less of a pain to debug if it ever fails in CI.
### Review advice
- Best reviewed commit-by-commit.
- I'm not *super* sure about the msvc logic, would benefit from a MSVC (PE/COFF) expert taking a look.
---
try-job: x86_64-msvc-1
try-job: i686-msvc-1
try-job: i686-mingw
try-job: x86_64-mingw-1
try-job: x86_64-apple-1
try-job: aarch64-apple
try-job: test-various
Insert null checks for pointer dereferences when debug assertions are enabled
Similar to how the alignment is already checked, this adds a check
for null pointer dereferences in debug mode. It is implemented similarly
to the alignment check as a `MirPass`.
This inserts checks in the same places as the `CheckAlignment` pass and additionally
also inserts checks for `Borrows`, so code like
```rust
let ptr: *const u32 = std::ptr::null();
let val: &u32 = unsafe { &*ptr };
```
will have a check inserted on dereference. This is done because null references
are UB. The alignment check doesn't cover these places, because in `&(*ptr).field`,
the exact requirement is that the final reference must be aligned. This is something to
consider further enhancements of the alignment check.
For now this is implemented as a separate `MirPass`, to make it easy to disable
this check if necessary.
This is related to a 2025H1 project goal for better UB checks in debug
mode: https://github.com/rust-lang/rust-project-goals/pull/177.
r? `@saethlin`
Replace our `LLVMRustDIBuilderRef` with LLVM-C's `LLVMDIBuilderRef`
Inspired by trying to split #134009 into smaller steps that are easier to review individually.
This makes it possible to start incrementally replacing our debuginfo bindings with the ones in the LLVM-C API, all of which operate on `LLVMDIBuilderRef`.
There should be no change to compiler behaviour.
Improve documentation when adding a new target
https://github.com/rust-lang/rust/pull/133631#issuecomment-2607877936 shows that it can be a bit difficult process-wise to add a new target.
I've added a bit of text to the docs, suggesting that users add the target defintion/spec first, and later work on `std` support.
I also found that we have two places where we document how to add a new target. I've linked these for now, but they should probably be merged somehow in the future.
`@rustbot` label A-docs
r? compiler
CC `@workingjubilee` who's worked a lot on target specs IIRC.
lcnr
Martin Liska
León Orell Valerian Liehr
Michael Howell
Marco Ieni
许杰友 Jieyou Xu (Joe)
Jakub Beránek
Tshepang Mbambo
Rehmatpal Singh
Yuki Okushi
The rustc-dev-guide Cronjob Bot
bors
Matthias Krüger
bjorn3
nora
Onur Özkan
Ben Kimock
The Miri Cronjob Bot