| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Thus eliminating a `FIXME` comment.
|
|
The use of `Binder` was removed in the recent #123900, but the comment
wasn't removed at the same time.
|
|
`InferCtxt::next_{ty,const}_var*` all take an origin, but the
`param_def_id` is almost always `None`. This commit changes them to just
take a `Span` and build the origin within the method, and adds new
methods for the rare cases where `param_def_id` might not be `None`.
This avoids a lot of tedious origin building.
Specifically:
- next_ty_var{,_id_in_universe,_in_universe}: now take `Span` instead of
`TypeVariableOrigin`
- next_ty_var_with_origin: added
- next_const_var{,_in_universe}: takes Span instead of ConstVariableOrigin
- next_const_var_with_origin: added
- next_region_var, next_region_var_in_universe: these are unchanged,
still take RegionVariableOrigin
The API inconsistency (ty/const vs region) seems worth it for the
large conciseness improvements.
|
|
|
|
|
|
|
|
Do not ICE on foreign malformed `diagnostic::on_unimplemented`
Fix #124651.
|
|
Don't ICE when we cannot eval a const to a valtree in the new solver
Use `const_eval_resolve` instead of `try_const_eval_resolve` because naming aside, the former doesn't ICE when a value can't be evaluated to a valtree.
r? lcnr
|
|
generalize hr alias: avoid unconstrainable infer vars
fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/108
see inline comments for more details
r? `@compiler-errors` cc `@BoxyUwU`
|
|
|
|
|
|
borrowck: prepopulate opaque storage more eagerly
otherwise we ICE due to ambiguity when normalizing while computing implied bounds.
r? ``@compiler-errors``
|
|
Record impl args in the proof tree in new solver
Rather than rematching them during select.
Also use `ImplSource::Param` instead of `ImplSource::Builtin` for alias-bound candidates, so we don't ICE in `Instance::resolve`.
r? lcnr
|
|
|
|
|
|
Don't consider candidates with no failing where clauses when refining obligation causes in new solver
Improves error messages when we have param-env candidates that don't deeply unify (i.e. after alias-bounds).
r? lcnr
|
|
Prefer lower vtable candidates in select in new solver
Also, adjust the select visitor to only winnow when the *parent* goal is `Certainty::Yes`. This means that we won't winnow in cases when we have any ambiguous inference guidance from two candidates.
r? lcnr
|
|
|
|
|
|
|
|
Record impl args in the proof tree
Weren't recording these since they went through a different infcx method
r? lcnr
|
|
Implement `do_not_recommend` in the new solver
Put the test into `diagnostic_namespace` test folder even though it's not in the diagnostic namespace, because it should be soon.
r? lcnr
cc `@weiznich`
|
|
|
|
|
|
|
|
Use a proof tree visitor to refine the `Obligation` for error reporting in new solver
With the magic of `ProofTreeVisitor`, we can close the gap that we have on `ObligationCause`s being not as descriptive in the new trait solver.
r? lcnr
Needs some work and obviously documentation.
|
|
Fix #124651.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Use `tcx.types.unit` instead of `Ty::new_unit(tcx)`
I don't think there is any need for the function, given that we can just access the `.types`, similarly to all other primitives?
|
|
|
|
|
|
Bump bootstrap compiler to latest beta
https://forge.rust-lang.org/release/process.html#master-bootstrap-update-t-2-day-tuesday
This also cherry-picks d716d72586548963f32e5c8d57c41db0065fa6e0 from the beta branching, to continue to workaround #122758.
r? bootstrap
|
|
|
|
Rewrite select (in the new solver) to use a `ProofTreeVisitor`
We can use a proof tree visitor rather than collecting and recomputing all the nested goals ourselves.
Based on #124415
|
|
|
|
fix `NormalizesTo` proof tree issue
fixes #124422
cc #121848
r? ``@compiler-errors``
|
|
|
|
Cleanup: Replace item names referencing GitHub issues or error codes with something more meaningful
**lcnr** in https://github.com/rust-lang/rust/pull/117164#pullrequestreview-1969935387:
> […] while I know that there's precendent to name things `Issue69420`, I really dislike this as it requires looking up the issue to figure out the purpose of such a variant. Actually referring to the underlying issue, e.g. `AliasMayNormToUncovered` or whatever and then linking to the issue in a doc comment feels a lot more desirable to me. We should ideally rename all the functions and enums which currently use issue numbers.
I've grepped through `compiler/` like crazy and think that I've found all instances of this pattern.
However, I haven't renamed `compute_2229_migrations_*`. Should I?
The first commit introduces an abhorrent and super long name for an item because naming is hard but also scary looking / unwelcoming names are good for things related to temporary-ish backcompat hacks. I'll let you discover it by yourself.
Contains a bit of drive-by cleanup and a diag migration bc that was the simplest option.
r? lcnr or compiler
|
|
Lazily normalize inside trait ref during orphan check & consider ty params in rigid alias types to be uncovered
Fixes #99554, fixes rust-lang/types-team#104.
Fixes #114061.
Supersedes #100555.
Tracking issue for the future compatibility lint: #124559.
r? lcnr
|
|
|
|
|
|
to be uncovered
|
|
Remove many `#[macro_use] extern crate foo` items
This requires the addition of more `use` items, which often make the code more verbose. But they also make the code easier to read, because `#[macro_use]` obscures where macros are defined.
r? `@fee1-dead`
|
