[PATCH] D98086: [FileCheck] Fix numeric error propagation

[Thomas Preud'homme via Phabricator via llvm-commits]

thopre accepted this revision.
thopre added a comment.
This revision is now accepted and ready to land.

LGTM but maybe you want feedback from James, though he appears very busy



================
Comment at: llvm/test/FileCheck/match-time-error-propagation/matched-excluded-pattern.txt:10-18
+; TODO: Capturing from an excluded pattern probably shouldn't be permitted
+; because it seems useless: it's captured only if the pattern matches, but then
+; FileCheck fails.  The helpfulness of reporting overflow from that capture is
+; perhaps questionable then, but it doesn't seem harmful either.  Anyway, the
+; goal of this test is simply to exercise the error propagation mechanism for a
+; matched excluded pattern.  In the future, if we have a more interesting error
+; to exercise in that case, we should instead use it in this test, and then we
----------------
jdenny wrote:
> thopre wrote:
> > FYI I'd like to make a patch to use APInt in FileCheck to allow numbers bigger than 64bits. I've found the need while working on __builtin_isnan for long double. No timeline and I don't expect to have time on it soon but that would remove the only post-match error unless a new one is added before that. On the other hand I haven't even started that work so I think this testcase should be kept.
> Thanks for mentioning it.  Inequality constraints will fit here, right?  If so, hopefully they'll come first so it's easy to maintain this handling.
Inequality will need code needed for using a variable defined on the same line: the ability of tentatively match a line, set variables etc. and discard if a constraint is not met. I have an old patch that does it but I wanted something more automatic (i.e. require a transaction object to perform a match with a commit method and the destructor would delete everything unless committed. That's the general idea but everytime I try to compartmentalize FileCheck more (e.g. creating a numeric expression parser object) I get into an encapsulation hell with info I need but not easily available. Sorry for renting

Anyway, perhaps it's time for me to get back to the use of var defined on the same line and get closure on that FileCheck numeric expression patchset.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98086/new/

https://reviews.llvm.org/D98086