-
Notifications
You must be signed in to change notification settings - Fork 452
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
Get rid of custom implementation of Utils::PathName #4721
Conversation
asl
commented
Jun 13, 2024
- Switch to std::filesystem::path
- Simplify and cleanup code aroung
- Get rid of (some) cstrings around paths
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.
Conditional approval from my side. It'd be great others also look across this since it impacts back end code.
Also a lot of this code will affect path manipulation. We do not necessarily test that.
// Subpath for bf-p4c-compilers. | ||
options.file = cstring(sourcePath); | ||
options.file += curFile; | ||
// FIXME: what is the logic behind here? |
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 assume this code was written to also work with compilers with a slightly different structure, e.g. the bf-p4c. But not sure what the approach here was there is likely an simpler solution.
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.
Well, the thing is: the code inside the access
condition is equivalent to the code above: we just emitting sourcePath / curFile
. It looks like some leftover from previous changes / refactoring.
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.
Good question. The code on lines 59-60 and 63-64 of the original code are identical.
Since there's nothing unique about this code block, perhaps we should delete the entire if statement?
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.
Hopefully yes, but I just do not know the story behind this code, so maybe something was lost at some point of time.
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.
The oldest commit I can find for this file is #3568. It was at a different point in the tree then and was later moved in a cleanup.
The duplicated code in the if (access(...))
block was present then, so it's nothing that we've accidentally corrupted after it was added to the p4c codebase.
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 feel free to be aggressive with refactorings here. This code is eventually meant to go away anyway since the parser is replaced with the actual p4-constaints parser.
Util::PathName newName(filename.getBasename() + baseSuffix + "." + filename.getExtension()); | ||
auto result = Util::PathName(folder).join(newName.toString()); | ||
return result.toString(); | ||
static std::filesystem::path makeFileName(const std::filesystem::path &folder, |
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.
Folder? What are we, Windows programmers? 🤣
(No change needed -- you're not introducing a new name.)
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, likely the code was copied from somewhere else :)
} | ||
|
||
bool ParserOptions::isv1() const { return langVersion == ParserOptions::FrontendVersion::P4_14; } | ||
|
||
void ParserOptions::dumpPass(const char *manager, unsigned seq, const char *pass, | ||
const IR::Node *node) const { | ||
if (strncmp(pass, "P4::", 4) == 0) pass += 4; | ||
cstring name = cstring(manager) + "_" + Util::toString(seq) + "_" + pass; | ||
std::string name = absl::StrCat(manager, "_", seq, "_", pass); |
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's a shame we can't just use +
instead of having to invoke StrCat
. But I know we can't with the current types of the elements being concatenated.
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.
Yes. Some stdlib implementations even return proxy object as a result operator+ to make things a bit more efficient. But it's not the case here. Anyway, the past code created lots of cstrings for no particular case...
if (filename == "-") filename = "tmp.p4"_cs; | ||
|
||
cstring fileName = makeFileName(dumpFolder, filename, suffix); | ||
std::string suffix = absl::StrFormat("-%04zu-%s", ++dump_uid, name); |
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.
Can absl::StrFormat
be replaced by std::format
when we move to C++20?
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.
Yes, that's the intention. They are not quite compatible, but good thing is that StrFormat
uses printf-style POSIX format strings (so, no new syntax as with boost::format), plus have compile-time checking of them.
auto fileext = cstring(progName.find(".")); | ||
progName = cstring(progName.replace(fileext, cstring::empty)); | ||
progName = progName.trim("/\t\n\r"); | ||
auto progName = options.file.stem(); |
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.
Nice! Much more compact using std::filesystem::path.
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.
Lot's of similar code everywhere. In different combinations and variations.
@@ -124,7 +124,7 @@ class Graphs : public Inspector { | |||
boost::edge_attribute_t, GraphvizAttributes, | |||
boost::property<boost::edge_name_t, cstring, boost::property<boost::edge_index_t, int>>>; | |||
using graphProperties = boost::property< | |||
boost::graph_name_t, cstring, | |||
boost::graph_name_t, std::string, |
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's the impact of this switch? Is there any noticeable memory impact?
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.
These are transient attributes, so it does make sense to store them inside graph, not on the side. Simplifies logs here and here.
// Subpath for bf-p4c-compilers. | ||
options.file = cstring(sourcePath); | ||
options.file += curFile; | ||
// FIXME: what is the logic behind here? |
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.
Good question. The code on lines 59-60 and 63-64 of the original code are identical.
Since there's nothing unique about this code block, perhaps we should delete the entire if statement?
I should also add that I'm okay with the changes. Will give Vladimir some time in case he has any feedback. Feel free to ping me if the merge is urgent and I'll approve. |
Ok, I removed that FIXME and duplicated code. @vlstill Will you please check when you have a chance? |
I'll approve tomorrow if we don't hear back from Vladimir. Feel free to ping me if I seem to have forgotten 🙂 |
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.
Approved 🙂
- Switch to std::filesystem::path - Simplify and cleanup code aroung - Get rid of (some) cstrings around paths
@fruffy it looks CI is unhappy:
|
Seems like we are running into actions/runner-images#9679 Edit: Turns out this might just be an outage https://status.canonical.com/#/incident/KNms6QK9ewuzz-7xUsPsNylV20jEt5kyKsd8A-3ptQG9fRkoWF_tPwQo3xO6l_CBViNLhdmwjQX92RChV_TTHQ== |
Something like this to be added:
? |
We already have this here: https://github.com/p4lang/p4c/blob/main/tools/ci-build.sh#L123 |
It is guarded by |
No I think the CI build is failing at that particular line. We will probably see the same behavior in the Ubuntu 18 run. |
This ended ~2 hours ago. The failure is fresh. |