-
Notifications
You must be signed in to change notification settings - Fork 12.6k
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
Resolve visibility paths as modules not as types. #109348
Conversation
This comment has been minimized.
This comment has been minimized.
CI is failing. |
is there a test for what happens if the path is valid? |
@bors r+ |
It fixes the ICE, but generally I don't think this is a right thing to do. Paths in trait contexts for example, also do not support unresolved segments, but do not result in ICEs because they are only resolved during late resolution and late resolution uses Right now Ideally |
☀️ Test successful - checks-actions |
Finished benchmarking commit (28b6607): comparison URL. Overall result: ❌✅ regressions and improvements - no action needed@rustbot label: -perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 648.817s -> 649.629s (0.13%) |
Asking for a resolution with
opt_ns = Some(TypeNS)
allows path resolution to look for type-relative paths, leaving unresolved segments behind. However, for visibility paths we really need to look for a module, so we need to passopt_ns = None
.Fixes #109146
r? @petrochenkov