about summary refs log tree commit diff
path: root/compiler/rustc_hir_analysis/src
AgeCommit message (Collapse)AuthorLines
2025-01-14Add hir::HeaderSafety to make follow up commits simplerOli Scherer-6/+11
2025-01-14Add `tcx.visible_traits()` and use it for producing diagnosticsTrevor Gross-1/+1
Add an alternative to `tcx.all_traits()` that only shows traits that the user might be able to use, for diagnostic purposes. With this available, make use of it for diagnostics including associated type errors, which is part of the problem with [1]. Includes a few comment updates for related API. [1]: https://github.com/rust-lang/rust/issues/135232
2025-01-13rm unnecessary `OpaqueTypeDecl` wrapperlcnr-3/+3
2025-01-12Rollup merge of #135378 - compiler-errors:unnecessary-stashing, r=chenyukangMatthias Krüger-16/+9
Remove a bunch of diagnostic stashing that doesn't do anything #121669 removed a bunch of conditional diagnostic stashing/canceling, but left around the `steal` calls which just emitted the error eagerly instead of canceling the diagnostic. I think that these no-op `steal` calls don't do much and are confusing to encounter, so let's remove them. The net effect is: 1. We emit more duplicated errors, since stashing has the side effect of duplicating diagnostics. This is not a big deal, since outside of `-Zdeduplicate-diagnostics=no`, the errors are already being deduplicated by the compiler. 2. It changes the order of diagnostics, since we're no longer stashing and then later stealing the errors. I don't think this matters much for the changes that the UI test suite manifests, and it makes these errors less order dependent.
2025-01-12Rollup merge of #135374 - compiler-errors:typo-trait-method, r=fee1-deadMatthias Krüger-2/+49
Suggest typo fix when trait path expression is typo'ed When users write something like `Default::defualt()` (notice the typo), failure to resolve the erroneous `defualt` item will cause resolution + lowering to interpret this as a type-dependent path whose self type is `Default` which is a trait object without `dyn`, rather than a trait function like `<_ as Default>::default()`. Try to provide a bit of guidance in this situation when we can detect the typo. Fixes https://github.com/rust-lang/rust/issues/135349
2025-01-11Remove a bunch of diagnostic stashing that doesn't do anythingMichael Goulet-16/+9
2025-01-11Suggest typos when trait path expression is typodMichael Goulet-2/+49
2025-01-11rename `BitSet` to `DenseBitSet`Rémy Rakic-2/+2
This should make it clearer that this bitset is dense, with the advantages and disadvantages that it entails.
2025-01-10Rollup merge of #135321 - matthiaskrgr:out_of_into, r=lqdJacob Pratt-1/+1
remove more redundant into() conversions
2025-01-10remove more redundant into() conversionsMatthias Krüger-1/+1
2025-01-09Rename RegionResolutionVisitor to ScopeResolutionVisitorMichael Goulet-12/+12
2025-01-09Make sure to walk into nested const blocks in RegionResolutionVisitorMichael Goulet-4/+8
2025-01-09Rollup merge of #135195 - oli-obk:push-toyoyrupruko, r=lcnrMatthias Krüger-27/+7
Make `lit_to_mir_constant` and `lit_to_const` infallible My motivation for this change is just that it's annoying to check everywhere, especially since all but one call site was just ICEing on errors anyway right there. They can still fail, but now just return an error constant instead of having the caller handle the error. fixes #114317 fixes #126182
2025-01-09Use trait definition cycle detection for trait alias definitions, tooOli Scherer-1/+1
2025-01-09Use option combinators instead of manual if/returnOli Scherer-10/+3
2025-01-09Remove the now-useless `Result` from `lit_to_const`Oli Scherer-6/+3
2025-01-09Always take the `Ok` path in `lit_to_const` and produce error constants insteadOli Scherer-12/+5
2025-01-09Use error constant instead of explicit error handlingOli Scherer-3/+0
2025-01-09Rollup merge of #135269 - estebank:unneeded-into, r=compiler-errorsMatthias Krüger-1/+1
Remove some unnecessary `.into()` calls
2025-01-08Remove some unnecessary `.into()` callsEsteban Küber-1/+1
2025-01-08Rename PatKind::Lit to ExprOli Scherer-1/+1
2025-01-08Exhaustively handle expressions in patternsOli Scherer-22/+20
2025-01-08Don't allow DispatchFromDyn impls that transmute ZST to non-ZSTMichael Goulet-13/+13
2025-01-08Don't allow transmuting ZSTs in dispatch_from_dyn implMichael Goulet-4/+13
2025-01-07Rollup merge of #134989 - max-niederman:guard-patterns-hir, r=oli-obkMatthias Krüger-1/+4
Lower Guard Patterns to HIR. Implements lowering of [guard patterns](https://rust-lang.github.io/rfcs/3637-guard-patterns.html) (see the [tracking issue](#129967)) to HIR.
2025-01-06Rollup merge of #134742 - compiler-errors:post-borrowck-analysis, r=lcnrMatthias Krüger-8/+15
Use `PostBorrowckAnalysis` in `check_coroutine_obligations` This currently errors with: ``` error: concrete type differs from previous defining opaque type use --> tests/ui/coroutine/issue-52304.rs:10:21 | 10 | pub fn example() -> impl Coroutine { | ^^^^^^^^^^^^^^ expected `{example::{closure#0} upvar_tys=() resume_ty=() yield_ty=&'{erased} i32 return_ty=() witness={example::{closure#0}}}`, got `{example::{closure#0} upvar_tys=() resume_ty=() yield_ty=&'static i32 return_ty=() witness={example::{closure#0}}}` | = note: previous use here ``` This is because we end up redefining the opaque in `check_coroutine_obligations` but with the `yield_ty = &'erased i32` from hir typeck, which causes the *equality* check for opaques to fail. The coroutine obligtions in question (when `-Znext-solver` is enabled) are: ``` Binder { value: TraitPredicate(<Opaque(DefId(0:5 ~ issue_52304[4c6d]::example::{opaque#0}), []) as std::marker::Sized>, polarity:Positive), bound_vars: [] } Binder { value: AliasRelate(Term::Ty(Alias(Opaque, AliasTy { args: [], def_id: DefId(0:5 ~ issue_52304[4c6d]::example::{opaque#0}), .. })), Equate, Term::Ty(Coroutine(DefId(0:6 ~ issue_52304[4c6d]::example::{closure#0}), [(), (), &'{erased} i32, (), CoroutineWitness(DefId(0:6 ~ issue_52304[4c6d]::example::{closure#0}), []), ()]))), bound_vars: [] } Binder { value: AliasRelate(Term::Ty(Coroutine(DefId(0:6 ~ issue_52304[4c6d]::example::{closure#0}), [(), (), &'{erased} i32, (), CoroutineWitness(DefId(0:6 ~ issue_52304[4c6d]::example::{closure#0}), []), ()])), Subtype, Term::Ty(Alias(Opaque, AliasTy { args: [], def_id: DefId(0:5 ~ issue_52304[4c6d]::example::{opaque#0}), .. }))), bound_vars: [] } ``` Ignoring the fact that we end up stalling some really dumb obligations here (lol), I think it makes more sense for us to be using post borrowck analysis for this check anyways. r? lcnr
2025-01-06footnote to ordinary commentlcnr-15/+15
2025-01-04Rollup merge of #135046 - RalfJung:rustc_box_intrinsic, r=compiler-errorsJubilee-0/+3
turn rustc_box into an intrinsic I am not entirely sure why this was made a special magic attribute, but an intrinsic seems like a more natural way to add magic expressions to the language.
2025-01-04Auto merge of #135031 - RalfJung:intrinsics-without-body, r=oli-obkbors-15/+15
rustc_intrinsic: support functions without body We synthesize a HIR body `loop {}` but such bodyless intrinsics. Most of the diff is due to turning `ItemKind::Fn` into a brace (named-field) enum variant, because it carries a `bool`-typed field now. This is to remember whether the function has a body. MIR building panics to avoid ever translating the fake `loop {}` body, and the intrinsic logic uses the lack of a body to implicitly mark that intrinsic as must-be-overridden. I first tried actually having no body rather than generating the fake body, but there's a *lot* of code that assumes that all function items have HIR and MIR, so this didn't work very well. Then I noticed that even `rustc_intrinsic_must_be_overridden` intrinsics have MIR generated (they are filled with an `Unreachable` terminator) so I guess I am not the first to discover this. ;) r? `@oli-obk`
2025-01-04turn hir::ItemKind::Fn into a named-field variantRalf Jung-15/+15
2025-01-04Rollup merge of #135055 - compiler-errors:rpitit-infer-in-stricter-impl, ↵Matthias Krüger-0/+20
r=estebank Report impl method has stricter requirements even when RPITIT inference gets in the way See the comment I added in the code. Fixes #122506.
2025-01-04Auto merge of #135057 - compiler-errors:project-unconstrained, r=oli-obkbors-31/+94
Project to `TyKind::Error` when there are unconstrained non-lifetime (ty/const) impl params It splits the `enforce_impl_params_are_constrained` function into lifetime/non-lifetime, and queryfies the latter. We can then use the result of the latter query (`Result<(), ErrorGuaranteed>`) to intercept projection and constrain the projected type to `TyKind::Error`, which ensures that we leak no ty or const vars to places that don't expect them, like `normalize_erasing_regions`. The reason we split `enforce_impl_params_are_constrained` into two parts is because we only error for *lifetimes* if the lifetime ends up showing up in any of the associated types of the impl (e.g. we allow `impl<'a> Foo { type Assoc = (); }`). However, in order to compute the `type_of` query for the anonymous associated type of an RPITIT, we need to do trait solving (in `query collect_return_position_impl_trait_in_trait_tys`). That would induce cycles. Luckily, it turns out for lifetimes we don't even care about if they're unconstrained, since they're erased in all contexts that we are trying to fix ICEs. So it's sufficient to keep this check separated out of the query. I think this is a bit less invasive of an approach compared to #127973. The major difference between this PR and that PR is that we queryify the check instead of merging it into the `explicit_predicates_of` query, and we use the result to taint just projection goals, rather than trait goals too. This doesn't require a lot of new tracking in `ItemCtxt` and `GenericPredicates`, and it also seems to not require any other changes to typeck like that PR did. Fixes #123141 Fixes #125874 Fixes #126942 Fixes #127804 Fixes #130967 r? oli-obk
2025-01-03turn rustc_box into an intrinsicRalf Jung-0/+3
2025-01-03Do not project when there are unconstrained impl paramsMichael Goulet-31/+94
2025-01-03Report impl has stricter requirements even when RPITIT inference gets in the wayMichael Goulet-0/+20
2025-01-02Fix macro shenanigansMichael Goulet-2/+11
2025-01-02Make suggestion verbose and tweak error messageMichael Goulet-2/+2
2025-01-02Suppress type param suggestion if encountering invalid const inferMichael Goulet-23/+52
2025-01-02Unconditionally lower generic_arg_inferMichael Goulet-1/+16
2025-01-02More refined spans for placeholder error in const/staticMichael Goulet-2/+11
2025-01-02Remove diagnostic_only_typeck and fix placeholder suggestion for const/staticMichael Goulet-1/+1
2025-01-02nit: Make get_infer_ret_ty name more consistent with is_suggestable_infer_tyMichael Goulet-2/+2
2025-01-01Rollup merge of #135000 - compiler-errors:opaque-captures-dupe, r=lqdMatthias Krüger-1/+4
Fix ICE when opaque captures a duplicated/invalid lifetime See description on test. Fixes #132766 Fixes #133693 Fixes #134780
2025-01-01Fix ICE when opaque captures a duplicated/invalid lifetimeMichael Goulet-1/+4
2024-12-31add guard patterns to HIR and implement loweringMax Niederman-1/+4
2024-12-30Auto merge of #134757 - RalfJung:const_swap, r=scottmcmbors-1/+3
stabilize const_swap libs-api FCP passed in https://github.com/rust-lang/rust/issues/83163. However, I only just realized that this actually involves an intrinsic. The intrinsic could be implemented entirely with existing stable const functionality, but we choose to make it a primitive to be able to detect more UB. So nominating for `@rust-lang/lang` to make sure they are aware; I leave it up to them whether they want to FCP this. While at it I also renamed the intrinsic to make the "nonoverlapping" constraint more clear. Fixes #83163
2024-12-27Move `{widening, carrying}_mul` to an intrinsic with fallback MIRScott McMurray-0/+5
Including implementing it for `u128`, so it can be defined in `uint_impl!`. This way it works for all backends, including CTFE.
2024-12-25rename typed_swap → typed_swap_nonoverlappingRalf Jung-1/+3
2024-12-25Use PostBorrowckAnalysis in check_coroutine_obligationsMichael Goulet-8/+15
2024-12-22Begin to implement type system layer of unsafe bindersMichael Goulet-9/+16