This is an archive of the discontinued LLVM Phabricator instance.

Add a new driver option to disable warning about c++17's non-throwing exception specification in function signature
ClosedPublic

Authored by ahatanak on Jun 15 2017, 2:57 PM.

Details

Summary

The option allows disabling just the warning about non-throwing exception specification in function signature instead of disabling all c++1z compatibility warnings with -Wno-c++1z-compat.

I'm not sure "-Wc++1z-compat-exception-spec" sounds right.

Maybe -Wc++1z-compat-mangling, -Wc++1z-mangling, or -Wc++1z-compat-exception-spec-function is better?

rdar://problem/32628743

Diff Detail

Repository
rL LLVM

Event Timeline

ahatanak created this revision.Jun 15 2017, 2:57 PM
dexonsmith accepted this revision.Jun 19 2017, 3:58 PM
dexonsmith added a subscriber: dexonsmith.

I think -Wc++1z-mangling is best. IMO, with C++1z in the name, it's already clear that this is about compatibility. I also don't think we need to get as specific as -Wc++1z-compat-exception-spec.

LGTM with that name, but you might wait a day or two in case someone has a strong opinion to the contrary.

This revision is now accepted and ready to land.Jun 19 2017, 3:58 PM
rsmith accepted this revision.Jun 19 2017, 4:18 PM

We use the -Wc++NN-compat- prefix on all the other subwarnings of -Wc++NN-compat warnings (examples: -Wc++98-compat-bind-to-temporary-copy, -Wc++11-compat-reserved-user-defined-literal, ...). I'd prefer to include the -compat in the name for consistency; I also find it less clear what the warning flag would mean without it (I would expect -Wc++1z-mangling to only fire in C++1z mode, whereas this warning never fires in C++1z mode).

-Wc++1z-compat-mangling seems fine to me.

Just curious, though: what is the motivation for enabling the rest of -Wc++1z-compat but not this part? This seems a lot more serious than the other warnings in the group. (Regardless, I think this patch is useful for the opposite: enabling just this one warning without the rest...)

We use the -Wc++NN-compat- prefix on all the other subwarnings of -Wc++NN-compat warnings

Interesting; I thought I saw a counter-example recently, and took that as the rule (although I can't for the life of me remember what it was). -Wc++NN-compat-mangling SGTM though.

Just curious, though: what is the motivation for enabling the rest of -Wc++1z-compat but not this part? This seems a lot more serious than the other warnings in the group. (Regardless, I think this patch is useful for the opposite: enabling just this one warning without the rest...)

A user is recompiling the codebase as a unit so binary compatibility doesn't matter, but language semantics do.

This revision was automatically updated to reflect the committed changes.