This is an archive of the discontinued LLVM Phabricator instance.

[clang] Introduce -Warray-parameter
ClosedPublic

Authored by serge-sans-paille on Jun 23 2022, 8:11 AM.

Details

Summary

This warning exist in GCC[0] and warns about re-declarations of functions
involving arguments of array or pointer types of inconsistent kinds or forms.

This is not the exact same implementation as GCC's : there's no warning level
and that flag has no effect on -Warray-bounds.

[0] https://gcc.gnu.org/onlinedocs/gcc-12.1.0/gcc/Warning-Options.html#index-Wno-array-parameter

Diff Detail

Event Timeline

Herald added a project: Restricted Project. · View Herald TranscriptJun 23 2022, 8:11 AM
serge-sans-paille requested review of this revision.Jun 23 2022, 8:11 AM
Herald added a project: Restricted Project. · View Herald TranscriptJun 23 2022, 8:11 AM
Herald added a subscriber: cfe-commits. · View Herald Transcript

Activate -Warray-parameter on -Wmost but disable it by default

Thanks for working on this!

clang/lib/Sema/SemaDecl.cpp
49

Is this new include necessary?

3267–3270
clang/test/Misc/warning-wall.c
101

Something went sideways here (perhaps saved with the wrong line endings?).

clang/test/Sema/array-parameter.c
3

I'd like to see some additional test cases:

void func(int *p);
void func(int a[2]); // Diagnose this one, I presume?
void func(int a[]); // But also diagnose this one as well, yes?
void func(int a[2]) {} // Do we then diagnose this as well, or is this matching a previous declaration and thus fine?

void other(int n, int m, int a[n]);
void other(int n, int m, int a[m]); // Hopefully we diagnose this set!

void another(int n, int array[n]);
void another(int n, int array[*]); // I *think* this should be warned, but I'm still a bit on the fence about it

Also, if this is expected to work in C++ as well, we should probably have cases like:

template <int N>
void func(int i[10]);

template <int N>
void func(int i[N]); // Should we diagnose this before instantiation or wait until we see the instantiation and only diagnose if differs?

static constexpr int Extent = 10;
void other(int i[10]);
void other(int i[Extent]); // Should not be diagnosed
13–20

I don't think we should diagnose any of these -- the array bounds do match. GCC doesn't diagnose them either.

22–23

I don't think we should diagnose this case either -- the [*] case is denoting a parameter of variable-length array type with no size information, and [] is the same except not a variable-length array type. So it's hard to argue that the bounds are not matched properly.

Take review into account : rework indentation, style cleaning and be more accurate about bounds reporting

aaron.ballman added inline comments.Jun 24 2022, 11:10 AM
clang/lib/Sema/SemaDecl.cpp
3220
3224
3234
3274–3278

The diagnostics engine knows how to format NamedDecl objects as well as types. Can you do this instead and still get reasonable diagnostics?

clang/test/Sema/array-parameter.c
3

Do you plan to add the C++ tests?

serge-sans-paille marked 3 inline comments as done.

Take review into account + add C++ test file.

clang/test/Sema/array-parameter.c
3

template <int N>
void func(int i[N]); // Should we diagnose this before instantiation or wait until we see the instantiation and only diagnose if differs?

GCC never warns about this. Current patch always warn and this looks fine to me.

shafik added a subscriber: shafik.Jun 27 2022, 1:37 PM
shafik added inline comments.
clang/test/Sema/array-parameter.c
18

Since we are covering static, const and restict we should also cover volatile for completeness.

aaron.ballman added inline comments.Jul 1 2022, 7:45 AM
clang/lib/Sema/SemaDecl.cpp
3216

I forgot about this gotcha -- arrays are special in that you shouldn't be using cast<> and friends on them, you need to ask the ASTContext to go from the QualType to the correct array type. e.g., ASTContext::getAsConstantArrayType() and ASTContext::getAsVariableArrayType() -- I think this is the cause of the failed assertions we're seeing in precommit CI.

Fix handling of ConstantArrayType, thanks @aaron.ballman for the hint.

aaron.ballman added inline comments.Jul 5 2022, 5:01 AM
clang/docs/ReleaseNotes.rst
324–326
clang/lib/Sema/SemaDecl.cpp
3216

I'm still not comfortable with the way this is written -- please go through the ASTContext instead, with something like:

if (Ty->isIncompleteArrayType() || Ty->isPointerType())
  return true;

if (const auto *VAT = Ctx.getAsVariableArrayType(Ty))
  return VAT->getSizeModifier() == ArrayType::ArraySizeModifier::Star;

return false;
3226–3227

Same here.

clang/test/Sema/array-parameter.c
18

+1, might as well round out the set.

clang/test/Sema/array-parameter.cpp
4–8

One more test, now that I'm thinking about explicit specializations:

template <int N>
void func(int (&Val)[N]);

template <>
void func<10>(int (&Val)[10]) {
}

I don't think this should get any diagnostics.

serge-sans-paille marked an inline comment as done.

Take review into account.

aaron.ballman accepted this revision.Jul 8 2022, 8:37 AM

LGTM, thank you for the new diagnostic!

clang/lib/Sema/SemaDecl.cpp
3213

East const? MONSTEROUS! ;-) (We tend to use west const mostly in the code base.)

This revision is now accepted and ready to land.Jul 8 2022, 8:37 AM
clang/lib/Sema/SemaDecl.cpp
3213

Whenever I don't have strict focus on my fingers, they go east!

This revision was landed with ongoing or failed builds.Jul 8 2022, 1:37 PM
This revision was automatically updated to reflect the committed changes.
alexfh added a subscriber: alexfh.Jul 12 2022, 5:48 AM

Serge, this diagnostic doesn't handle non-type template parameters correctly in some cases. Here's an example derived from a real code: https://gcc.godbolt.org/z/cvP8od5c6

template<int K>
struct T {
  static void F(int a[8 * K]);
};
template<int K>
void T<K>::F(int a[8 * K]) {}
<source>:6:18: warning: argument 'a' of type 'int[8 * K]' with mismatched bound [-Warray-parameter]
void T<K>::F(int a[8 * K]) {}
                 ^
<source>:3:21: note: previously declared as 'int[8 * K]' here
  static void F(int a[8 * K]);
                    ^

Do you see an obvious fix? If not, please revert while investigating.

Thanks for the extra test case!

Do you see an obvious fix? If not, please revert while investigating.

Obvious fix landed in 66fa2847a775dda27ddcac3832769441727db42f