This is an archive of the discontinued LLVM Phabricator instance.

[FileCheck] Fix --dump-input implicit pattern location
ClosedPublic

Authored by jdenny on Apr 6 2020, 4:20 PM.

Details

Summary

Currently, --dump-input implies that all --implicit-check-not
patterns appear on line 1 by printing annotations like:

       1: foo bar baz 
not:1         !~~     error: no match expected

This patch changes that to:

          1: foo bar baz 
not:imp1         !~~     error: no match expected

imp1 indicates the first --implicit-check-not pattern.

Diff Detail

Event Timeline

jdenny created this revision.Apr 6 2020, 4:20 PM
Herald added a project: Restricted Project. · View Herald TranscriptApr 6 2020, 4:20 PM
jdenny updated this revision to Diff 255658.Apr 7 2020, 6:20 AM

Applied clang-format.

I'm new to working with Harbormaster. Do I manually force it to re-run after updating a patch?

thopre added a comment.Apr 8 2020, 3:58 PM

I'm new to working with Harbormaster. Do I manually force it to re-run after updating a patch?

I've seen it do it automatically in other phabricator instances but that doesn't seem to be the case here. Might be configuration-dependent. Better force a rebuild to be sure.

llvm/utils/FileCheck/FileCheck.cpp
321–323

Is this going to be stable if a new option that require a buffer gets added? I know the tests would catch this if that's the case but I'd prefer to not have to update this formula.

I'm also confused at the comment. Does it match the formula? All I see in the formula is that the implicit buffer ID is the check file buffer minus one. Does the comment need updating? Actually repeating the formula does not seem useful, I'd rather have an explanation as to why the implicit buffer ID can be obtained with this formula.

jdenny marked an inline comment as done.Apr 8 2020, 4:52 PM

I'm new to working with Harbormaster. Do I manually force it to re-run after updating a patch?

I've seen it do it automatically in other phabricator instances but that doesn't seem to be the case here. Might be configuration-dependent. Better force a rebuild to be sure.

Thanks. I clicked restart. We'll see what happens.

llvm/utils/FileCheck/FileCheck.cpp
321–323

Is this going to be stable if a new option that require a buffer gets added? I know the tests would catch this if that's the case but I'd prefer to not have to update this formula.

Good point. I suppose I could pass around the buffer ID range for implicit buffers.

Of course, if new buffers are added for patterns, this code likely has to be updated to process annotations for those new buffers anyway. But your suggestion would at least address the case where a new buffer is added for some other purpose.

I'm also confused at the comment. Does it match the formula?

It does.

All I see in the formula is that the implicit buffer ID is the check file buffer

It's not the CheckFileBufferID, it's the CheckBufferID. Perhaps I should rename the latter to BufferID so it's more distinct?

minus one.

I could rewrite it as - 2 + 1. That is, - 2 is for the input file buffer and check file buffer, and + 1 converts from zero-origin to one-origin indexing. Would that help?

Well, it's moot if I pass in the implicit buffer ID range.

jdenny updated this revision to Diff 256427.Apr 9 2020, 3:33 PM
jdenny marked an inline comment as done.
jdenny set the repository for this revision to rG LLVM Github Monorepo.

Addressed reviewer comments.

clang-tidy (via Harbormaster) is saying BuildInputAnnotations should be buildInputAnnotations. However, this patch does not introduce that function, and it follows the style in the rest of the file, so any fix should be in a separate patch.

thopre accepted this revision.Apr 15 2020, 10:45 AM

Much nicer with that change, thanks! LGTM

This revision is now accepted and ready to land.Apr 15 2020, 10:45 AM

Much nicer with that change, thanks!

Agreed. Thanks for the review!

This revision was automatically updated to reflect the committed changes.