This is an archive of the discontinued LLVM Phabricator instance.

[C89/C2x] Change the behavior of implicit int diagnostics
ClosedPublic

Authored by aaron.ballman on Apr 22 2022, 6:54 AM.

Details

Reviewers
jyknight
efriedma
hubert.reinterpretcast
erichkeane
tahonermann
Group Reviewers
Restricted Project
Summary

C89 allowed a type specifier to be elided with the resulting type being int, aka implicit int behavior. This feature was subsequently removed in C99 without a deprecation period, so implementations continued to support the feature. Now, as with implicit function declarations, is a good time to reevaluate the need for this support.

This patch allows -Wimplicit-int to issue warnings in C89 mode (off by default), defaults the warning to an error in C99 through C17, and disables support for the feature entirely in C2x. It also removes a warning about missing declaration specifiers that really was just an implicit int warning in disguise and other minor related cleanups.

Diff Detail

Event Timeline

aaron.ballman created this revision.Apr 22 2022, 6:54 AM
Herald added a project: Restricted Project. · View Herald TranscriptApr 22 2022, 6:54 AM
aaron.ballman requested review of this revision.Apr 22 2022, 6:54 AM
Herald added projects: Restricted Project, Restricted Project. · View Herald TranscriptApr 22 2022, 6:54 AM

Some quick comments... I didn't even bother opening the tests besides checking on functionality, so hopefully those are ok too :D

clang/docs/ReleaseNotes.rst
174

I find myself thinking that despite it being 'valid code' that -Wimplicit-int should be on-by-default in C89 mode. We often warn about 'valid, but non-future-proof' code, by default, particularly when they are code-breaking like this is.

clang/include/clang/Basic/LangOptions.h
534

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.

clang/lib/Parse/Parser.cpp
1198

C90?

clang/lib/Sema/SemaDecl.cpp
14329

IMO there should be a warning here for C89. Warning for non-future-proof code is pretty typical.

cor3ntin added inline comments.
clang/include/clang/Basic/LangOptions.h
534

@erichkeane requiresImplicitInt is only used twice. Does it needs a name?

clang/lib/Sema/SemaDecl.cpp
14329

Isn't the counter argument that was made on similar changes that people specifically asking for C89 have peculiar expectations?
Otherwise i agree

14342–14343

Nitpick: whitespace only change

erichkeane added inline comments.Apr 22 2022, 8:33 AM
clang/include/clang/Basic/LangOptions.h
534

*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.

clang/lib/Sema/SemaDecl.cpp
14329

Yep, folks asking for C89 ARE peculiar :D However, warnings-not-as-error are, IMO, simply 'helpful'.

14342–14343

This might be a clang-format thing based on the previous line.

aaron.ballman marked 2 inline comments as done.Apr 22 2022, 9:27 AM
aaron.ballman added inline comments.
clang/docs/ReleaseNotes.rst
174

On the one hand, yes. On the other hand, this is only for people who specify -std=c89 explicitly (which is not the default language mode for C), and I think we've been taking the viewpoint that these folks are mostly trying to keep old, mostly unmaintained code working.

clang/include/clang/Basic/LangOptions.h
534

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.)

clang/lib/Parse/Parser.cpp
1198

I'll fix the comment up. This confusion exists all over the place. :-D

clang/lib/Sema/SemaDecl.cpp
14329

Same here as above -- we *could* warn, but I suspect it wouldn't be particularly helpful. The fact that we were warning with an extension warning was non-conforming though (we shouldn't fail -pedantic-errors in C89 over that).

14342–14343

Yeah, clang-format got a bit aggressive there, I'll be the formatting changes out, thanks!

aaron.ballman marked an inline comment as done.

Updated based on review feedback, fixed failing precommit CI issues.

cor3ntin added inline comments.Apr 22 2022, 9:44 AM
clang/include/clang/Basic/LangOptions.h
534

implicitIntEnabled makes sense to me. I guess my question is, is there precedence for options for language-mandated features?

erichkeane added inline comments.Apr 22 2022, 9:44 AM
clang/docs/ReleaseNotes.rst
174

I'm annoyed by how much I understand/agree with both sides of this argument.

clang/include/clang/Basic/LangOptions.h
534

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?

Well, as it is now, the latter tells you whether 'it is allowed as an extension'.

isImplicitIntRequired() and isImplicitIntAllowed()?

These seem pretty clear to me. I don't see 'Support' as being valuable.

clang/lib/Sema/SemaDecl.cpp
14329

*grumble grumble*.

aaron.ballman marked 7 inline comments as done.Apr 22 2022, 9:48 AM
aaron.ballman added inline comments.
clang/include/clang/Basic/LangOptions.h
534

I guess my question is, is there precedence for options for language-mandated features?

Sure, though many of them also have user-facing command line flags to set the options. (wchar_t support, digraphs, etc)

I added these as helper functions mostly because there's no way to have language options whose default value is dependent on other language options.

Updated based on review feedback; changes the names of the language option helper functions for clarity.

aaron.ballman marked 5 inline comments as done.Apr 22 2022, 9:52 AM
erichkeane accepted this revision.Apr 22 2022, 10:03 AM

I'm happy enough. I see both sides of the C89 debate enough to 'disagree and commit' on that one.

This revision is now accepted and ready to land.Apr 22 2022, 10:03 AM

Updated to fix more tests caught by precommit CI.

rsmith added a subscriber: rsmith.Apr 22 2022, 12:03 PM
rsmith added inline comments.
clang/docs/ReleaseNotes.rst
173–174

Is there some fundamental reason why implicit int is harder to support in C2x (as there was for implicit function declarations, because unprototyped functions are gone), or are we merely taking the opportunity to do this because C2x is new? I find the former more easily defensible than the latter, but I suppose the fact that we removed implicit function declarations means that C2x is the first really properly breaking change that C has had, so maybe now is the time regardless.

aaron.ballman added inline comments.Apr 22 2022, 12:13 PM
clang/docs/ReleaseNotes.rst
173–174

Purely the latter -- C2x didn't make anything harder here. However, I'd like to position C23 as "not your grandfather's C" in Clang by strengthening diagnostics, especially ones related to safety or security vulnerabilities. Basically, I think it's time to cut ties with as many dangerous things that have been excised from C as possible. I think implicit int fits that goal in the same way that implicit function decls do (namely, the implicit choice can be wrong and you get surprising silent breakage at runtime if you're lucky).

(FWIW, I'm also hoping to get these sort of changes lumped into Clang 15 so that the pain of upgrading is more localized to just one release rather than strung out over several.)

rsmith added inline comments.Apr 22 2022, 4:47 PM
clang/docs/ReleaseNotes.rst
173–174

OK. I wonder our stricter interpretation of the rules in C23 onwards is something we should be calling out in our documentation as policy?

Precommit CI failures are down to just clang-format related ones. However, as with the implicit function declaration diagnostic, I expect there to be a long tail of failing tests which aren't caught by me locally or by the precommit CI bots. My plan is to track the bots closely whenever I do land this and fix up breakage as it's noticed. Hopefully it won't be too disruptive, but changing diagnostic behavior for ancient extensions like this turns out to be almost impossible to get a fully clean commit from in one go. (If someone wants to run this patch through their own configuration and report back failures before I land, I'm happy to make those fixes now.)

clang/docs/ReleaseNotes.rst
173–174

I'd be okay if we did that -- though, to be honest, we might want to review more of our developer policies regarding standards conformance in general, not just features removed from the language but kept as an extension. For example, I've been pretty sad about our inattention to documenting implementation-defined behaviors in Clang. "The source is our documentation" is cute for a while, but it does our users a disservice just the same, so it'd be nice to start setting policy that new implementation-defined stuff needs to be explicitly documented properly. I'm guessing we may find other such policy tweaks we'd like to make.

Ping for the other reviewers in case they have thoughts.

Ping for the other reviewers in case they have thoughts.

I took a gander and it all looks good to me. I added one comment regarding a test change.

clang/unittests/AST/SourceLocationTest.cpp
135–151

Perhaps preserve the prior tests (switched to Lang_C89) and then add these tests? That would ensure locations stay correct for both declaration forms.

tahonermann accepted this revision.Apr 28 2022, 7:06 AM
tahonermann added a reviewer: tahonermann.
aaron.ballman marked an inline comment as done.

Rebased and adjusted the source location AST unit test according to review feedback.

clang/unittests/AST/SourceLocationTest.cpp
135–151

Good suggestion! I've done that.

tahonermann accepted this revision.Apr 28 2022, 11:02 AM
aaron.ballman marked 2 inline comments as done.Apr 28 2022, 12:17 PM

@rsmith -- do you have any lingering concerns about the severity of the diagnostic?

Assuming no further comments from reviewers, I plan to land this sometime tomorrow.

aaron.ballman closed this revision.May 4 2022, 5:37 AM

I've landed in 2cb2cd242ca08d0bbd2a51a41f1317442e5414fc and will keep my eyes on the bots for long tail issues from the diagnostic change.