about summary refs log tree commit diff
path: root/compiler/rustc_infer/src/infer
AgeCommit message (Collapse)AuthorLines
2023-04-06Remove index from BrAnonJack Huey-6/+6
2023-04-06Don't use BrAnon index in diagnosticsJack Huey-2/+2
2023-04-06Use BoundTy and BoundRegion instead of kind of PlaceholderTy and ↵Jack Huey-27/+43
PlaceholderRegion
2023-04-07Rollup merge of #109957 - fmease:fix-109905, r=petrochenkovMatthias Krüger-1/+4
diagnostics: account for self type when looking for source of unsolved type variable Fixes #109905. When searching for the source of an unsolved infer var inside of a list of generic args, we look through the `tcx.generics_of(…).own_substs(…)` which *skips* the self type if present. However, the computed `argument_index` is later[^1] used to index into `tcx.generics_of(…).params` which may still contain the self type. In such case, we are off by one when indexing into the parameters. From now on, we account for this immediately after calling `own_substs` which keeps things local. This also fixes the wrong output in the preexisting UI test `inference/need_type_info/concrete-impl.rs` which was overlooked. It used to claim that the *type of type parameter `Self`* couldn't be inferred in `<Struct as Ambiguous<_>>::method()` which of course isn't true: `Self` equals `Struct` here, `A` couldn't be inferred. `@rustbot` label A-diagnostics [^1]: https://github.com/rust-lang/rust/blob/f98a2718141593fbb8dbad10acc537786d748156/compiler/rustc_infer/src/infer/error_reporting/need_type_info.rs#L471
2023-04-05account for self type when looking for source of unsolved ty varLeón Orell Valerian Liehr-1/+4
2023-04-04Rollup merge of #109913 - scottmcm:index-slice, r=WaffleLapkinMichael Goulet-1/+1
Doc-comment `IndexVec::from_elem` and use it in a few more places Since this PR is a reply to https://github.com/rust-lang/rust/pull/109819#discussion_r1156128164, r? ``@WaffleLapkin``
2023-04-04Now passes testsIQuant-1/+2
2023-04-04Rename tuple_wrap_err_subdiag to suggest_wrap_to_build_a_tuple, making it ↵IQuant-4/+4
more consistent with similar functions
2023-04-04Extract suggest_specify_actual_length into a separate functionIQuant-59/+61
2023-04-04A more general implementation of `IntoDiagnosticArg` for `Binder` (Also ↵IQuant-3/+3
removes `DiagArg`, as it's no longer necessary)
2023-04-04Renamed TypeErrorAdditionalDiags (was Error0308Subdiags) and ↵IQuant-34/+38
ObligationCauseFailureCode (was FailureCodeDiagnostics)
2023-04-04Move and document escape_literal functionIQuant-19/+22
2023-04-04Update compiler/rustc_infer/src/infer/error_reporting/suggest.rsIQuant-1/+1
Co-authored-by: David Wood <agile.lion3441@fuligin.ink>
2023-04-04Migrate (most of) report_and_explain_type_errorIQuant-213/+216
2023-04-04FailureCode::Error0038 is unreachable, so can be removedIQuant-6/+0
2023-04-04Migrate TupleTrailingCommaSuggestionIQuant-14/+11
2023-04-04Migrate SuggestTuplePatternIQuant-23/+14
2023-04-04Migrate SuggestBoxingForReturnImplTrait, Fix typo in infer_fn_consider_castingIQuant-20/+16
2023-04-04Migrate SuggestAccessingFieldIQuant-22/+5
2023-04-04Migrate SuggestAsRefWhereAppropriateIQuant-29/+52
2023-04-04Ported FunctionPointerSuggestionIQuant-21/+10
2023-04-04Remove intercrate and mark_ambiguous from RelationMichael Goulet-87/+12
2023-04-03Doc-comment `IndexVec::from_elem` and use it in a few more placesScott McMurray-1/+1
2023-04-02Use `&IndexSlice` instead of `&IndexVec` where possibleScott McMurray-3/+3
All the same reasons as for `[T]`: more general, less pointer chasing, and `&mut IndexSlice` emphasizes that it doesn't change *length*.
2023-04-02Rollup merge of #109846 - matthiaskrgr:clippy2023_04_III, r=NilstriebNilstrieb-1/+1
more clippy::complexity fixes (iter_kv_map, map_flatten, nonminimal_bool)
2023-04-01fix clippy::iter_kv_mapMatthias Krüger-1/+1
2023-04-01a couple clippy::complexity fixesMatthias Krüger-9/+5
map_identity filter_next option_as_ref_deref unnecessary_find_map redundant_slicing unnecessary_unwrap bool_comparison derivable_impls manual_flatten needless_borrowed_reference
2023-03-31Auto merge of #109165 - aliemjay:fix-ice-annotation, r=davidtwcobors-2/+2
allow ReError in CanonicalUserTypeAnnotation Why not? we already allow `TyKind::Error`. Fixes #109072.
2023-03-31allow ReError in CanonicalUserTypeAnnotationAli MJ Al-Nasrawy-2/+2
2023-03-30Update `ty::VariantDef` to use `IndexVec<FieldIdx, FieldDef>`Scott McMurray-1/+2
And while doing the updates for that, also uses `FieldIdx` in `ProjectionKind::Field` and `TypeckResults::field_indices`. There's more places that could use it (like `rustc_const_eval` and `LayoutS`), but I tried to keep this PR from exploding to *even more* places. Part 2/? of https://github.com/rust-lang/compiler-team/issues/606
2023-03-28Rollup merge of #109629 - aliemjay:remove-givens, r=lcnrnils-129/+21
remove obsolete `givens` from regionck Revives #107376. The only change is the last commit (https://github.com/rust-lang/rust/pull/109629/commits/2a3177a8bcc4c5a5285dc2908a0f1ce98e9a6377) which should fix the regression. Fixes https://github.com/rust-lang/rust/issues/106567 r? `@lcnr`
2023-03-28Rollup merge of #102472 - lcnr:static-in-eval, r=jackh726nils-20/+4
stop special-casing `'static` in evaluation fixes #102360 I have no idea whether this actually removed all places where `'static` matters. Without canonicalization it's very easy to accidentally rely on `'static` again. Blocked on changing the `order_dependent_trait_objects` future-compat lint to a hard error r? `@nikomatsakis`
2023-03-26tolerate region vars in implied boundsAli MJ Al-Nasrawy-1/+4
See https://github.com/rust-lang/rust/issues/109628.
2023-03-26exhaustive match on implied bounds regionsAli MJ Al-Nasrawy-15/+8
2023-03-26remove obsolete `givens` from regionckAli MJ Al-Nasrawy-126/+22
2023-03-25fix type suggestions in match armsLukas Markeffsky-1/+2
2023-03-23Auto merge of #109517 - matthiaskrgr:rollup-m3orqzd, r=matthiaskrgrbors-11/+59
Rollup of 7 pull requests Successful merges: - #108541 (Suppress `opaque_hidden_inferred_bound` for nested RPITs) - #109137 (resolve: Querify most cstore access methods (subset 2)) - #109380 (add `known-bug` test for unsoundness issue) - #109462 (Make alias-eq have a relation direction (and rename it to alias-relate)) - #109475 (Simpler checked shifts in MIR building) - #109504 (Stabilize `arc_into_inner` and `rc_into_inner`.) - #109506 (make param bound vars visibly bound vars with -Zverbose) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
2023-03-23Rollup merge of #109462 - compiler-errors:alias-relate, r=BoxyUwU,lcnrMatthias Krüger-11/+59
Make alias-eq have a relation direction (and rename it to alias-relate) Emitting an "alias-eq" is too strict in some situations, since we don't always want strict equality between a projection and rigid ty. Adds a relation direction. * I could probably just reuse this [`RelationDir`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_infer/infer/combine/enum.RelationDir.html) -- happy to uplift that struct into middle and use that instead, but I didn't feel compelled to... 🤷 * Some of the matching in `compute_alias_relate_goal` is a bit verbose -- I guess I could simplify it by using [`At::relate`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_infer/infer/at/struct.At.html#method.relate) and mapping the relation-dir to a variance. * Alternatively, I coulld simplify things by making more helper functions on `EvalCtxt` (e.g. `EvalCtxt::relate_with_direction(T, T)` that also does the nested goal registration). No preference. r? ```@lcnr``` cc ```@BoxyUwU``` though boxy can claim it if she wants NOTE: first commit is all the changes, the second is just renaming stuff
2023-03-23Auto merge of #109503 - matthiaskrgr:rollup-cnp7kdd, r=matthiaskrgrbors-2/+2
Rollup of 9 pull requests Successful merges: - #108954 (rustdoc: handle generics better when matching notable traits) - #109203 (refactor/feat: refactor identifier parsing a bit) - #109213 (Eagerly intern and check CrateNum/StableCrateId collisions) - #109358 (rustc: Remove unused `Session` argument from some attribute functions) - #109359 (Update stdarch) - #109378 (Remove Ty::is_region_ptr) - #109423 (Use region-erased self type during IAT selection) - #109447 (new solver cleanup + implement coherence) - #109501 (make link clickable) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
2023-03-23Remove AliasRelationDirection::SupertypeMichael Goulet-12/+30
2023-03-23Rename AliasEq -> AliasRelateMichael Goulet-5/+5
2023-03-23Include relation direction in AliasEq predicateMichael Goulet-3/+33
2023-03-23Auto merge of #108861 - b-naber:eager-nll-type-relating, r=lcnrbors-170/+141
Make NLL Type Relating Eager We previously instantiated bound regions in nll type relating lazily. Making this eager is more consistent with how we handle type relating in [`higher_ranked_sub`](https://github.com/rust-lang/rust/blob/0a3b557d528dd7c8a88ceca6f7dc0699b89a3ef4/compiler/rustc_infer/src/infer/higher_ranked/mod.rs#L28) and should allow us to short circuit in case there's structural equality.
2023-03-22Rollup merge of #109447 - lcnr:coherence, r=compiler-errorsMatthias Krüger-2/+2
new solver cleanup + implement coherence the cleanup: - change `Certainty::unify_and` to consider ambig + overflow to be ambig - rename `trait_candidate_should_be_dropped_in_favor_of` to `candidate_should_be_dropped_in_favor_of` - remove outdated fixme For coherence I mostly just add an ambiguous candidate if the current trait ref is unknowable. I am doing the same for reservation impl where I also just add an ambiguous candidate.
2023-03-23Rollup merge of #109280 - compiler-errors:no-vec-map, r=Mark-SimulacrumDylan DPC-5/+3
Remove `VecMap` Not sure what the use of this data structure is over just using `FxIndexMap` or a `Vec`. r? ```@ghost```
2023-03-22eager nll type relatingb-naber-170/+104
2023-03-22assertion for only collection nll region variable information for debug in ↵b-naber-0/+37
non-canonicalization contexts
2023-03-22stop special-casing `'static` in evaluatelcnr-20/+4
2023-03-21Auto merge of #109453 - matthiaskrgr:rollup-odn02wu, r=matthiaskrgrbors-4/+13
Rollup of 8 pull requests Successful merges: - #96391 (Windows: make `Command` prefer non-verbatim paths) - #108164 (Drop all messages in bounded channel when destroying the last receiver) - #108729 (fix: modify the condition that `resolve_imports` stops) - #109336 (Constrain const vars to error if const types are mismatched) - #109403 (Avoid ICE of attempt to add with overflow in emitter) - #109415 (Refactor `handle_missing_lit`.) - #109441 (Only implement Fn* traits for extern "Rust" safe function pointers and items) - #109446 (Do not suggest bounds restrictions for synthesized RPITITs) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
2023-03-21Rollup merge of #109336 - compiler-errors:constrain-to-ct-err, r=BoxyUwUMatthias Krüger-4/+13
Constrain const vars to error if const types are mismatched When equating two consts of different types, if either are const variables, constrain them to the correct const error kind. This helps us avoid "successfully" matching a const against an impl signature but leaving unconstrained const vars, which will lead to incremental ICEs when we call const-eval queries during const projection. Fixes #109296 The second commit in the stack fixes a regression in the first commit where we end up mentioning `[const error]` in an impl overlap error message. I think the error message changes for the better, but I could implement alternative strategies to avoid this without delaying the overlap error message... r? `@BoxyUwU`
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-07-13 16:14:16 +0000