Rollup of 4 pull requests
Successful merges:
- rust-lang/rust#147577 (Improve error message for ambiguous numeric types in closure parameters)
- rust-lang/rust#147785 (fix incorrect line number when building trimmed multi-line suggestions)
- rust-lang/rust#147814 (btree: some cleanup with less unsafe)
- rust-lang/rust#147843 (Change the tidy license checker)
r? `@ghost`
`@rustbot` modify labels: rollup
fix incorrect line number when building trimmed multi-line suggestions
While fixing the issue https://github.com/rust-lang/rust-clippy/issues/15883 from `rust-clippy`, I tracked it down to a problem in `rustc` where line numbers were incorrect when building trimmed multi-line suggestions.
Rollup of 4 pull requests
Successful merges:
- rust-lang/rust#147734 (Further tighten up relaxed bounds)
- rust-lang/rust#147888 (enzyme/autodiff is compatible with download-ci=true)
- rust-lang/rust#147898 (compiletest: Move `AuxProps` out of `EarlyProps`)
- rust-lang/rust#147903 (compiletest: Store the selected edition in `TestProps`)
r? `@ghost`
`@rustbot` modify labels: rollup
Further tighten up relaxed bounds
Follow-up to rust-lang/rust#142693, rust-lang/rust#135331 and rust-lang/rust#135841.
Fixesrust-lang/rust#143122.
* Reject relaxed bounds `?Trait` in the bounds of trait aliases.
Just like `trait Trait {}` doesn't mean `trait Trait: Sized {}` and we therefore reject `trait Trait: ?Sized {}`, `trait Trait =;` (sic!) doesn't mean `trait Trait = Sized;` (never did!) and as a logical consequence `trait Trait = ?Sized;` is meaningless and should be forbidden.
* Don't permit `?Sized` in more places (e.g., supertrait bounds, trait object types) if feature `more_maybe_bounds` is enabled.
That internal feature is only meant to allow the user to define & use *new* default traits (that have fewer rules to follow for now to ease experimentation).
* Unconditionally check that the `Trait` in `?Trait` is a default trait.
Previously, we would only perform this check in selected places which was very brittle and led to bugs slipping through.
* Slightly improve diagnostics.
Offload host2
r? `@oli-obk`
A follow-up to my previous gpu host PR. With this, I can (in theory) run a sufficiently simple Rust function on GPUs. I tested it on AMD, where the amdgcn tartget of rustc causes issues due to Addressspace castings, which might not be valid. If I (manually) fix them, I can run the generated IR on an AMD GPU. This should conceptually also work on NVIDIA or Intel. I updated the dev-guide acordingly: https://rustc-dev-guide.rust-lang.org/offload/usage.html
I am unhappy with the amount of standalone functions in my offload code, so in my second commit I bundled some of the code around two structs which are Rust versions of the LLVM/Offload structs which they represent. The structs themselves only have doc comments. Since I directly lower everything to llvm-ir I didn't saw a big value in modelling the struct member variables.
unused_must_use: Don't warn on `Result<(), Uninhabited>` or `ControlFlow<Uninhabited, ()>`
This suppresses warnings on things like `Result<(), !>`, which helps simplify code using the common pattern of having an `Error` associated type: code will only have to check the error if there is a possibility of error.
This will, for instance, help with future refactorings of `write!` in the standard library.
As this is a user-visible change to lint behavior, it'll require a lang FCP.
---
My proposal, here, is that we handle this simple case to make common patterns more usable. This does not rule out the possibility of adding more cases in the future, including general trait-based cases. However, I don't think we should make this common case wait on the more general cases. In particular, this solution does not close any doors on replacing this special case with a general case.
This would unblock some planned work in the standard library to make `write!` more usable for infallible cases (e.g. writing into a `Vec` or `String`).
Deny-by-default never type lints
In Rust [1.89.0](https://github.com/rust-lang/rust/milestone/133) we started emitting these lints in dependencies. I discussed the future steps with `@lcnr` and we think that before stabilizing the never type (and doing the breaking changes) we should deny the lints for ~4 releases.
This PR marks `never_type_fallback_flowing_into_unsafe` and `dependency_on_unit_never_type_fallback` lints as deny-by-default.
Tracking:
- https://github.com/rust-lang/rust/issues/35121
Related:
- https://github.com/rust-lang/rust/pull/141937
use minicore for more tests
r? `@jieyouxu`
Unfortunately this doesn't work for all tests; minicore sometimes fails to build with errors like
```
rustc-LLVM ERROR: ILP32E cannot be used with the D ISA extension
```
and
```
error: the target features paca, pacg must all be either enabled or disabled together
```
These errors are meant to be triggered in the tests, but not in minicore.
It seems like all ``@compile-flags`` are forwarded to minicore. Maybe we should exclude `-Ctarget-feature` from that? Or provide some way to set flags only for the current file, not minicore?
Warn on unused_attributes in uitests
r? ```@jdonszelmann```
Because:
- unused_attributes warnings are usually actual mistakes, rather than just unused code, and we want to notify test writers they may be accidentally making a mistake
- Because the lint was allowed by default previously, we missed real bugs, because the test coverage is worse
1. https://github.com/rust-lang/rust/issues/147417
2. https://github.com/rust-lang/rust/issues/147411
Rehome 26 `tests/ui/issues/` tests to other subdirectories under `tests/ui/` [#5 of Batch #2]
Part of rust-lang/rust#133895
Methodology:
1. Refer to the previously written `tests/ui/SUMMARY.md`
2. Find an appropriate category for the test, using the original issue thread and the test contents.
3. Add the issue URL at the bottom (not at the top, as that would mess up stderr line numbers)
4. Rename the tests to make their purpose clearer
Inspired by the methodology that Kivooeo was using.
r? ```@jieyouxu```
Issue-125323: ICE non-ADT in struct pattern when long time constant evaluation is in for loop
This PR fixes#125323
## Context
According to the issue, the ICE happens since #121206.
In the PR, some error methods were reorganized. For example, has_errors() was renamed to has_errors_exclude_lint_errors(). However, some codes which used the original has_errors() were not switched to has_errors_exclude_lint_errors(). I finally found that report_error() in writeback.rs causes this ICE. Currently the method uses tainted_by_errors() to get guar (ErrorGuaranteed), but originally it used dcx().has_errors() but it wasn't changed to has_errors_exclude_lint_errors() when changes in #121206 were merged. I don't think I fully understand how an error is propagated, but I suppose that the error from long time constant evaluation is unexpectedly propagated other parts (in this ICE, for loop), then cause the non-ADT in struct pattern ICE.
## Change
- Fix report_error() in writeback.rs: use dcx().has_errors_exclude_lint_errors() instead of tainted_by_errors() to prevent error propagation from constant evaluation.
- Add test for the ICE
- Modify some tests to align the change: Due to this fix, E0282 error happens (or not happen anymore) in some tests.
## NOTE
The 4th commit aims to revert the fix in #123516 because I confirmed that the ICE solved by the PR doesn't happen if I modify report_error(). I think the root cause of that ICE is the same as #125323 . But I can discard this commit since we can fix#125323 without it.
rustdoc: Fix passes order so intra-doc links are collected after stripping passes
Fixes regression I introduced in https://github.com/rust-lang/rust/pull/147153.
This PR puts back the intra-doc link collecting pass after the stripping items pass, preventing lints to be emitted on non-visible items.
Although, might be nice to add a way to change this behaviour. To be discussed later on.
cc ``@ojeda``
r? ``@fmease``
deduced_param_attrs: check Freeze on monomorphic types.
`deduced_param_attrs` currently checks `Freeze` bound on polymorphic MIR. This pessimizes the deduction, as generic types are not `Freeze` by default.
This moves the check to the ABI adjustment.
Simplify trivial constants in SimplifyConstCondition
After `InstSimplify-after-simplifycfg` with `-Zub_checks=false`, there are many of the following patterns.
```
_13 = const false;
assume(copy _13);
_12 = unreachable_unchecked::precondition_check() -> [return: bb1, unwind unreachable];
```
Simplifying them to unreachable early should make CFG simpler.
the `#[track_caller]` shim should not inherit `#[no_mangle]`
fixes https://github.com/rust-lang/rust/issues/143162
builds on https://github.com/rust-lang/rust/pull/143293 which introduced a mechanism to strip attributes from shims.
cc `@Jules-Bertholet` `@workingjubilee` `@bjorn3`
---
Summary:
This PR fixes an interaction between `#[track_caller]`, `#[no_mangle]`, and casting to a function pointer.
A function annotated with `#[track_caller]` internally has a hidden extra argument for the panic location. The `#[track_caller]` attribute is only allowed on `extern "Rust"` functions. When a function is annotated with both `#[no_mangle]` and `#[track_caller]`, the exported symbol has the signature that includes the extra panic location argument. This works on stable rust today:
```rust
extern "Rust" {
#[track_caller]
fn rust_track_caller_ffi_test_tracked() -> &'static Location<'static>;
}
mod provides {
use std::panic::Location;
#[track_caller] // UB if we did not have this!
#[no_mangle]
fn rust_track_caller_ffi_test_tracked() -> &'static Location<'static> {
Location::caller()
}
}
```
When a `#[track_caller]` function is converted to a function pointer, a shim is added to drop the additional argument. So this is a valid program:
```rust
#[track_caller]
fn foo() {}
fn main() {
let f = foo as fn();
f();
}
```
The issue arises when `foo` is additionally annotated with `#[no_mangle]`, the generated shim currently inherits this attribute, also exporting a symbol named `foo`, but one without the hidden panic location argument. The linker rightfully complains about a duplicate symbol.
The solution of this PR is to have the generated shim drop the `#[no_mangle]` attribute.
error from const eval lint causes ICE at check_pat in late_lint, because the function expects the typeck result isn't tainted by error but it is.
To avoid the ICE, check_pat returns earlier if the typeck_result is tainted.
check_mod_deathness also has an issue from the same reason. visit_body for making live symbols expects the typeck result has no error.
So this commit adds a check in visit_nested_body to avoid the ICE.
However, if visit_nested_body just returns without doing anything, all codes with the error are marked as dead, because live_symbols is empty.
To avoid this side effect, visit_nested_body and other visit_* functions in MarkSymbolVistior should return appropriate error.
If a function returns ControlFlow::Break, live_symbols_and_ignore_derived_traits returns earlier with error,
then check_mod_deathness, the caller of the function returns earlier without pushing everything into dead_codes.
Fix ICE on offsetted ZST pointer
I'm not sure this is the *right* fix, but it's simple enough and does roughly what I'd expect. Like with the previous optimization to codegen usize rather than a zero-sized static, there's no guarantee that we continue returning a particular value from the offsetting.
A grep for `const_usize.*align` found the same code copied to rustc_codegen_gcc and cranelift but a quick skim didn't find other cases of similar 'optimization'. That said, I'm not convinced I caught everything, it's not trivial to search for this.
Closesrust-lang/rust#147516
Guard HIR lowered contracts with `contract_checks`
Refactor contract HIR lowering to ensure no contract code is executed when contract-checks are disabled.
The call to `contract_checks` is moved to inside the lowered fn body, and contract closures are built conditionally, ensuring no side-effects present in contracts occur when those are disabled. This partially addresses rust-lang/rust#139548, i.e. the bad behavior no longer happens with contract checks disabled (`-Zcontract-checks=no`).
The change is made in preparation for adding contract variable declarations - variables declared before the `requires` assertion, and accessible from both `requires` and `ensures`, but not in the function body (PR rust-lang/rust#144444). As those declarations may also have side-effects, it's good to guard them with `contract_checks` - the new lowering approach allows for this to be done easily.
Contracts tracking issue: rust-lang/rust#128044
**Known limiatations**:
- It is still possible to early return from the *function* from within a contract, e.g.
```rust
#[ensures({if x > 0 { return 0 }; |_| true})]
fn foo(x: u32) -> i32 {
42
}
```
When `foo` is called with an argument greater than 0, instead of `42`, `0` will be returned.
As this is not a regression, it is not addressed in this PR. However, it may be worth revisiting later down the line, as users may expect a form of early return from *contract specifications*, and so returning from the entire *function* could cause confusion.
- ~Contracts are still not optimised out when disabled. Currently, even when contracts are disabled, the code generated causes existing optimisations to fail, meaning even disabled contracts could impact runtime performance. This issue is blocking rust-lang/rust#136578, and has not been addressed in this PR, i.e. the `mir-opt` and `codegen` tests that fail in rust-lang/rust#136578 still fail with these new HIR lowering changes.~ Contracts should now be optimised out when disabled, however some regressions tests still need to be added to be sure that is indeed the case.
