This is an archive of the discontinued LLVM Phabricator instance.

[C] Strengthen -Wint-conversion to default to an error
ClosedPublic

Authored by aaron.ballman on Jul 15 2022, 10:37 AM.

Details

Summary

Clang has traditionally allowed C programs to implicitly convert integers to pointers and pointers to integers, despite it not being valid to do so except under special circumstances (like converting the integer 0, which is the null pointer constant, to a pointer). In C89, this would result in undefined behavior per 3.3.4, and in C99 this rule was strengthened to be a constraint violation instead. Constraint violations are most often handled as an error.

This patch changes the warning to default to an error in all C modes (it is already an error in C++). This gives us better security posture by calling out potential programmer mistakes in code but still allows users who need this behavior to use -Wno-error=int-conversion to retain the warning behavior, or -Wno-int-conversion to silence the diagnostic entirely.

When modifying the diagnostics, I observed that ext_typecheck_convert_int_pointer was already marked SFINAEFailure but ext_typecheck_convert_pointer_int was not. This appeared to be an oversight which I corrected. That resulted in needing a change to not perform SFINAE traps in C mode. If desired, I can split those changes into a separate review, but they felt related enough to this change to be reasonable to roll in here by virtue of changing the behavior of the diagnostic.

Diff Detail

Event Timeline

aaron.ballman created this revision.Jul 15 2022, 10:37 AM
Herald added a project: Restricted Project. · View Herald TranscriptJul 15 2022, 10:37 AM
aaron.ballman requested review of this revision.Jul 15 2022, 10:37 AM
Herald added projects: Restricted Project, Restricted Project, Restricted Project. · View Herald TranscriptJul 15 2022, 10:37 AM
Herald added a subscriber: Restricted Project. · View Herald Transcript

This seems like a good idea despite the breaking change. I dont see anything in the code to be concerned about, but I'm hoping others will comment as to whether this is completely acceptable.

clang/lib/Sema/SemaExprCXX.cpp
8482 ↗(On Diff #445048)

This makes sense to me, I don't see why this hasn't bit us before, but SFINAE in C mode seems wrong?

Given this is an on-by-default warning already, I don't expect changing it to an error by default to have much impact in practice. Changing it fine.

clang/lib/Sema/SemaExprCXX.cpp
8483 ↗(On Diff #445048)

I'd prefer not to introduce unnecessary differences in C vs. C++ handling like this...

This seems weird for two reasons:

  • We don't use ext_typecheck_convert_pointer_int in C++, so there's not really any reason to mark it SFINAEFailure
  • Whatever code is calling this probably doesn't want an SFINAE context. Is this coming from TransformToPotentiallyEvaluated? We don't want SFINAE traps from there, in C or C++.
aaron.ballman added inline comments.Jul 15 2022, 11:04 AM
clang/lib/Sema/SemaExprCXX.cpp
8483 ↗(On Diff #445048)

We don't use ext_typecheck_convert_pointer_int in C++, so there's not really any reason to mark it SFINAEFailure

The original changes came from: https://github.com/llvm/llvm-project/issues/39709 but I see now that we used to treat this as a warning in C++ rather than an error. So adding SFINAEFailure made sense at that point, but I think you're right that it should be removed now. I'll try that locally and see if anything explodes as a result.

Whatever code is calling this probably doesn't want an SFINAE context. Is this coming from TransformToPotentiallyEvaluated? We don't want SFINAE traps from there, in C or C++.

Typo correction went haywire. Specifically: https://github.com/llvm/llvm-project/blob/main/clang/test/Sema/typo-correction-ambiguity.c#L13

We would typo correct v_231 to be v_2_0 here, and when deciding whether that was valid or not, we'd hit the SFINAE trap in C code and that changed the behavior of the test to add suggestions instead of silence them.

I think it's incredibly weird to ever use SFINAE in C, even by accident.

Removed the SFINAEFailure and trap changes, added a release note.

clang/lib/Sema/SemaExprCXX.cpp
8483 ↗(On Diff #445048)

I'll try that locally and see if anything explodes as a result.

All my local tests passed, so I've made the change and we'll see if precommit CI finds anything I didn't.

This revision is now accepted and ready to land.Jul 22 2022, 12:21 PM

Hi @aaron.ballman, it looks like this broke 2 tests in the lldb test suite (https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/45560/). Can we revert this to keep CI green?

Actually, never mind, I think I can fix the tests.

Actually, never mind, I think I can fix the tests.

Thank you for the fix, and sorry for the trouble!

Hi @aaron.ballman, it looks like this broke 2 tests in the lldb test suite (https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/45560/). Can we revert this to keep CI green?

FWIW, this is not a situation where I think a revert would be reasonable. Clang changed in a standards conforming way; if lldb is sensitive to a change in diagnostics like that, I believe the lldb maintainers should be addressing the situation, not the Clang maintainers. However, we of course should collaborate and not cause headaches for one another, so if it was a highly disruptive conforming change or we made a nonconforming change, that's a different story. Thank you for asking about the revert, but thank you even more for helping to fix forward (this helps us keep git blame useful without having to wade through churn commits, too)!