-
Notifications
You must be signed in to change notification settings - Fork 12.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Explain origin of implicit Sized
obligations and provide suggestions when possible
#85947
Conversation
r? @jackh726 (rust-highfive has picked a reviewer for you, use r? to override) |
ty::AssocKind::Type => { | ||
let default = match tcx.hir().get_if_local(self.def_id) { | ||
Some( | ||
hir::Node::TraitItem(hir::TraitItem { | ||
kind: hir::TraitItemKind::Type(_, Some(ty)), | ||
.. | ||
}) | ||
| hir::Node::ImplItem(hir::ImplItem { | ||
kind: hir::ImplItemKind::TyAlias(ty), | ||
.. | ||
}), | ||
) => { | ||
format!(" = {:?}", ty) | ||
} | ||
_ => String::new(), | ||
}; | ||
format!("type {}{};", self.ident, default) | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This doesn't have a test. It wasn't meant to be in this commit 🤦
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
4a0568e
to
974d94a
Compare
This comment has been minimized.
This comment has been minimized.
974d94a
to
d0b8678
Compare
This comment has been minimized.
This comment has been minimized.
d0b8678
to
996225c
Compare
This comment has been minimized.
This comment has been minimized.
996225c
to
f0086ed
Compare
This comment has been minimized.
This comment has been minimized.
f0086ed
to
3b04c9f
Compare
This comment has been minimized.
This comment has been minimized.
☔ The latest upstream changes (presumably #85954) made this pull request unmergeable. Please resolve the merge conflicts. |
@bors try @rust-timer queue This should likely not be merged as is: the approach of signaling on the predicate isn't great. |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
🔒 Merge conflict This pull request and the master branch diverged in a way that cannot be automatically merged. Please rebase on top of the latest master branch, and let the reviewer approve again. How do I rebase?Assuming
You may also read Git Rebasing to Resolve Conflicts by Drew Blessing for a short tutorial. Please avoid the "Resolve conflicts" button on GitHub. It uses Sometimes step 4 will complete without asking for resolution. This is usually due to difference between how Error message
|
…r=estebank don't suggest unsized indirection in where-clauses Skip where-clauses when suggesting using indirection in combination with `?Sized` bounds on type parameters. Fixes rust-lang#85943. `@estebank` I think this doesn't conflict with your work in rust-lang#85947; please let me know if you'd like me to cherry pick it to a new branch based on yours instead.
956b415
to
ee9375f
Compare
WIP: ordering of `Sized` obligations can affect the presence of the note. Some tweaks needed to make this the best it can be.
…ype to its own note
ee9375f
to
3956224
Compare
@bors try @rust-timer queue |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit 3956224 with merge 847b2268d073e67a8a5f3bebe53ca5846b2fcbe9... |
The job Click to see the possible cause of the failure (guessed by this bot)
|
☀️ Try build successful - checks-actions |
Queued 847b2268d073e67a8a5f3bebe53ca5846b2fcbe9 with parent 46ad16b, future comparison URL. |
Finished benchmarking try commit (847b2268d073e67a8a5f3bebe53ca5846b2fcbe9): comparison url. Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up. @bors rollup=never |
I'm sorry if this is completely off base; I am not completely certain about my understanding of AST lowering and HIR.
To me, this looked like a HIR invariant being violated. I think the Also, I think the existing code that moves the On a hunch, I dumped the
and got something including this (note the repeated
(param name)
(span; path resolution)
(path resolution; trailing fields)
(trailing fields)
(leading fields; bounded_ty)
(span; path resolution)
(path resolution; trailing fields)
(trailing fields)
|
Also, I confirmed a build failure for the stage1
and success with
Same assertion failure:
during
and it looks like f338867 did change some relevant AST lowering code. |
Closing as #85799 has all the commits here, I'll try to land everything together, and split it if asked by reviewer. |
…stebank move implicit `Sized` predicate to end of list In `Bounds::predicates()`, move the implicit `Sized` predicate to the end of the generated list. This means that if there is an explicit `Sized` bound, it will be checked first, and any resulting diagnostics will have a more useful span. Fixes rust-lang#85998, at least partially. ~~Based on rust-lang#85979, but only the last 2 commits are new for this pull request.~~ (edit: rebased) A full fix would need to deal with where-clauses, and that seems difficult. Basically, predicates are being collected in multiple stages, and there are two places where implicit `Sized` predicates can be inserted: once for generic parameters, and once for where-clauses. I think this insertion is happening too early, and we should actually do it only at points where we collect all of the relevant trait bounds for a type parameter. I could use some help interpreting the changes to the stderr output. It looks like reordering the predicates changed some diagnostics that don't obviously have anything to do with `Sized` bounds. Possibly some error reporting code is making assumptions about ordering of predicates? The diagnostics for src/test/ui/derives/derives-span-Hash-*.rs seem to have improved, no longer pointing at the type parameter identifier, but src/test/ui/type-alias-impl-trait/generic_duplicate_param_use9.rs became less verbose for some reason. I also ran into an instance of rust-lang#84970 while working on this, but I kind of expected that could happen, because I'm reordering predicates. I can open a separate issue on that if it would be helpful. `@estebank` this seems likely to conflict (slightly?) with your work on rust-lang#85947; how would you like to resolve that?
…stebank move implicit `Sized` predicate to end of list In `Bounds::predicates()`, move the implicit `Sized` predicate to the end of the generated list. This means that if there is an explicit `Sized` bound, it will be checked first, and any resulting diagnostics will have a more useful span. Fixes rust-lang#85998, at least partially. ~~Based on rust-lang#85979, but only the last 2 commits are new for this pull request.~~ (edit: rebased) A full fix would need to deal with where-clauses, and that seems difficult. Basically, predicates are being collected in multiple stages, and there are two places where implicit `Sized` predicates can be inserted: once for generic parameters, and once for where-clauses. I think this insertion is happening too early, and we should actually do it only at points where we collect all of the relevant trait bounds for a type parameter. I could use some help interpreting the changes to the stderr output. It looks like reordering the predicates changed some diagnostics that don't obviously have anything to do with `Sized` bounds. Possibly some error reporting code is making assumptions about ordering of predicates? The diagnostics for src/test/ui/derives/derives-span-Hash-*.rs seem to have improved, no longer pointing at the type parameter identifier, but src/test/ui/type-alias-impl-trait/generic_duplicate_param_use9.rs became less verbose for some reason. I also ran into an instance of rust-lang#84970 while working on this, but I kind of expected that could happen, because I'm reordering predicates. I can open a separate issue on that if it would be helpful. ``@estebank`` this seems likely to conflict (slightly?) with your work on rust-lang#85947; how would you like to resolve that?
Built on top of #85799. Only last two commits are relevant.