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
nr2.0: Add ForeverStack
data structure.
#2344
Conversation
|
||
/** | ||
|
||
Let's look at our stack for resolving and traversing the following Rust code: |
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 think all those comments would make a good wiki page. That doesn't mean we should delete them from the code though.
// So what do we do here - if the Rib has already been pushed in an earlier | ||
// pass, we might end up in a situation where it is okay to re-add new names. | ||
// Do we just ignore that here? Do we keep track of if the Rib is new or not? | ||
// should our cursor have info on the current node like "is it newly pushed"? |
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.
We could encode such information in the type system, mutating a YoungNode into an Grownode, this would prevent state in the cursor as well as state in the node, once grown there would be no way back.
Just throwing random ideas around, don't mind me 😆
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 like it, just style nits. I think keeping logging in is a good idea. just need to change them to rust_debug lines
|
||
// You should have received a copy of the GNU General Public License | ||
// along with GCC; see the file COPYING3. If not see | ||
// <http://www.gnu.org/licenses/>. |
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.
Why do we have two headers? Not sure i like the .hxx extension. Would prefer a different name or combine the header.
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.
Tbh hxx for template only implementations is pretty standard. We've discussed them a bit in the past with @CohenArthur and agreed on not using them when there is a non templated implementation, no .hxx
file should exist along a .cc
file for a same given header file.
I believe that when handled correctly those might reduce compile time, do not quote me on that though as they're included anyway with the header ?
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.
Let's talk about this tomorrow during the community call :)
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.
By chance, I've just found that @rsandifo-arm's commit 73b7582 "Add rtl-ssa" did add *.inl
files for what appears to be a similar purpose (from a quick look)?
gccrs/gcc/rtl-ssa/internals.inl
Line 1 in 73b7582
// Implementation of private inline member functions for RTL SSA -*- C++ -*- |
Line 1 in 73b7582
// is_a<> support for RTL SSA classes -*- C++ -*- |
gccrs/gcc/rtl-ssa/member-fns.inl
Lines 20 to 26 in 73b7582
// This file contains inline implementations of public member functions that | |
// are too large to be written in the class definition. It also contains | |
// some non-inline template definitions of public member functions. | |
// See the comments above the function declarations for details. | |
// | |
// The file also contains the bare minimum of private and protected inline | |
// member functions that are needed to make the public functions compile. |
(I have no opinion on *.inl
vs *.hxx
.)
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.
oh, interesting. I didn't know that was an option. I think *.inl
looks a little less C++y than *.hxx
but I'm not opposed to it
auto next = std::string (indentation + 4, ' '); | ||
auto next_next = std::string (indentation + 8, ' '); | ||
|
||
std::cerr << indent << "Node {\n" |
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 think logging is really useful but it should be rust_debug lines.
*/ | ||
void pop (); | ||
|
||
/** |
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.
There was #1638 , but it's getting killed for good reasons. But do we want to enforce some kind of comments for new comments? Using /** ... */
with doxygen style tags are fine. I was wondering how to properly document other changes.
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.
This is the way I prefer, but I'm fine with other styles. As long as I can write @return
and see it get highlighted in my editor, I'm happy haha
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.
What do you use for an editor?
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.
6824522
to
3c05c87
Compare
For debugging, I went with an |
a0aa199
to
a3d0b29
Compare
This data structure replaces our existing scopes and allows for multiple name resolution passes to insert definitions or look up names at different stages of the pipeline. The documentation goes into detail about how the data structure works, and how the source's hierarchy is preserved throughout the pipeline. The class is templated to enforce specific behavior based on the namespace the scope map targets. gcc/rust/ChangeLog: * resolve/rust-forever-stack.h: New file. * resolve/rust-forever-stack.hxx: New file.
This data structure replaces our existing scopes and allows for multiple
name resolution passes to insert definitions or look up names at different
stages of the pipeline. The documentation goes into detail about how the
data structure works, and how the source's hierarchy is preserved
throughout the pipeline.
The class is templated to enforce specific behavior based on the namespace
the scope map targets.
gcc/rust/ChangeLog:
Needs #2327 and #2317