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
Don't store `pattern_ty` in `TestableCase`
This field's only remaining use was in an assertion, but we can perform the same assertion earlier when constructing `TestableCase::Range`.
---
For background, the `pattern_ty` field was introduced in https://github.com/rust-lang/rust/pull/136435 to replace a reference to the full THIR pattern node. Since then, most uses of `pattern_ty` were removed by https://github.com/rust-lang/rust/pull/150238.
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.
remove unnecessary variables and delimiter check
Zulip discussion: https://rust-lang.zulipchat.com/#narrow/channel/182449-t-compiler.2Fhelp/topic/question.20about.20lex_token_tree_open_delim.20in.20rustc_parse/with/580552157
In `lex_token_tree_open_delim`, after calling `self.lex_token_trees(/* is_delimited */ true)`:
- If the delimiters are well-balanced, the value popped from the stack will always equal to `open_delim` and `pre_span`.
- If the delimiters are not balanced, `self.lex_token_trees(/* is_delimited */ true)` will return an error so this branch will not be reached
Therefore `open_delimiter` and `open_delimiter_span` can be removed.
Test `tests/ui/parser` all passed
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.
Deduplication: Pulled common logic out from lower_const_arg_struct
This PR aims to deduplicate the logic in the function `lower_const_arg_struct` by creating a helper function `lower_path_for_struct_expr` which is shared between `rustc_hir_ty_lowering `and `rustc_hir_typeck`.
Related: https://github.com/rust-lang/rust/issues/150621
Helper function code:
```
pub struct ResolvedStructPath<'tcx> {
pub res: Result<Res, ErrorGuaranteed>,
pub ty: Ty<'tcx>,
}
pub fn lower_path_for_struct_expr(
&self,
qpath: hir::QPath<'tcx>,
path_span: Span,
hir_id: HirId,
) -> ResolvedStructPath<'tcx> {
match qpath {
hir::QPath::Resolved(ref maybe_qself, path) => {
let self_ty = maybe_qself.as_ref().map(|qself| self.lower_ty(qself));
let ty = self.lower_resolved_ty_path(self_ty, path, hir_id, PermitVariants::Yes);
ResolvedStructPath { res: Ok(path.res), ty }
}
hir::QPath::TypeRelative(hir_self_ty, segment) => {
let self_ty = self.lower_ty(hir_self_ty);
let result = self.lower_type_relative_ty_path(
self_ty,
hir_self_ty,
segment,
hir_id,
path_span,
PermitVariants::Yes,
);
let ty = result
.map(|(ty, _, _)| ty)
.unwrap_or_else(|guar| Ty::new_error(self.tcx(), guar));
ResolvedStructPath {
res: result.map(|(_, kind, def_id)| Res::Def(kind, def_id)),
ty,
}
}
}
}
```
Thanks to @BoxyUwU for the guidance on this issue.
Store `chunk_domain_size` explicitly in `Chunk`.
Currently we compute it on demand, but it's a little simpler and slightly faster to store it.
r? @ghost
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.
Post-attribute ports cleanup pt. 1
r? @jdonszelmann
This cleans up some checks I could find were for non-parsed attributes, and works towards removing BUILTIN_ATTRIBUTES
All commits do one thing and every commit passes tests, so best reviewed commit by commit
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
Split out the creation of `Cycle` to a new `process_cycle` function
This splits out the creation of `CycleError` to a new `process_cycle` function. This makes it a bit clearer which operations are done for diagnostic purposes vs. what's needed to break cycles.
`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...
Only show the "match arms with guards don't count towards exhaustivity"
note when removing all guards would make the match exhaustive. Previously,
this note was shown whenever all arms had guards, even if the patterns
themselves were insufficient to cover all valid values of a type.
Re-run 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.
Add `#[track_caller]` to some functions which can panic b/c of the
caller's wrong index (this helped me debug some mistakes I did while
refactoring `ty::Alias`)
Move `rustc_middle::mir::mono` to `rustc_middle::mono`
Because the things in this module aren't MIR and don't use anything from `rustc_middle::mir`. Also, modules that use `mono` often don't use anything else from `rustc_middle::mir`.
r? @saethlin
Because the things in this module aren't MIR and don't use anything
from `rustc_middle::mir`. Also, modules that use `mono` often don't use
anything else from `rustc_middle::mir`.
malezjaa