-
Notifications
You must be signed in to change notification settings - Fork 13.4k
[WIP] On-demandify region mapping #41327
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
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