Uh oh!
There was an error while loading. Please reload this page.
Move next node ID to Resolver - #66072
Conversation
Mark-Simulacrum
commented
Nov 4, 2019
cc @petrochenkov -- this is hopefully "obviously correct" but I could imagine us actually wanting to embed the field somewhere other than resolver, I'm not sure. Happy to move it further back or something else. |
This comment has been minimized.
This comment has been minimized.
eadf82a to
60d5f4fComparerust-highfive
commented
Nov 4, 2019
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
Centril
left a comment
There was a problem hiding this comment.
It would be good to include the "why" of this change in the PR description.
There was a problem hiding this comment.
Could we add a method next_node_id on LoweringContext that just delegates to self.resolver so that the diff becomes smaller in case we want to move it again some time?
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Aw :( -- Ideally we should move stuff out of librustc instead of the other direction... perhaps we can move most of this file out of librustc...
There was a problem hiding this comment.
I think it's fine to do so but it's also a pretty involved change (perhaps we want to create a librustc_pretty or something) -- I don't think it should be done in this PR.
There was a problem hiding this comment.
Yea; didn't mean in this PR. :)
bors
commented
Nov 4, 2019
☔ The latest upstream changes (presumably #65835) made this pull request unmergeable. Please resolve the merge conflicts. |
60d5f4f to
5bbcd85Comparerust-highfive
commented
Nov 4, 2019
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
181fafa to
85f08b5Comparenikomatsakis
commented
Nov 8, 2019
@bors r+ |
bors
commented
Nov 8, 2019
📌 Commit 85f08b5 has been approved by |
…omatsakis Move next node ID to Resolver This moves the `next_node_id` method(s) and related tracking information to the resolver. By doing so, we also remove the OneThread and Cell on next_node_id in Session in this move, which means that the new code is simpler and less "interesting" as it doesn't tie itself to a single thread. This required moving some of the pretty-printing logic around, but this was just copying the code without any semantic changes, so it's just a second commit instead of a separate PR; I can polish it up a bit more if desired.
Centril
commented
Nov 9, 2019
Failed in #66231 (comment), @bors r- |
This doesn't migrate the pretty-printing everybody loops, which will be done in the next few commits.
This allows us to query whether PpmEveryBodyLoops is set during expansion and run the everybody loops pass.
This function was only ever called with 1 so there's little point in it; this isn't an expensive operation (essentially a checked add) so we're not really "reserving" anything either.
85f08b5 to
43a7405CompareMark-Simulacrum
commented
Nov 9, 2019
@bors r=nikomatsakis |
bors
commented
Nov 9, 2019
📌 Commit 43a7405 has been approved by |
bors
commented
Nov 10, 2019
Move next node ID to Resolver This moves the `next_node_id` method(s) and related tracking information to the resolver. By doing so, we also remove the OneThread and Cell on next_node_id in Session in this move, which means that the new code is simpler and less "interesting" as it doesn't tie itself to a single thread. This required moving some of the pretty-printing logic around, but this was just copying the code without any semantic changes, so it's just a second commit instead of a separate PR; I can polish it up a bit more if desired.
bors
commented
Nov 10, 2019
☀️ Test successful - checks-azure |
This moves the
next_node_idmethod(s) and related tracking information to the resolver. By doing so, we also remove the OneThread and Cell on next_node_id in Session in this move, which means that the new code is simpler and less "interesting" as it doesn't tie itself to a single thread.This required moving some of the pretty-printing logic around, but this was just copying the code without any semantic changes, so it's just a second commit instead of a separate PR; I can polish it up a bit more if desired.