maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/SemaCXX/array-bound-merge.cpp

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

15 lines
461 B
C++
Raw Normal View History

Update tests to use %clang_cc1 instead of 'clang-cc' or 'clang -cc1'. - This is designed to make it obvious that %clang_cc1 is a "test variable" which is substituted. It is '%clang_cc1' instead of '%clang -cc1' because it can be useful to redefine what gets run as 'clang -cc1' (for example, to set a default target). llvm-svn: 91446
2009-12-16 04:14:24 +08:00
// RUN: %clang_cc1 -fsyntax-only -verify %s
Fix for PR5515: allow "merging" array bounds both forwards and backwards. llvm-svn: 91044
2009-12-10 16:54:47 +08:00
// PR5515
extern int a[];
int a[10];
extern int b[10];
int b[];
extern int c[1];
int c[] = {1,2}; // expected-error {{excess elements in array initializer}}
Reject 'int a[1][];' in Sema rather than crashing in IR generation. Found by a misreduction of PR13290. llvm-svn: 159905
2012-07-08 07:00:31 +08:00
Recommit: Compress formatting of array type names (int [4] -> int[4]) Based on post-commit review discussion on 2bd84938470bf2e337801faafb8a67710f46429d with Richard Smith. Other uses of forcing HasEmptyPlaceHolder to false seem OK to me - they're all around pointer/reference types where the pointer/reference token will appear at the rightmost side of the left side of the type name, so they make nested types (eg: the "int" in "int *") behave as though there is a non-empty placeholder (because the "*" is essentially the placeholder as far as the "int" is concerned). This was originally committed in 277623f4d5a672d707390e2c3eaf30a9eb4b075c Reverted in f9ad1d1c775a8e264bebc15d75e0c6e5c20eefc7 due to breakages outside of clang - lldb seems to have some strange/strong dependence on "char [N]" versus "char[N]" when printing strings (not due to that name appearing in DWARF, but probably due to using clang to stringify type names) that'll need to be addressed, plus a few other odds and ends in other subprojects (clang-tools-extra, compiler-rt, etc).
2021-10-15 05:52:47 +08:00
int d[1][]; // expected-error {{array has incomplete element type 'int[]'}}
Using CanQualType::getAs<ArrayType> is unsafe; fix the code currently using it, and make sure additional uses don't get introduced. <rdar://problem/12858424>. llvm-svn: 170081
2012-12-13 09:43:21 +08:00
[Sema] Emit a better diagnostic when variable redeclarations disagree We referred to all declaration in definitions in our diagnostic messages which is can be inaccurate. Instead, classify the declaration and emit an appropriate diagnostic for the new declaration and an appropriate note pointing to the old one. This fixes PR24116. llvm-svn: 242190
2015-07-15 04:08:49 +08:00
extern const int e[2]; // expected-note {{previous declaration is here}}
Recommit: Compress formatting of array type names (int [4] -> int[4]) Based on post-commit review discussion on 2bd84938470bf2e337801faafb8a67710f46429d with Richard Smith. Other uses of forcing HasEmptyPlaceHolder to false seem OK to me - they're all around pointer/reference types where the pointer/reference token will appear at the rightmost side of the left side of the type name, so they make nested types (eg: the "int" in "int *") behave as though there is a non-empty placeholder (because the "*" is essentially the placeholder as far as the "int" is concerned). This was originally committed in 277623f4d5a672d707390e2c3eaf30a9eb4b075c Reverted in f9ad1d1c775a8e264bebc15d75e0c6e5c20eefc7 due to breakages outside of clang - lldb seems to have some strange/strong dependence on "char [N]" versus "char[N]" when printing strings (not due to that name appearing in DWARF, but probably due to using clang to stringify type names) that'll need to be addressed, plus a few other odds and ends in other subprojects (clang-tools-extra, compiler-rt, etc).
2021-10-15 05:52:47 +08:00
int e[] = { 1 }; // expected-error {{redefinition of 'e' with a different type: 'int[]' vs 'const int[2]'}}