Tweak auto trait errors
Make suggestions to remove params and super traits verbose and make spans more accurate.
```
error[E0567]: auto traits cannot have generic parameters
--> $DIR/auto-trait-validation.rs:6:19
|
LL | auto trait Generic<T> {}
| -------^^^
| |
| auto trait cannot have generic parameters
error[E0568]: auto traits cannot have super traits or lifetime bounds
--> $DIR/auto-trait-validation.rs:8:20
|
LL | auto trait Bound : Copy {}
| ----- ^^^^
| |
| auto traits cannot have super traits or lifetime bounds
```
```
error[E0380]: auto traits cannot have associated items
--> $DIR/issue-23080.rs:5:8
|
LL | unsafe auto trait Trait {
| ----- auto traits cannot have associated items
LL | fn method(&self) {
| ^^^^^^
```
Revert "Preserve the .debug_gdb_scripts section"
https://github.com/rust-lang/rust/pull/143679 introduces a significant build time perf regression for ripgrep. Let's revert it such that we can investigate it without pressure.
Broken by #144776; this is reachable after all.
Fixes#144994.
The commit also adds a lot more cases to the `type-name-basic.rs`,
because it's currently very anaemic. This includes some cases where
region omission does very badly; these are marked with FIXME.
Fortify generic param default checks
* Hard-reject instead of lint-reject type param defaults in generic assoc consts (GACs) (feature: `generic_const_items`).
* In https://github.com/rust-lang/rust/pull/113522, I explicitly handled the free const item case and forgot about the assoc const one.
* This led rustc to assume the default of emitting the deny-by-default lint `invalid_type_param_default`.
* GCIs are unstable, thus we're not bound by backward compat
* Hard-reject instead of lint-reject type param defaults in foreign items.
* We already hard-reject generic params on foreign items, so this isn't a breaking change.
* There's no reason why we need to lint-reject.
* Refactor the way we determine where generic param defaults are allowed:
* Don't default to emitting lint `invalid_type_param_defaults` for nodes that aren't explicitly handled but instead panic.
* This would've caught my GAC oversight from above much earlier via fuzzing
* Prevents us from accidentally stabilizing more invalid type param defaults in the future
* Streamline the phrasing of the diagnostic
we only merge candidates for trait and normalizes-to goals
so change `fn try_merge_responses` to `fn try_merge_candidates` and just use candidates everywhere.
Potentially slightly faster than the alternative :3
r? ``@compiler-errors`` ``@BoxyUwU``
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
This restricts the uses of the unadjusted ABI to LLVM intrinsics. The
Rust ABI works fine for the thread-local shim as it always returns
pointers directly like the backend expects.
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.
This adds
- (ex) for regions whose origin is existential,
- (p) for regoins whose origin is a placeholder, and
- (p for <name>) if the originating placeholder is named.
This has helped _my_ debugging and it doesn't create too bad clutter, I feel.
The change is ridiculously small, but I turned it into a separate PR so we can bikeshed the format.
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.
Stuart Cook