Both callers of parseNumericVariableDefinition() perform the same extra
check that no character is found after the variable name. This patch
factors out this check into parseNumericVariableDefinition().
Details
Details
Diff Detail
Diff Detail
- Repository
- rL LLVM
Event Timeline
Comment Actions
LGTM, assuming the error position difference is not an issue.
llvm/lib/Support/FileCheck.cpp | ||
---|---|---|
251 ↗ | (On Diff #208093) | Nit: is this needed here? |
llvm/test/FileCheck/numeric-defines-diagnostics.txt | ||
23 ↗ | (On Diff #208093) | It's slightly disconcerting that the column number here has changed. I assume that it's just some difference between the start and end of the string or something? |
llvm/test/FileCheck/numeric-defines-diagnostics.txt | ||
---|---|---|
23 ↗ | (On Diff #208093) | It seems like the diagnostic now points to the invalid character (+) instead of the start of the name. I think this makes more sense. |
llvm/test/FileCheck/numeric-defines-diagnostics.txt | ||
---|---|---|
23 ↗ | (On Diff #208093) | As Alexander said, it was pointing to the start of the variable before (saying basically that the whole "VALUE+2" is an invalid variable name) and is now pointing to the + operator because that's the first unexpected character. |