[PATCH] D124258: [C89/C2x] Change the behavior of implicit int diagnostics

[Corentin Jabot via Phabricator via cfe-commits]

cor3ntin added inline comments.


================
Comment at: clang/include/clang/Basic/LangOptions.h:534
+  /// Returns true if implicit int is supported at all.
+  bool implicitIntEnabled() const { return !CPlusPlus && !C2x; }
+
----------------
aaron.ballman wrote:
> erichkeane wrote:
> > cor3ntin wrote:
> > > erichkeane wrote:
> > > > This name seems inverse of what you mean to me?  IDK if you're bike-shed-sniping me here, but:
> > > > 
> > > > `prohibitsImplicitInt` to be the reverse of above? It becomes SLIGHTLY ambiguous to me (in that we don't mean "the language standard prohibits", we mean "the compiler implementation prohibits"), but that can be fixed up with a comment.
> > > > 
> > > > If you want to keep the direction, perhaps `implicitIntPermitted`, at which point I might suggest the one above become `implicitIntRequired`.
> > > @erichkeane `requiresImplicitInt` is only used twice. Does it needs a name?
> > > 
> > *shrug*, I tend to be of the feeling that if you have to say something this often, and functions are basically free, mind as well make one.
> The idea here is that `requiresImplicitInt()` tells you when the support is mandatory per spec, and `implicitIntEnabled()` tells you when the support is either mandatory or an extension. I'm not strongly tied to the names, how do these sound?
> 
> `isImplicitIntRequired()` and `isImplicitIntAllowed()`?
> 
> (I could also add the word `Support` in there as in `isImplicitIntSupportRequired()` but then the function names start to get a bit longer than I think is reasonable.)
`implicitIntEnabled` makes sense to me. I guess my question is, is there precedence for options for language-mandated features?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D124258/new/

https://reviews.llvm.org/D124258