There is no reason for it to not be a StringRef. Making it one
simplifies existing code, and makes follow-up features easier.
Details
Diff Detail
- Repository
- rCTE Clang Tools Extra
Event Timeline
LGTM aside from one comment. There's a few style nits however, and I think the lambda on one line could use a few newlines for readability.
clang-query/QueryParser.cpp | ||
---|---|---|
39 | I don't think this is the best way of handling it, in fact I'm pretty certain you're leaking memory here. |
Thanks, I ran clang-format, and I'd rather let it be the rulemaker, rather than try to add newlines in the lambdas :).
clang-query/QueryParser.cpp | ||
---|---|---|
39 | Hmm, I didn't know we could get a mem leak with StringRef. Can you explain? |
clang-query/QueryParser.cpp | ||
---|---|---|
33 | I believe returning Line is identical -- you should wind up with the same "begin" pointer for the returned string and a length of zero (because Line must be empty by this point). | |
40 | I don't have a strong preference, but I raised the point because it seems odd to explicitly clear a StringRef and then return a new, different, empty StringRef on the next line. |
clang-query/QueryParser.cpp | ||
---|---|---|
33 | Actually, I can see it by reading the code - P->CompletionPos <= Word.data() in the LexOrCompleteWord ctor woudln't work anymore without this hack. (Working on removing the hack is out of scope of this change). |
clang-query/QueryParser.cpp | ||
---|---|---|
33 | Ok, I see your new comment now. I guess that will work. I don't know the behavior of ltrim and whether it preserves that property. |
clang-query/QueryParser.cpp | ||
---|---|---|
40 | Well, code changes, and Line may not always be empty here. As it is, this communicates that we're returning an empty StringRef and always will (until this line has a reason to change). |
LGTM aside from the nits pointed out; you can fix and commit without another round of review.
Why not just return Line?