Enforce tail call type is related to body return type in borrowck
Like all call terminators, tail call terminators instantiate the binder of the callee signature with region variables and equate the arg operand types with that signature's args to ensure that the call is valid.
However, unlike normal call terminators, we were forgetting to also relate the return type of the call terminator to anything. In the case of tail call terminators, the correct thing is to relate it to the return type of the caller function (or in other words, the return local `_0`).
This meant that if the caller's return type had some lifetime constraint, then that constraint wouldn't flow through the signature and affect the args.
This is what's happening in the example test I committed:
```rust
fn link(x: &str) -> &'static str {
become passthrough(x);
}
fn passthrough<T>(t: T) -> T { t }
fn main() {
let x = String::from("hello, world");
let s = link(&x);
drop(x);
println!("{s}");
}
```
Specifically, the type `x` is `'?0 str`, where `'?0` is some *universal* arg. The type of `passthrough` is `fn(&'?1 str) -> &'?1 str`. Equating the args sets `'?0 = '?1`. However, we need to also equate the return type `&'?1 str` to `&'static str` so that we eventually require that `'?0 = 'static`, which is a borrowck error!
-----
Look at the first commit for the functional change, and the second commit is just a refactor because we don't need to pass `Option<BasicBlock>` to `check_call_dest`, but just whether or not the terminator is expected to be diverging (i.e. if the return type is `!`).
Fixesrust-lang/rust#144916
Parser: Recover from attributes applied to types and generic args
r? compiler
Add clearer error messages for invalid attribute usage in types or generic types
fixesrust-lang/rust#135017fixesrust-lang/rust#144132
Rollup of 12 pull requests
Successful merges:
- rust-lang/rust#144552 (Rehome 33 `tests/ui/issues/` tests to other subdirectories under `tests/ui/`)
- rust-lang/rust#144676 (Add documentation for unstable_feature_bound)
- rust-lang/rust#144836 (Change visibility of Args new function)
- rust-lang/rust#144910 (Add regression tests for seemingly fixed issues)
- rust-lang/rust#144913 ([rustdoc] Fix wrong `i` tooltip icon)
- rust-lang/rust#144924 (compiletest: add hint for when a ui test produces no errors)
- rust-lang/rust#144926 (Correct the use of `must_use` on btree::IterMut)
- rust-lang/rust#144928 (Drop `rust-version` from `rustc_thread_pool`)
- rust-lang/rust#144945 (Autolabel PRs that change explicit tail call tests as `F-explicit_tail_calls`)
- rust-lang/rust#144954 (run-make: Allow blessing snapshot files that don't exist yet)
- rust-lang/rust#144971 (num: Rename `isolate_most_least_significant_one` functions)
- rust-lang/rust#144978 (Fix some doc links for intrinsics)
r? `@ghost`
`@rustbot` modify labels: rollup
Drop `rust-version` from `rustc_thread_pool`
The current `rust-version = "1.63"` was inherited from rayon, but it
doesn't make sense to limit this in the compiler workspace. Having any
setting at all has effects on tools like `cargo info` that try to infer
the MSRV when the workspace itself doesn't specify it. Since we are the
compiler, our only MSRV is whatever bootstrapping requires.
Preserve the .debug_gdb_scripts section
Make sure that compiler and linker don't optimize the section's contents
away by adding the global holding the data to `llvm.used`. This
eliminates the need for a volatile load in the main shim; since the LLVM
codegen backend is the only implementer of the corresponding trait
function, remove it entirely.
Pretty printers in dylib dependencies are now emitted by the main crate
instead of the dylib; apart from matching how rlibs are handled, this
approach has the advantage that `omit_gdb_pretty_printer_section` keeps
working with dylib dependencies.
r? `@bjorn3`
Instead of collecting pretty printers transitively when building
executables/staticlibs/cdylibs, let the debugger find each crate's
pretty printers via its .debug_gdb_scripts section. This covers the case
where libraries defining custom pretty printers are loaded dynamically.
Simplify dead code lint
This PR scratches a few itches I had when looking at that code.
The perf improvement comes from keeping the `scanned` set through several marking phases. This pretty much divides by 2 the number of HIR traversals.
Make sure that compiler and linker don't optimize the section's contents
away by adding the global holding the data to "llvm.used". The volatile
load in the main shim is retained because "llvm.used", which translates
to SHF_GNU_RETAIN on ELF targets, requires a reasonably recent linker;
emitting the volatile load ensures compatibility with older linkers, at
least when libstd is used.
Pretty printers in dylib dependencies are now emitted by the main crate
instead of the dylib; apart from matching how rlibs are handled, this
approach has the advantage that `omit_gdb_pretty_printer_section` keeps
working with dylib dependencies.
coverage: Various small cleanups
This PR is a collection of small coverage-related changes that I accumulated while working towards other coverage improvements.
Each change should hopefully be fairly straightforward.
`Printer` cleanups
The trait `Printer` is implemented by six types, and the sub-trait `PrettyPrinter` is implemented by three of those types. The traits and the impls are complex and a bit of a mess. This PR starts to clean them up.
r? ``@davidtwco``
fix: Error on illegal `[const]`s inside blocks within legal positions
Fixesrust-lang/rust#132067
I initially considered moving `[const]` validations to `rustc_ast_lowering`, but that approach would require adding constness information to `AssocCtxt`, which introduces significant changes - especially within `rustc_expand` - just to support a single use case here:
3fb1b53a9d/compiler/rustc_ast_passes/src/ast_validation.rs (L1596-L1610)
Instead, I believe it's sufficient to simply "reset" `[const]` allowness whenever we enter a new block.
The current `rust-version = "1.63"` was inherited from rayon, but it
doesn't make sense to limit this in the compiler workspace. Having any
setting at all has effects on tools like `cargo info` that try to infer
the MSRV when the workspace itself doesn't specify it. Since we are the
compiler, our only MSRV is whatever bootstrapping requires.
Distinguish prepending and replacing self ty in predicates
There are two kinds of functions called `with_self_ty`:
1. Prepends the `Self` type onto an `ExistentialPredicate` which lacks it in its internal representation.
2. Replaces the `Self` type of an existing predicate, either for diagnostics purposes or in the new trait solver when normalizing that self type.
This PR distinguishes these two because I often want to only grep for one of them. Namely, let's call it `with_replaced_self_ty` when all we're doing is replacing the self type.
resolve: Cleanups and micro-optimizations to extern prelude
This is what can be done without changing the structure of `ExternPreludeEntry`, like in https://github.com/rust-lang/rust/pull/144737.
See individual commits for details.
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.
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
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.
