Conversation
| Indeterminate(Span), | ||
| ModuleOnly(Span), |
There was a problem hiding this comment.
I tried to generate those errors, but I wasn't able to generate them. Probably some weird edge-case.
Let's keep them.
deed8e1 to
596133b
Compare
|
Thanks for the review! |
596133b to
40df631
Compare
There was a problem hiding this comment.
Looks good to me. I will let @jhpratt do the final review.
|
|
||
| ItemKind::Enum(ident, _, _) | ItemKind::Trait(box ast::Trait { ident, .. }) => { | ||
| ItemKind::Trait(box ast::Trait { ident, ref impl_restriction, .. }) => { | ||
| let impl_restriction = self.resolve_impl_restriction(impl_restriction); |
There was a problem hiding this comment.
build_reduced_graph is the most inappropriate place for resolving names, item visibilities are resolved here only out of necessity, and it still causes issues (like #60552 and similar).
Visibilities in restrictions are not necessary for putting declarations into modules, so these visibilities should be safely resolve-able in somewhere in late.rs without adding hacks that this PR adds.
There was a problem hiding this comment.
rust/compiler/rustc_resolve/src/late.rs
Lines 2804 to 2821 in 40df631
Maybe I should resolve and add impl restrictions here?
There was a problem hiding this comment.
Yes, that looks like the right place.
This PR is linked to a GSoC proposal and is part of the progress toward implementing
implrestrictions proposed in RFC 3323.This PR implements the lowering of
implrestriction information torustc_middle.The UI tests cover path resolution errors, except for
RestrictionResolutionError::ModuleOnlyandRestrictionResolutionError::Indeterminate, as it seemed to be no existing UI tests for their visibility counterparts (ModuleOnlyandIndeterminate).This implementation basically follows the pattern used in #141754. It also introduces the enum
RestrictionTargetincompiler/rustc_resolve/src/lib.rsto allow error handling to be shared withmutrestrictions that will be added later.r? @Urgau
cc @jhpratt