match exhaustiveness: Show the guard exhaustivity note only when it's the guards alone that cause non-exhaustiveness
Only show the "match arms with guards don't count towards exhaustivity" note when removing all guards would make the match exhaustive, but also in the cases when the match contains arms without guards. Previously, this note was shown only if all arms had guards, but even if the patterns themselves were insufficient to cover all valid values of a type.
Do this by rerunning the exhaustiveness analysis with guards stripped to determine whether the guards are actually the cause of non-exhaustiveness. This only happens on an actual exhaustiveness error, so should not be a performance concern.
This will make a program like:
```rust
fn main() {
let some_condition = true;
let some_option: Option<u8> = None;
let _res = match some_option {
Some(val) if some_condition => val,
None => 0,
};
}
```
produce the note ”match arms with guards don't count towards exhaustivity” that previously would not have been appearing.
Closesrust-lang/rust#104653 as I think this addresses the spirit of that issue. I don’t believe it’s necessary to be any more elaborate in the diagnostics here?
Fix ICE in next-solver dyn-compatibility check
The next solver treated error-containing dispatchability goals as proven and misclassified the trait as dyn compatible. Short-circuit receivers with type errors so object-method confirmation stays on the normal error path.
Tracking issue: rust-lang/rust#130516Closes: rust-lang/rust#151311
Fix private fields diagnostics and improve error messages
Fixesrust-lang/rust#151408
while the best solution may be check whether the code is under user's control, e.g. in the same workspace. but if user does not provide some fields, mention other private fields seems weird, see the test case:
```console
LL | let _ = std::collections::HashMap {};
| ^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: private field `base` that was not provided
```
since we already suggested to use associated function to construct, it's better to remove the note.
this fix only provide note on private fields when `did.is_local()` or user have already provide some fields.
move borrow checker tests
Hi, I have moved some tests I think should be in the borrowck category. Please let me know if there are issues. r? @Kivooeo
Related to rust-lang/rust#133895
Use convergent attribute to funcs for GPU targets
On targets with convergent operations, we need to add the convergent attribute to all functions that run convergent operations. Following clang, we can conservatively apply the attribute to all functions when compiling for such a target and rely on LLVM optimizing away the attribute in cases where it is not necessary.
This affects the amdgpu and nvptx targets.
cc @kjetilkjeka, @kulst for nvptx
cc @ZuseZ4
r? @nnethercote, as you already reviewed this in the other PR
Split out from rust-lang/rust#149637, the part here should be uncontroversial.
Rollup of 4 pull requests
Successful merges:
- rust-lang/rust#154460 (Deduplication: Pulled common logic out from lower_const_arg_struct)
- rust-lang/rust#154609 (Enable `#[diagnostic::on_const]` for local impls)
- rust-lang/rust#154678 (Introduce #[diagnostic::on_move] on `Rc`)
- rust-lang/rust#154902 (rustdoc: Inherit inline attributes for declarative macros)
rustdoc: Inherit inline attributes for declarative macros
When explicitly re-exporting a declarative macro by name, rustdoc previously bypassed intermediate re-exports and dropped `#[doc(inline)]` attributes, causing the macro to be incorrectly stripped if the original definition was `#[doc(hidden)]`.
This updates `generate_item_with_correct_attrs` to walk the `reexport_chain` specifically for declarative macros, allowing them to inherit inline attributes exactly as glob imports do, while preserving strict visibility rules for standard items.
Fixesrust-lang/rust#154694
Explicitly forget the zero remaining elements in `vec::IntoIter::fold()`.
[Original description:] ~~This seems to help LLVM notice that dropping the elements in the destructor of `IntoIter` is not necessary. In cases it doesn’t help, it should be cheap since it is just one assignment.~~
This PR adds a function to `vec::IntoIter()` which is used used by `fold()` and `spec_extend()`, when those operations complete, to forget the zero remaining elements and only deallocate the allocation, ensuring that there will never be a useless loop to drop zero remaining elements when the iterator is dropped.
This is my first ever attempt at this kind of codegen micro-optimization in the standard library, so please let me know what should go into the PR or what sort of additional systematic testing might indicate this is a good or bad idea.
The next solver treated error-containing dispatchability goals as proven and misclassified the trait as dyn compatible. Short-circuit receivers with type errors so object-method confirmation stays on the normal error path.
Migrate some tests from `tests/ui/issues` to appropriate directories
The following changes have been made in the pull request:
- `tests/ui/issues/issue-25746-bool-transmute.rs` ➝ `tests/ui/transmute/transmute-bool-u8.rs`
- `tests/ui/issues/issue-32377.{rs,stderr}` ➝ `tests/ui/intrinsics/transmute-phantomdata-generic-unequal-size.{rs,stderr}`
The issue links have also been added at the top of each `.rs` file.
r? Kivooeo
GCI: During reachability analysis don't try to evaluate the initializer of overly generic free const items
We generally don't want the initializer of free const items to get evaluated if they have any non-lifetime generic parameters. However, while I did account for that in HIR analysis & mono item collection (rust-lang/rust#136168 & rust-lang/rust#136429), I didn't account for reachability analysis so far which means that on main we still evaluate such items if they are *public* for example.
The closed PR rust-lang/rust#142293 from a year ago did address that as a byproduct but of course it wasn't merged since its primary goal was misguided. This PR extracts & improves upon the relevant parts of that PR which are necessary to fix said issue.
Follow up to rust-lang/rust#136168 & rust-lang/rust#136429.
Partially supersedes rust-lang/rust#142293.
Part of rust-lang/rust#113521.
r? @BoxyUwU
delegation: generate more verbose error delegation
After this PR we generate more verbose error delegation including path lowering, as there can be other code in generic args as in rust-lang/rust#154820. Now we access information for delegation lowering through ty-level queries and they require that the code should be lowered, even if it is in unresolved delegation.
Fixesrust-lang/rust#154820, part of rust-lang/rust#118212.
r? @petrochenkov
`ty::Alias` refactor
This PR changes the following alias-related types from this:
```rust
pub enum AliasTyKind {
Projection,
Inherent,
Opaque,
Free,
}
pub struct AliasTy<I: Interner> {
pub args: I::GenericArgs,
pub def_id: I::DefId,
}
pub enum TyKind<I: Interner> {
...
Alias(AliasTyKind, AliasTy<I>),
}
```
Into this:
```rust
pub enum AliasTyKind<I: Interner> {
Projection { def_id: I::DefId },
Inherent { def_id: I::DefId },
Opaque { def_id: I::DefId },
Free { def_id: I::DefId },
}
pub struct AliasTy<I: Interner> {
pub args: I::GenericArgs,
pub kind: AliasTyKind<I>,
}
pub enum TyKind<I: Interner> {
...
Alias(AliasTy<I>),
}
```
... and then does a thousand other changes to accommodate for this change everywhere.
This brings us closer to being able to have `AliasTyKind`s which don't require a `DefId` (and thus can be more easily created, etc). Although notably we depend on both `AliasTyKind -> DefId` and `DefId -> AliasTyKind` conversions in a bunch of places still.
r? lcnr
----
A lot of these changes were done either by search & replace (via `ast-grep`) or on auto pilot, so I'm not quite sure I didn't mess up somewhere, but at least tests pass...
When explicitly re-exporting a declarative macro by name, rustdoc
previously bypassed intermediate re-exports and dropped `#[doc(inline)]`
attributes, causing the macro to be incorrectly stripped if the original
definition was `#[doc(hidden)]`.
This updates `generate_item_with_correct_attrs` to walk the
`reexport_chain` specifically for declarative macros, allowing them to
inherit inline attributes exactly as glob imports do, while preserving
strict visibility rules for standard items.
compiletest: Remove `rfail` support from incremental tests
Incremental revisions beginning with `rfail` would cause the incremental test runner to build the test program, expecting success, and then run the test program, expecting failure.
Expecting incremental tests to fail at runtime is of questionable utility, because in almost all cases an equivalent test program can be made to succeed at runtime instead.
Removing `rfail` support is a small step towards cleaning up compiletest's incremental test runner, and its overall handling of pass/fail expectations.
There was one existing regression test using `rfail` revisions: `tests/incremental/issue-80691-bad-eval-cache.rs`. The test code is complex, and reverting the fix in rust-lang/rust#83220 does not actually cause the test to fail, suggesting that it is no longer a useful regression test. This PR therefore deletes that test.
(An earlier draft of this PR ported the test to run-make, but now it has been removed entirely.)
This annotates the `Rc` type with the diagnostic attribute
`#[diagnostic::on_move]`. Now when a moved `Rc` is borrowed,
a suggestion to clone it is made, with a label explaining why.
Mark method receivers in builtin derives as being from the derive.
Another small annoyance while working on clippy. This was clearly using the root context on purpose, but it also has no reason to do so. All the uses of the receiver are generated by the macros so they can just use the marked context rather than the root.
This fixes a stable-to-stable regression where constants of type
`ManuallyDrop<T>` would not be allowed to be used as a pattern due to
`MaybeDangling<T>` in `ManuallyDrop<T>` not implementing
`StructuralPartialEq`.
bors