This is an archive of the discontinued LLVM Phabricator instance.

Add -verify-asm-diags mode to llvm-mc
AcceptedPublic

Authored by olista01 on Dec 7 2016, 3:46 AM.

Details

Summary

Similar to clang's -verify option, this parses comments in the source containing expected diagnostics, and checks that the emitted diagnostics match them. It is intended to be used in tests in the same way as the clang option.

I haven't been able to share any code other than the ParseHelper class with the clang implementation, because clang uses it's own source manager and diagnostic classes, which are different from LLVM's.

Diff Detail

Repository
rL LLVM

Event Timeline

olista01 updated this revision to Diff 80565.Dec 7 2016, 3:46 AM
olista01 retitled this revision from to Add -verify-asm-diags mode to llvm-mc.
olista01 updated this object.
olista01 set the repository for this revision to rL LLVM.
olista01 added a subscriber: llvm-commits.
grimar resigned from this revision.Dec 7 2016, 3:48 AM
grimar removed a reviewer: grimar.

I know nothing about ARM/llvm-mc, sorry.

niravd edited edge metadata.Dec 7 2016, 7:13 AM

I'm not familiar with the historical justification for verify in clang, so this may be obvious, but what do these patches give us? The assembler should be emitting comments in linear order, so I don't see where FileCheck is insufficient or more difficult to write tests with. Is the long term goal to allow checking of included files and modularize testing?

The assembler does not emit errors in source order for errors that are detected after parsing, such as during layout or fixup resolution.

I also think it's easier to write robust tests using this than FileCheck, as you don't have to regex-match the line and column numbers.

niravd added a comment.Dec 7 2016, 8:16 AM

The assembler does not emit errors in source order for errors that are detected after parsing, such as during layout or fixup resolution.

Ah, right. And having the error message come out of order in those cases is natural and better for the user so we shouldn't sort the output messages.

Can you make a test example where we specifically get out-of-order messages?

Otherwise LGTM.

niravd accepted this revision.Dec 7 2016, 8:21 AM
niravd edited edge metadata.
This revision is now accepted and ready to land.Dec 7 2016, 8:21 AM
olista01 updated this revision to Diff 80737.Dec 8 2016, 2:57 AM
olista01 edited edge metadata.

Re-ordered the existing test file to show that the order is no longer important for post-parsing errors, and remove the obsolete comment.

Thanks, I'll commit this once the dependencies are all committed.