Add NonNull pattern types
These are the final piece missing for
* https://github.com/rust-lang/rust/pull/136006
We cannot use the previous scheme of using an integer range for raw pointers, as we're not just changing the layout of raw pointers anymore, but also the type representation. And we can't represent "any provenance or NonZero<usize>" natively as patterns. So I created a new `!null` pattern. Since this is all unstable representation stuff for replacing rustc_layout_scalar_range_start with pattern types, the divergence from normal patterns is fine, especially since T-lang seems interested in exploring general negation patterns
r? `@BoxyUwU`
Add `FromIterator` impls for `ascii::Char`s to `String`s
Wanted to `collect` ascii chars into a `String` while working on #141369 , and was surprised these impls don't exist. Seems to me to be simply oversight.
BTW, I only added `impl FromIterator<ascii::Char> for Cow<'_, str>`, without a corresponding `FromIterator<&Char>` impl, because there's no existing impl for `FromIterator<&char>`, but that might be oversight too.
cc #110998
`-Znext-solver` instantiate predicate binder without recanonicalizing goal
This strengthens the leak check to match the old trait solver. The new trait solver now also instantiates higher ranked goals in the same scope as candidate selection, so the leak check in each candidate detects placeholder errors involving this higher ranked goal.
E.g. let's look at tests/ui/higher-ranked/leak-check/leak-check-in-selection-2.rs
```rust
trait Trait<T, U> {}
impl<'a> Trait<&'a str, &'a str> for () {}
impl<'a> Trait<&'a str, String> for () {}
fn impls_trait<T: for<'a> Trait<&'a str, U>, U>() {}
fn main() {
impls_trait::<(), _>();
}
```
Here proving `(): for<'a> Trait<&'a str, ?u>` via `impl<'a> Trait<&'a str, &'a str> for ()` equates `?u` with `&'!a str` which results in a leak check error as `?u` cannot name `'a`. If this leak check error happens while considering candidates we drop the first impl and infer `?u` to `String`. If not, this remains ambiguous.
This behavior is a bit iffy, see the FCP proposal in rust-lang/rust#119820 for more details on why this current behavior is somewhat undesirable. However, considering placeholders from higher-ranked goals for candidate selection does allow more code to compile and a lot of the code *feels like it should compile*. **This caused us to revert the change of rust-lang/rust#119820 in rust-lang/rust#127568.**
I originally expected that we can avoid breakage with the new solver differently here, e.g. by considering OR-region constraints. However, doing so is a significant change and I don't have a great idea for how that should work. Matching the old solver behavior for now should not make this cleaner approach any more difficult in the future, so let's just go with what actually allows us to stabilize the new solver for now.
This PR changing the new solver to match the behavior of the old one wrt the leak check. As the new solver is already used by default in coherence, this allows more code to compile, see `tests/ui/higher-ranked/leak-check/leak-check-in-selection-7-coherence.rs`:
```rust
struct W<T, U>(T, U);
trait Trait<T> {}
// using this impl results in a higher-ranked region error.
impl<'a> Trait<W<&'a str, &'a str>> for () {}
impl<'a> Trait<W<&'a str, String>> for () {}
trait NotString {}
impl NotString for &str {}
impl NotString for u32 {}
trait Overlap<U> {}
impl<T: for<'a> Trait<W<&'a str, U>>, U> Overlap<U> for T {}
impl<U: NotString> Overlap<U> for () {}
fn main() {}
```
This behavior is quite arbitrary and not something I expect users to rely on in practice, however, it should still go through an FCP imo.
r? `@BoxyUwU` originally implemented by `@compiler-errors` in https://github.com/rust-lang/rust/pull/136997. Closes https://github.com/rust-lang/trait-system-refactor-initiative/issues/120.
compiletest: Don't set `TARGET` for non run-make tests
There are a few tests that were using `TARGET` to quietly do nothing on `i586` targets, but it's cleaner to just add support for `//@ ignore-i586` instead.
This lets us get rid of an unsafe `env::set_var` in compiletest, which really should have been setting the environment variable on individual build/run subprocess commands anyway.
- The original code and tests were introduced way back in rust-lang/rust#39068
Add a test for the cold attribute
This adds a test for the cold attribute to verify that it actually does something, and that it applies correctly in all the positions it is expected to work.
There are a few tests that were trying to skip i586 targets via the `TARGET`
environment variable instead, so better to just add support for the directive.
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.
