-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
[WIP] On-demandify region mapping #41327
Conversation
One possibility that occurred to me was to change |
@cramertj those are copied around quite frequently, and that would make the data structures much larger. I'll try to take tomorrow and form a more educated opinion. Thanks for the PR! |
@nikomatsakis Yeah, that's why I didn't do it. :) I opened the PR hoping we could come to a better solution. |
☔ The latest upstream changes (presumably #41357) made this pull request unmergeable. Please resolve the merge conflicts. |
Instead, thread around `Option<CodeExtent>` where applicable.
Make a `CodeExtent<'tcx>` be something allocated in an arena instead of an index into the `RegionMaps`.
2eddfa7
to
80d7e3e
Compare
Can't you use something like this to reduce the amount of manual refactoring? http://coccinelle.lip6.fr/ |
@leonardo-m plausibly, if it worked on rust, but I think that what @cramertj and I have been talking about is really more what we want the target code to look like, rather than the churn it takes to get there. That said, I've been doing a lot of refactoring on this PR on a side branch, and I think I'm going to close it for now (I've discussed with @cramertj off line), until I reach some point I am happy with. |
Attempt at #41057
This approach wound up introducing lots of churn, and I'm opening this primarily as an opportunity to discuss the change and see if there's a more principled way to break up region maps.
In particular, I'd like to see if there's a way to keep
CodeExtent
s unique so that functions with access to onlyCodeExtent
s can lookup the associated function. Without this, I'm not sure of the right way to write things likefmt::Debug for CodeExtent
(insrc/librustc/middle/region.rs
), or the cfg-generating (src/librustc/cfg/construct.rs
) or error-reporting (src/librustc/infer/error_reporting/mod.rs
), since they all try to access region maps using only aCodeExtent
, and doing anything else would require a massive refactor (such as adding aNodeId
tonote_and_explain_region
).Thoughts?
r? @nikomatsakis