This is an archive of the discontinued LLVM Phabricator instance.

[clang-format] Remove redundant test in style-on-command-line.cpp
ClosedPublic

Authored by krasimir on Jan 20 2017, 4:00 AM.

Details

Summary

rL292562 added a fix to always format if the fallback style is set to "none".
In test/Format/style-on-command-line.cpp:19 is redundant, since -fallback-style
has a default value of LLVM set in ClangFormat.cpp:72.

@amaiorano: I believe that the rest of the test cases still cover your change in
case the fallback style is explicitly set to "none". Please, if this is not the
case, initiate a discussion.

Diff Detail

Repository
rL LLVM

Event Timeline

krasimir created this revision.Jan 20 2017, 4:00 AM
krasimir added a subscriber: cfe-commits.
ioeric accepted this revision.Jan 20 2017, 4:38 AM

@amaiorano: The test itself is correct. It's just that this test failed in our internal test. We could've fixed it internally, but the fix would be ugly. Since the intended behavior is already covered in the case above it, and it's really just checking the default fallback style is LLVM, which is not related to the original change, I think it makes sense to get rid of the case. Hope you don't mind :)

This revision is now accepted and ready to land.Jan 20 2017, 4:38 AM
This revision was automatically updated to reflect the committed changes.

@amaiorano: The test itself is correct. It's just that this test failed in our internal test. We could've fixed it internally, but the fix would be ugly. Since the intended behavior is already covered in the case above it, and it's really just checking the default fallback style is LLVM, which is not related to the original change, I think it makes sense to get rid of the case. Hope you don't mind :)

Of course I don't mind :) Why did it fail your internal tests, btw? Just curious. Was it something I could've detected myself?

@amaiorano: The test itself is correct. It's just that this test failed in our internal test. We could've fixed it internally, but the fix would be ugly. Since the intended behavior is already covered in the case above it, and it's really just checking the default fallback style is LLVM, which is not related to the original change, I think it makes sense to get rid of the case. Hope you don't mind :)

Of course I don't mind :) Why did it fail your internal tests, btw? Just curious. Was it something I could've detected myself?

Probably not... it's just that our default fallback style is "Google" instead of "LLVM".

@amaiorano: The test itself is correct. It's just that this test failed in our internal test. We could've fixed it internally, but the fix would be ugly. Since the intended behavior is already covered in the case above it, and it's really just checking the default fallback style is LLVM, which is not related to the original change, I think it makes sense to get rid of the case. Hope you don't mind :)

Of course I don't mind :) Why did it fail your internal tests, btw? Just curious. Was it something I could've detected myself?

Probably not... it's just that our default fallback style is "Google" instead of "LLVM".

(I replied the following by email, but I'm not sure where it went... posting it here instead)

You mean you build a modified version of clang-format where Style is initialized to getGoogleStyle()?

I had wondered whether adding a "defaultStyle" argument might be useful, specifically in the case where you want to pass in yaml that simply tweaks the default style, but I figured it's not much harder to pass in "BasedOnStyle" in the yaml.

@amaiorano: The test itself is correct. It's just that this test failed in our internal test. We could've fixed it internally, but the fix would be ugly. Since the intended behavior is already covered in the case above it, and it's really just checking the default fallback style is LLVM, which is not related to the original change, I think it makes sense to get rid of the case. Hope you don't mind :)

Of course I don't mind :) Why did it fail your internal tests, btw? Just curious. Was it something I could've detected myself?

Probably not... it's just that our default fallback style is "Google" instead of "LLVM".

(I replied the following by email, but I'm not sure where it went... posting it here instead)

You mean you build a modified version of clang-format where Style is initialized to getGoogleStyle()?

I had wondered whether adding a "defaultStyle" argument might be useful, specifically in the case where you want to pass in yaml that simply tweaks the default style, but I figured it's not much harder to pass in "BasedOnStyle" in the yaml.

No.. we set both default style and default fallback style (tool options) to "google" in our build.

I don't see why "defaultStyle" would be useful. I think having the existing "style" and "fallback-style" options is sufficient (and already a bit confusing).