This is an archive of the discontinued LLVM Phabricator instance.

[update_test_checks] Default to --function-signature for new tests
AbandonedPublic

Authored by arichardson on Dec 16 2022, 6:28 AM.

Details

Summary

As was recently brought up in D139006, not using --function-signature by
default can cause tests to fail unexpectedly due to not matching "define"
in the function declaration. The referenced review tried to fix this but
was ultimately reverted due to the test churn that it causes.

This is an alternative approach, suggested by @nikic in D139006 that
defaults to --function-signature for new tests but keeps existing ones
unchanged. The implementation is somewhat ugly, using magic constants
for the --function-signature flag default values, but I can't see a way of
avoiding this.

Diff Detail

Event Timeline

arichardson created this revision.Dec 16 2022, 6:28 AM
Herald added a project: Restricted Project. · View Herald TranscriptDec 16 2022, 6:28 AM
arichardson requested review of this revision.Dec 16 2022, 6:28 AM
Herald added a project: Restricted Project. · View Herald TranscriptDec 16 2022, 6:28 AM
asb added a subscriber: asb.Dec 20 2022, 3:37 AM

Some general thoughts:

Although I understand the concerns about churn from updating auto-generated tests, I was concerned that an approach like this might have greater disadvantages than just landing a patch that regenerates everything (after all, churn in auto-generated tests has far fewer practical issues vs e.g. clang-formatting - conflicts are easily resolved by regenerating).

Though looking through the implementation, it doesn't seem overly complicated and seems like a sensible path forwards. I wouldn't be supportive of using such an approach for all future behaviour changes though - the complexity would just accrete and it makes the behaviour of the tool harder to predict.

Some general thoughts:

Although I understand the concerns about churn from updating auto-generated tests, I was concerned that an approach like this might have greater disadvantages than just landing a patch that regenerates everything (after all, churn in auto-generated tests has far fewer practical issues vs e.g. clang-formatting - conflicts are easily resolved by regenerating).

Though looking through the implementation, it doesn't seem overly complicated and seems like a sensible path forwards. I wouldn't be supportive of using such an approach for all future behaviour changes though - the complexity would just accrete and it makes the behaviour of the tool harder to predict.

I'm hoping that if we can land this, we can eventually upgrade all autogenerated tests without a function signature to use it and once that has happened, remove this workaround. I can see that there are still lots of new tests being added that don't use --function-signature and this will continue until --function-signature is the default.

nikic added a comment.Dec 22 2022, 2:04 AM

Some general thoughts:

Although I understand the concerns about churn from updating auto-generated tests, I was concerned that an approach like this might have greater disadvantages than just landing a patch that regenerates everything (after all, churn in auto-generated tests has far fewer practical issues vs e.g. clang-formatting - conflicts are easily resolved by regenerating).

For this change this would require regenerating close to 5000 tests. Not out of the question, but it's a bit more than the usual amount of churn.

Anyway, I think before making this change we should probably land D133943 first. Doing that change will be harder if --function-signature is more widely used. (Alternatively, if we introduce a --version flag as I suggested before, we could do that as a separate version bump without test regeneration.)

nikic resigned from this revision.Mar 9 2023, 11:45 AM

Superseded by D145149.

arichardson abandoned this revision.Mar 9 2023, 12:56 PM
llvm/test/tools/UpdateTestChecks/update_test_checks/Inputs/basic.ll.expected