On demandify region mapping #41662
Merged
On demandify region mapping #41662
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Instead, thread around `Option<CodeExtent>` where applicable.
Make a `CodeExtent<'tcx>` be something allocated in an arena instead of an index into the `RegionMaps`.
Instead of requesting the region maps for the entire crate, request for a given item etc. Several bits of code were modified to take `&RegionMaps` as input (e.g., the `resolve_regions_and_report_errors()` function). I am not totally happy with this setup -- I *think* I'd rather have the region maps be part of typeck tables -- but at least the `RegionMaps` works in a "parallel" way to `FreeRegionMap`, so it's not too bad. Given that I expect a lot of this code to go away with NLL, I didn't want to invest *too* much energy tweaking it.
eddyb
reviewed
May 1, 2017
src/librustc/hir/map/mod.rs
Outdated
| @@ -572,6 +572,18 @@ impl<'hir> Map<'hir> { | |||
| } | |||
| } | |||
|
|
|||
| /// Check if the node is a non-closure function item | |||
| pub fn is_fn(&self, id: NodeId) -> bool { | |||
There was a problem hiding this comment.
I would call this is_fn_or_method.
eddyb
reviewed
May 1, 2017
src/librustc/middle/region.rs
Outdated
| _ => { | ||
| let parent_id = tcx.hir.get_parent(fn_node_id); | ||
| let parent_def_id = tcx.hir.local_def_id(parent_id); | ||
| return tcx.region_maps(parent_def_id); |
There was a problem hiding this comment.
There's a way to get the surrounding fn DefId for a closure, I think that should be used instead.
There was a problem hiding this comment.
I think I did not because I specifically wanted this to work for things that are not closures. However, in retrospect, I am not sure if that was right. That is, for things like the E in [T; E], perhaps they do want separate region-maps (as we've been saying on the other PR).
There was a problem hiding this comment.
Yeah, only [x; n] may share an environment with the outer item and that's not supported today.
carols10cents
added
the
S-waiting-on-author
This was a pretty narrow test to start with, and it's kind of a pain to update it. Not worth the trouble IMO.
|
@bors r+ |
|
📌 Commit c008f05 has been approved by |
frewsxcv
added a commit
to frewsxcv/rust
that referenced
this pull request
May 2, 2017
…pping, r=eddyb On demandify region mapping This is an adaptation of @cramertj's PR. I am sort of tempted to keep simplifying it, but also tempted to land it so and we can refactor more in follow-up PRs. As is, it does the following things: - makes the region-maps an on-demand query, per function `tcx.region_maps(def_id)` - interns code extents instead of of having them be integers - remove the "root region extent" and (to some extent) item extents; instead we use `Option<CodeExtent<'tcx>>` in a few places (no space inefficiency since `CodeExtent<'tcx>` is now a pointer). I'm not entirely happy with the way I have it setup though. Here are some of the changes I was considering (I'm not sure if they would work out well): 1. Removing `item_extents` entirely -- they are rarely used now, because most of the relevant places now accept an `Option<Region<'tcx>>` or an `Option<CodeExtent<'tcx>>`, but I think still used in a few places. 2. Merging `RegionMaps` into the typeck tables, instead of having it be its own query. 3. Change `CodeExtent<'tcx>` to store the parent pointer. This would mean that fewer places in the code actually *need* a `RegionMaps` anyhow, since most of them just want to be able to walk "up the tree". On the other hand, you wouldn't be able to intern a `CodeExtent<'tcx>` for some random node-id, you'd need to look it up in the table (since there'd be more information). Most of this code is semi-temporary -- I expect it to largely go away as we move to NLL -- so I'm also not *that* concerned with making it perfect. r? @eddyb
# for free
to join this conversation on GitHub.
Already have an account?
# to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is an adaptation of @cramertj's PR. I am sort of tempted to keep simplifying it, but also tempted to land it so and we can refactor more in follow-up PRs. As is, it does the following things:
tcx.region_maps(def_id)Option<CodeExtent<'tcx>>in a few places (no space inefficiency sinceCodeExtent<'tcx>is now a pointer).I'm not entirely happy with the way I have it setup though. Here are some of the changes I was considering (I'm not sure if they would work out well):
item_extentsentirely -- they are rarely used now, because most of the relevant places now accept anOption<Region<'tcx>>or anOption<CodeExtent<'tcx>>, but I think still used in a few places.RegionMapsinto the typeck tables, instead of having it be its own query.CodeExtent<'tcx>to store the parent pointer. This would mean that fewer places in the code actually need aRegionMapsanyhow, since most of them just want to be able to walk "up the tree". On the other hand, you wouldn't be able to intern aCodeExtent<'tcx>for some random node-id, you'd need to look it up in the table (since there'd be more information).Most of this code is semi-temporary -- I expect it to largely go away as we move to NLL -- so I'm also not that concerned with making it perfect.
r? @eddyb