This is an archive of the discontinued LLVM Phabricator instance.

Use descriptive message if list initializer is incorrectly parenthesized.
ClosedPublic

Authored by sepavloff on Oct 20 2016, 12:48 AM.

Details

Summary

If initializer contains parentheses around braced list where it is not allowed, as in
construct int({0}), clang issued message like `functional-style cast from 'void' to
'int' is not allowed`, which does not much help. Both gcc and msvc issue message
list-initializer for non-class type must not be parenthesized, which is more
descriptive. This change implements similar behavior for clang also.

Diff Detail

Repository
rL LLVM

Event Timeline

sepavloff updated this revision to Diff 75270.Oct 20 2016, 12:48 AM
sepavloff retitled this revision from to Use descriptive message if list initializer is incorrectly parenthesized..
sepavloff updated this object.
sepavloff added a subscriber: cfe-commits.

Thanks for working on this! I have a couple of comments:

include/clang/Basic/DiagnosticSemaKinds.td
1762 ↗(On Diff #75270)

Wouldn't it be better if we had a diagnostic with the type information? So, instead of showing list-initializer for non-class type must not be parenthesized clang would show list-initializer for non-class type 'int' must not be parenthesized. What do you think?

As well as that, it seems that GCC issues a warning instead of an error for this diagnostic, so should this be a warning in clang as well?

include/clang/Sema/Sema.h
1802 ↗(On Diff #75270)

I think you mean parenthesized instead of parenthzed here. As well as that, I think that it would be better to use a name without the not, something like canInitializeWithParenthesizedList.

Also, please add a comment that explains what this method does.

1803 ↗(On Diff #75270)

Please add a blank line here to separate unrelated Act... methods from the new method.

lib/Sema/SemaDecl.cpp
9796 ↗(On Diff #75270)

Slight formatting issue: please indent the three lines that start with '<<' using 4 extra spaces instead of 2 (just like you did in your changes for SemaExprCXX.cpp).

10110 ↗(On Diff #75270)

If you change the name as I suggested to something like canInitializeWithParenthesizedList then the logic here would have to be inverted: TargetType()->isDependentType() || TargetType()->isRecordType() || TargetType()->getContainedAutoType(). Consequently, the call sites will have to be updated to include a ! before the call.

lib/Sema/SemaExprCXX.cpp
1229 ↗(On Diff #75270)

Formatting issue: clang-format replaces

<< IList->getSourceRange()
<< FixItHint::CreateRemoval(LParenLoc)

with

<< IList->getSourceRange() << FixItHint::CreateRemoval(LParenLoc)
test/SemaCXX/cxx0x-initializer-scalars.cpp
96 ↗(On Diff #75270)

Please add a test case for a pointer type as well, something like this should work:

int *x({0});

As well as that, please add a test for a dependent type.

sepavloff updated this revision to Diff 75404.Oct 21 2016, 3:20 AM

Addressed reviewr's notes.

sepavloff marked 5 inline comments as done.Oct 21 2016, 3:34 AM
sepavloff added inline comments.
include/clang/Basic/DiagnosticSemaKinds.td
1762 ↗(On Diff #75270)

Putting type name into the diagnostic message is a good idea, implemented.

As for making this message a warning instead of an error, I am in doubt.
Pros:

  • it enhances GCC compatibility,
  • wrong code may be easily fixed by compiler,

Cons:

  • this is a violation of the standard,
  • this extension does not add any benefits,
  • wrong code can be easily fixed by user.

I chose to retain current clang behavior and reject questionable code. GCC patch that introduced this message explains using warning by some uncertainty, 5 years passed, I think the standard is stable in viewpoint on such usage.

lib/Sema/SemaExprCXX.cpp
1229 ↗(On Diff #75270)

After insertion of type Ty this is no more the case.

LGTM, I added Richard in case he has something to add.

I chose to retain current clang behavior and reject questionable code. GCC patch that introduced this message explains using warning by some uncertainty, 5 years passed, I think the standard is stable in viewpoint on such usage.

Thanks for the detailed explanation, I wasn't sure if GCC's was behaving according to the standard or not.

This revision was automatically updated to reflect the committed changes.