[PATCH] D72914: [FileCheck] Strengthen error checks in unit tests

James Henderson via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Jan 23 01:33:55 PST 2020


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

LGTM.



================
Comment at: llvm/unittests/Support/FileCheckTest.cpp:206
+  handleAllErrors(std::move(Err), [&](const ErrorT &E) {
+    EXPECT_NE(E.message().find(ExpectedMsg.str()), std::string::npos);
+  });
----------------
thopre wrote:
> jhenderson wrote:
> > thopre wrote:
> > > jhenderson wrote:
> > > > Would `EXPECT_EQ(ExpectedMsg, E.message())`  be more precise?
> > > A lot of the diagnostics span several lines because they come with a location information. Matching the exact message means you'd have to provide all this in the string to check against. I felt that the error message itself was enough to check which requires a substring match.
> > > 
> > > What do you think?
> > Okay, that's fine. No need to add the additional context in most cases (though you might want a single test that shows location information too).
> Is the intent of a single location check to verify that a given type of error provide location information or to check for a given error that the location is correct?
> 
> If the former I can perhaps use some regex check in expectError and check for a location info for all messages. I'm not sure what we gain if the intent is the latter. Besides, location information in error message is generally already tested in the standard LIT testsuite.
I think if there's sensible lit testing, then that's fine. We should have testing that shows location information is correct somewhere (and depending on how the code path works, it might be appropriate to test each error separately), but there's no need for both lit and unit testing for it, I think.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72914





More information about the llvm-commits mailing list