-
Notifications
You must be signed in to change notification settings - Fork 162
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
Add ForeverStackStore
#3251
base: master
Are you sure you want to change the base?
Add ForeverStackStore
#3251
Conversation
d3836c3
to
3c27f41
Compare
@CohenArthur @P-E-P @philberty thoughts? |
I'm mostly fine with this idea, but I've not yet finished reviewing it entirely. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks good, although I'd like @CohenArthur to review this PR because he's the one who brought ForeverStack
in the first place and should have a better insight.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have style nits but up to @CohenArthur on that one or @tschwinge or @dkm to make it GCC Style
{ | ||
Node *tmp = this; | ||
|
||
while (true) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
while true is something we should be wary of doing i think it would be btter to do something like:
bool keep_going = lambda ();
while (keep_going == KeepGoing::Yes) {
}
I just think its better to avoid just flat out while (true) but thats my style preference
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, lambda () == KeepGoing::Yes
should probably just be the loop condition
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've tweaked it to use a for
loop now -- the condition is a bit odd, but it should be succinct
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not against the PR, I think the code looks good but I am having a hard time wrapping my head around how this could be used. @powerboat9 could you do one big PR containing the ForeverStackStore
and the usage of it by ForeverStack
? I feel like it would help me a lot.
Actually nevermind my comment I just saw you had submitted #3258 as well - I'll review it and then come back to this PR. apologies for the hasty review |
3c27f41
to
868947a
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! if everything @philberty had to say is resolved, then I'm happy to merge this
868947a
to
9c9ba56
Compare
9c9ba56
to
275ce4b
Compare
ForeverStackStore is meant to partially unify the internal states of per-namespace ForeverStack instances. This commit does not contain modifications to ForeverStack which would allow it to rely on a ForeverStackStore to store nodes, but a future commit should address this. gcc/rust/ChangeLog: * Make-lang.in: Handle rust-forever-stack.cc. * resolve/rust-forever-stack.h (class ForeverStackStore): Add. * resolve/rust-forever-stack.cc: New file, based on rust-forever-stack.hxx. Signed-off-by: Owen Avery <[email protected]>
275ce4b
to
2adcc43
Compare
ForeverStackStore
is meant to partially unify the internal states of per-namespaceForeverStack
instances. This PR doesn't contain modifications toForeverStack
which would allow it to rely on aForeverStackStore
to store nodes, but a future PR should address this.