Do not give function allocations alignment in consteval and Miri.
We do not yet have a (clear and T-lang approved) design for how `#[align(N)]` on functions should affect function pointers' addresses on various platforms, so for now do not give function pointers alignment in consteval and Miri.
----
Old summary:
Not a full solution to <https://github.com/rust-lang/rust/issues/144661>, but fixes the immediate issue by making function allocations all have alignment 1 in consteval, ignoring `#[rustc_align(N)]`, so the compiler doesn't know if any offset other than 0 is non-null.
A more "principlied" solution would probably be to make function pointers to `#[instruction_set(arm::t32)]` functions be at offset 1 of an align-`max(2, align attribute)` allocation instead of at offset 0 of their allocation during consteval, and on wasm to either disallow `#[align(N)]` where N > 1, or to pad the function table such that the function pointer of a `#[align(N)]` function is a multiple of `N` at runtime.
`AlignmentEnum` should just be `repr(usize)` now
These used to use specific sizes because they were compiled on all widths. But now that the types themselves are `#[cfg]`'d, we can save some conversions by having it always be `repr(usize)`.
Enable extract-insert-dyn.rs test on RISC-V (riscv64)
This PR adds support for running the `tests/codegen-llvm/simd/extract-insert-dyn.rs` test on the RISC-V (riscv64) architecture.
Previously, this test would fail on RISC-V targets due to architecture-specific code generation issues. This patch modifies the test to ensure compatibility while preserving its intent.
The change has been tested locally using `./x test` on a riscv64 target, and the test now passes as expected.
### Notes:
- This change is scoped specifically to improve RISC-V compatibility.
- It does not affect behavior or test results on other architectures.
Add lint against dangling pointers from local variables
## `dangling_pointers_from_locals`
*warn-by-default*
The `dangling_pointers_from_locals` lint detects getting a pointer to data of a local that will be dropped at the end of the function.
### Example
```rust
fn f() -> *const u8 {
let x = 0;
&x // returns a dangling ptr to `x`
}
```
```text
warning: a dangling pointer will be produced because the local variable `x` will be dropped
--> $DIR/dangling-pointers-from-locals.rs:10:5
|
LL | fn simple() -> *const u8 {
| --------- return type of the function is `*const u8`
LL | let x = 0;
| - `x` is defined inside the function and will be drop at the end of the function
LL | &x
| ^^
|
= note: pointers do not have a lifetime; after returning, the `u8` will be deallocated at the end of the function because nothing is referencing it as far as the type system is concerned
= note: `#[warn(dangling_pointers_from_locals)]` on by default
```
### Explanation
Returning a pointer from a local value will not prolong its lifetime, which means that the value can be dropped and the allocation freed while the pointer still exists, making the pointer dangling.
If you need stronger guarantees, consider using references instead, as they are statically verified by the borrow-checker to never dangle.
------
This is related to GitHub codeql [CWE-825](https://github.com/github/codeql/blob/main/rust/ql/src/queries/security/CWE-825/AccessAfterLifetimeBad.rs) which shows examples of such simple miss-use.
It should be noted that C compilers warns against such patterns even without `-Wall`, https://godbolt.org/z/P7z98arrc.
------
`@rustbot` labels +I-lang-nominated +T-lang
cc `@traviscross`
r? compiler
Use full flag name in strip command for Darwin
Darwin always uses `rust-objcopy` which supports long-form flags
Solaris unchanged due to not having support for `--discard-all` and only `-x`
fixes https://github.com/rust-lang/rust/issues/135038
r? ````@WaffleLapkin```` (since bot will ping you anyway, feel free to reroll)
Return a struct with named fields from `hash_owner_nodes`
While looking through this code for other reasons, I noticed a nice opportunity to return a struct with named fields instead of a tuple. The first patch also introduces an early-return to flatten the rest of `hash_owner_nodes`.
There are further changes that could potentially be made here (renaming things, `Option<Hashes>` instead of optional fields), but I'm not deeply familiar with this code so I didn't want to disturb the calling code too much.
`Interner` arg to `EarlyBinder` does not affect auto traits
Conceptually `EarlyBinder` does not contain an `Interner` so it shouldn't tell Rust it does via `PhantomData`. This is necessary for rust-analyzer as it stores `EarlyBinder`s in query results which require `Sync`, placing restrictions on our interner setup.
r? compiler-errors
compiletest: Preliminary cleanup of `ProcRes` printing/unwinding
While experimenting with changes to how compiletest handles output capture, error reporting, and unwinding, I repeatedly ran in to difficulties with this core code for reporting test failures caused by a subprocess.
There should be no change in compiletest output.
r? jieyouxu
Remove the omit_gdb_pretty_printer_section attribute
Disabling loading of pretty printers in the debugger itself is more reliable. Before this commit the .gdb_debug_scripts section couldn't be included in dylibs or rlibs as otherwise there is no way to disable the section anymore without recompiling the entire standard library.
expand WF obligations when checking method calls
Don't wrap a bunch of signatures in `FnPtr` then check their WF; instead, check the WFness of each input/output separately.
This is useful for the new trait solver, since because we stall on root obligations we end up needing to repeatedly recompute the WFness of possibly very large function signature types if it ends up bottoming out in ambiguity.
This may also give us more chances to hit the WF fast path for certain types like built-ins.
Finally, this just seems conceptually correct to do. There's nothing conceptually that suggests that wrapping the function signature in an fn pointer makes sense at all to do; I'm guessing that it was just convenient so that we didn't have to register WF obligations in a loop, but it doesn't affect the readability of this code at all.
This reduces the amount of "hidden" printing in error-reporting code, which
will be helpful when overhauling compiletest's error handling and output
capture.
Update safety comment for new_unchecked in niche_types
Change the safety comment on `new_unchecked` to mention the valid range instead of 0. I noticed this while working on https://github.com/model-checking/verify-rust-std
Properly pass path to staged `rustc` to `compiletest` self-tests
Otherwise, this can do weird things like use a global rustc, or try to use stage 0 rustc. This must be properly configured, because `compiletest` is intended to only support one compiler target spec JSON format (of the in-tree compiler).
Historically, this was probably done so before `bootstrap` was really its own thing, and `compiletest` had to be runnable as a much more "self-standing" tool.
Follow-up to rust-lang/rust#144675, as I didn't realize this until Zalathar pointed it out in [#t-infra/bootstrap > Building vs testing `compiletest` @ 💬](https://rust-lang.zulipchat.com/#narrow/channel/326414-t-infra.2Fbootstrap/topic/Building.20vs.20testing.20.60compiletest.60/near/532040838).
r? ````@Kobzol````
[test][AIX] ignore extern_weak linkage test
The AIX linkage model doesn't support ELF-style extern_weak semantics, so just skip this test, like other platforms that don't have it.
Improve formatting of doc code blocks
We don't currently apply automatic formatting to doc comment code blocks. As a
result, it has built up various idiosyncracies, which make such automatic
formatting difficult. Some of those idiosyncracies also make things harder for
human readers or other tools.
This PR makes a few improvements to doc code formatting, in the hopes of making
future automatic formatting easier, as well as in many cases providing net
readability improvements.
I would suggest reading each commit separately, as each commit contains one
class of changes.
update fortanix tests
Firstly, as far as I can tell, no CI job actually runs any of the fortanix tests? Maybe I'm missing the job that runs these tests though?
In any case, the `assembly` tests now use `minicore`, meaning that they will run regardless of the host architecture (specifically, they will run during a standard PR CI build).
The run-make test is actually broken, and I'd propose to make it just `cargo build` rather than `cargo run`. We can have a separate test for actually running the program, if desired.
Also this test is subject to https://github.com/rust-lang/rust/issues/128733, so I'd like to re-evaluate what parts of the C/C++ compilation are actually required or useful.
cc [``@jethrogb](https://github.com/jethrogb)`` [``@raoulstrackx](https://github.com/raoulstrackx)`` [``@aditijannu](https://github.com/aditijannu)``
r? ``@jieyouxu``
Document guarantees of poisoning
This mostly documents the current behavior of `Mutex` and `RwLock` (rust-lang/rust#143471) as imperfect. It's unlikely that the situation improves significantly in the future, and even if it does, the rules will probably be more complicated than "poisoning is completely reliable", so this is a conservative guarantee.
We also explicitly specify that `OnceLock` never poisons, even though it has an API similar to mutexes.
Fixesrust-lang/rust#143471 by improving documentation.
r? ``@Amanieu``
[rustdoc] Display unsafe attrs with edition 2024 `unsafe()` wrappers.
Use Rust 2024 edition representation for unsafe attributes in rustdoc HTML:
- `#[no_mangle]` -> `#[unsafe(no_mangle)]`
- `#[export_name = "foo"]` -> `#[unsafe(export_name = "foo")]`
- `#[link_section = ".text"]` -> `#[unsafe(link_section = ".text")]`
The 2024 edition representation is used regardless of the crate's own edition. This ensures that Rustaceans don't have to learn the rules of an outdated edition (e.g. that `unsafe()` wasn't always necessary) in order to understand a crate's documentation.
After some looking through the `T-rustdoc` issues, I was not able to find an existing issue for this. Apologies if I missed it.
r? ``````@aDotInTheVoid``````
