| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Fix invalid slice coercion suggestion reported in turbofish
This PR fixes the invalid slice coercion suggestion reported in turbofish and inferred generics by not emitting them.
Fixes https://github.com/rust-lang/rust/issues/110063
|
|
Tweaks to `adt_sized_constraint`
fixes a comment, but also some other nits.
r? lcnr
|
|
add `dropck_outlives` comments
|
|
|
|
|
|
|
|
|
|
|
|
Detect trait upcasting through struct tail unsizing in new solver select
Oops, we were able to hide trait upcasting behind a parent unsize goal that evaluated to `Certainty::Yes`. Let's do rematching for `Certainty::Yes` unsize goals with `BuiltinImplSource::Misc` sources (corresponding to all of the other unsize rules) to make sure we end up selecting any nested goals which may be satisfied via `BuiltinImplSource::TraitUpcasting` or `::TupleUnsizing`.
r? ``@lcnr``
|
|
refactor builtin unsize handling, extend comments
r? `@compiler-errors`
|
|
|
|
|
|
|
|
r=compiler-errors
make `noop_method_call` warn by default
r? `@compiler-errors`
|
|
|
|
|
|
|
|
|
|
discard default auto trait impls if explicit ones exist (rebase of #85048)
Rebase of #85048
|
|
Remove `constness` from `ParamEnv`
This should be replaced by keyword generics/effects. cc #110395
r? `@oli-obk`
|
|
|
|
Restore region uniquification in the new solver 🎉
All of the bugs that were "due" to uniquification have been settled via other means (e.g. bidirectional alias-relate, param-env incompleteness, etc).
Firstly, revert the functional changes in #110180. 😸
Secondly, we need to ignore regions when considering if a goal has changed (the "has_changed" boolean returned from `evaluate_goal`) -- otherwise, because we're doing region uniquification, we may perpetually consider a goal to be changed. See the UI test I committed for an explanation.
|
|
Don't treat negative trait predicates as always knowable
We don't need this. It was added in #90104 but I don't really know why. It's not sound afaict -- negative trait predicates need the same coherence-ambiguity/orphan check rules as positive ones.
r? `@lcnr`
cc `@spastorino,` do you remember why?
|
|
|
|
This reverts commit 171f5414705194067557cd7b70bd680308b9cced.
|
|
|
|
Double check that hidden types match the expected hidden type
Fixes https://github.com/rust-lang/rust/issues/113278 specifically, but I left a TODO for where we should also add some hardening.
It feels a bit like papering over the issue, but at least this way we don't get unsoundness, but just surprising errors. Errors will be improved and given spans before this PR lands.
r? `@compiler-errors` `@lcnr`
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Rollup of 8 pull requests
Successful merges:
- #113969 (add dynamic for smir)
- #113985 (Use erased self type when autoderefing for trait error suggestion)
- #113987 (Comment stuff in the new solver)
- #113992 (arm-none fixups)
- #113993 (Optimize format usage)
- #113994 (Optimize format usage)
- #114006 (Update sparc-unknown-none-elf platform README)
- #114021 (Add missing documentation for `Session::time`)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Comment stuff in the new solver
r? `@lcnr`
|
|
Use erased self type when autoderefing for trait error suggestion
Let's not try to pass something from `skip_binder` into autoderef.
Fixes #113951
|
|
Co-authored-by: lcnr <rust@lcnr.de>
|
|
r=GuillaumeGomez,compiler-errors
rustdoc: handle cross-crate RPITITs correctly
Filter out the internal associated types synthesized during the desugaring of RPITITs, they really shouldn't show up in the docs.
This also fixes #113929 since we're no longer invoking `is_impossible_associated_item` (renamed from `is_impossible_method`) which cannot handle them (leading to an ICE). I don't think it makes sense to try to make `is_impossible_associated_item` handle this exotic kind of associated type (CC original author `@compiler-errors).`
@ T-rustdoc reviewers, currently I'm throwing out ITIT assoc tys before cleaning assoc tys at each usage-site. I'm thinking about making `clean_middle_assoc_item` return an `Option<_>` instead and doing the check inside of it to prevent any call sites from forgetting the check for ITITs. Since I wasn't sure if you would like that approach, I didn't go through with it. Let me know what you think.
<details><summary>Explanation on why <code>is_impossible_associated_item(itit_assoc_ty)</code> leads to an ICE</summary>
Given the following code:
```rs
pub trait Trait { fn def<T>() -> impl Default {} }
impl Trait for () {}
```
The generated associated type looks something like (simplified):
```rs
type {opaque#0}<T>: Default = impl Default; // the name is actually `kw::Empty` but this is the `def_path_str` repr
```
The query `is_impossible_associated_item` goes through all predicates of the associated item – in this case `<T as Sized>` – to check if they contain any generic parameters from the (generic) associated type itself. For predicates that don't contain any *own* generics, it does further processing, part of which is instantiating the predicate with the generic arguments of the impl block (which is only correct if they truly don't contain any own generics since they wouldn't get instantiated this way leading to an ICE).
It checks if `parent_def_id(T) == assoc_ty_def_id` to get to know if `T` is owned by the assoc ty. Unfortunately this doesn't work for ITIT assoc tys. In this case, the parent of `T` is `Trait::def` (!) which is the associated function (I'm pretty sure this is very intentional) which is of course not equal to the assoc ty `Trait::{opaque#0}`.
</details>
`@rustbot` label A-cross-crate-reexports
|
|
get_first
single_char_add_str
unnecessary_mut_passed
manual_map
manual_is_ascii_check
|
|
|
|
|
|
|
|
|
|
filter_map_identity
iter_kv_map
needless_question_mark
redundant_at_rest_pattern
filter_next
derivable_impls
|
|
Get rid of subst-relate incompleteness in new solver
We shouldn't need subst-relate if we have bidirectional-normalizes-to in the new solver.
The only potential issue may happen if we have an unconstrained projection like `<Wrapper<?0> as Trait>::Assoc == <Wrapper<T> as Trait>::Assoc` where they both normalize to something that doesn't mention any substs, which would possibly prefer `?0 = T` if we fall back to subst-relate. But I'd prefer if we remove incompleteness until we can determine some case where we need them, and the bidirectional-normalizes-to seems better to have in general.
I can update https://github.com/rust-lang/trait-system-refactor-initiative/issues/26 and https://github.com/rust-lang/trait-system-refactor-initiative/issues/25 once this lands.
r? `@lcnr`
|
|
r=cjgillot
Tweak spans for self arg, fix borrow suggestion for signature mismatch
1. Adjust a suggestion message that was annoying me
2. Fix #112503 by recording the right spans for the `self` part of the `&self` 0th argument
3. Remove the suggestion for adjusting a trait signature on type mismatch, bc that's gonna probably break all the other impls of the trait even if it fixes its one usage :sweat_smile:
|
|
|
|
|
|
This reverts commit 557359f92512ca88b62a602ebda291f17a953002, reversing
changes made to 1e6c09a803fd543a98bfbe1624d697a55300a786.
|
|
Rollup of 4 pull requests
Successful merges:
- #113887 (new solver: add a separate cache for coherence)
- #113910 (Add FnPtr ty to SMIR)
- #113913 (error/E0691: include alignment in error message)
- #113914 (rustc_target: drop duplicate code)
r? `@ghost`
`@rustbot` modify labels: rollup
|
