This patch removes the StringOffset and HasStringValue fields from the MIToken struct and simplifies the stringValue method which now returns the new StringValue field.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
Except for removing rawStringValue this entire suggestion was pretty nitpicky anyway, so feel free to ignore if any of this doesn't seem worth it.
lib/CodeGen/MIRParser/MILexer.h | ||
---|---|---|
113 | It seems weird to me that we are adding an operator= (and a non-obvious one at that) for a class that is never really being assigned. It seems like the complexity is coming from the use of MIToken constructor to reinitialize an MIToken. I think it would be simpler to use two explicit calls:
then one of
Conveniently all the existing uses of the MIToken constructors like this are already broken across two lines, so this should not increase the size of the reinitialization source code (but allows deleting code duplicated across these 3 constructors). An even simpler solution is to just use std::string/SmallString and have it always own (not sure how performance-critical this is). Once it grows large enough there should be no further need to reallocate, so it is just a small memcpy cost. |
The updated patch now uses the 'reset' and 'set...' pattern instead of MIToken's constructors as suggested by Sean.
Mark as "Accept" in Phab. (don't think it really matters, but just to be consistent with the LGTM in the previous comment).
It seems weird to me that we are adding an operator= (and a non-obvious one at that) for a class that is never really being assigned. It seems like the complexity is coming from the use of MIToken constructor to reinitialize an MIToken. I think it would be simpler to use two explicit calls:
then one of
Conveniently all the existing uses of the MIToken constructors like this are already broken across two lines, so this should not increase the size of the reinitialization source code (but allows deleting code duplicated across these 3 constructors).
An even simpler solution is to just use std::string/SmallString and have it always own (not sure how performance-critical this is). Once it grows large enough there should be no further need to reallocate, so it is just a small memcpy cost.