In `ParseDeclarationSpecifiers` for the code
class A typename A;
we were able to annotate token `kw_typename` because it refers to
existing type. But later during processing token `annot_typename` we
failed to `SetTypeSpecType` and exited switch statement leaving
annotation token unconsumed. The code after the switch statement failed
because it didn't expect a special token.
The fix is not to assume that switch statement consumes all special
tokens and consume any token, not just non-special.
rdar://problem/37099386
Reviewers: rsmith, arphaman
Reviewed By: rsmith
Subscribers: jkorous-apple, cfe-commits
Differential Revision: https://reviews.llvm.org/D44449
llvm-svn: 329735
The current support of the feature produces only 2 lines in report:
-Some general Code Generation Time;
-Total time of Backend Consumer actions.
This patch extends Clang time report with new lines related to Preprocessor, Include Filea Search, Parsing, etc.
Differential Revision: https://reviews.llvm.org/D43578
llvm-svn: 329684
Found via codespell -q 3 -I ../clang-whitelist.txt
Where whitelist consists of:
archtype
cas
classs
checkk
compres
definit
frome
iff
inteval
ith
lod
methode
nd
optin
ot
pres
statics
te
thru
Patch by luzpaz! (This is a subset of D44188 that applies cleanly with a few
files that have dubious fixes reverted.)
Differential revision: https://reviews.llvm.org/D44188
llvm-svn: 329399
The AST for the fragment
```
@interface I
@end
template <typename>
void decode(I *p) {
for (I *k in p) {}
}
void decode(I *p) {
decode<int>(p);
}
```
differs heavily when templatized and non-templatized:
```
|-FunctionTemplateDecl 0x7fbfe0863940 <line:4:1, line:7:1> line:5:6 decode
| |-TemplateTypeParmDecl 0x7fbfe0863690 <line:4:11> col:11 typename depth 0 index 0
| |-FunctionDecl 0x7fbfe08638a0 <line:5:1, line:7:1> line:5:6 decode 'void (I *__strong)'
| | |-ParmVarDecl 0x7fbfe08637a0 <col:13, col:16> col:16 referenced p 'I *__strong'
| | `-CompoundStmt 0x7fbfe0863b88 <col:19, line:7:1>
| | `-ObjCForCollectionStmt 0x7fbfe0863b50 <line:6:3, col:20>
| | |-DeclStmt 0x7fbfe0863a50 <col:8, col:13>
| | | `-VarDecl 0x7fbfe08639f0 <col:8, col:11> col:11 k 'I *const __strong'
| | |-ImplicitCastExpr 0x7fbfe0863a90 <col:16> 'I *' <LValueToRValue>
| | | `-DeclRefExpr 0x7fbfe0863a68 <col:16> 'I *__strong' lvalue ParmVar 0x7fbfe08637a0 'p' 'I *__strong'
| | `-CompoundStmt 0x7fbfe0863b78 <col:19, col:20>
| `-FunctionDecl 0x7fbfe0863f80 <line:5:1, line:7:1> line:5:6 used decode 'void (I *__strong)'
| |-TemplateArgument type 'int'
| |-ParmVarDecl 0x7fbfe0863ef8 <col:13, col:16> col:16 used p 'I *__strong'
| `-CompoundStmt 0x7fbfe0890cf0 <col:19, line:7:1>
| `-ObjCForCollectionStmt 0x7fbfe0890cc8 <line:6:3, col:20>
| |-DeclStmt 0x7fbfe0890c70 <col:8, col:13>
| | `-VarDecl 0x7fbfe0890c00 <col:8, col:11> col:11 k 'I *__strong' callinit
| | `-ImplicitValueInitExpr 0x7fbfe0890c60 <<invalid sloc>> 'I *__strong'
| |-ImplicitCastExpr 0x7fbfe0890cb0 <col:16> 'I *' <LValueToRValue>
| | `-DeclRefExpr 0x7fbfe0890c88 <col:16> 'I *__strong' lvalue ParmVar 0x7fbfe0863ef8 'p' 'I *__strong'
| `-CompoundStmt 0x7fbfe0863b78 <col:19, col:20>
```
Note how in the instantiated version ImplicitValueInitExpr unexpectedly appears.
While objects are auto-initialized under ARC, it does not make sense to
have an initializer for a for-loop variable, and it makes even less
sense to have such a different AST for instantiated and non-instantiated
version.
Digging deeper, I have found that there are two separate Sema* files for
dealing with templates and for dealing with non-templatized code.
In a non-templatized version, an initialization was performed only for
variables which are not loop variables for an Objective-C loop and not
variables for a C++ for-in loop:
```
if (FRI && (Tok.is(tok::colon) || isTokIdentifier_in())) {
bool IsForRangeLoop = false;
if (TryConsumeToken(tok::colon, FRI->ColonLoc)) {
IsForRangeLoop = true;
if (Tok.is(tok::l_brace))
FRI->RangeExpr = ParseBraceInitializer();
else
FRI->RangeExpr = ParseExpression();
}
Decl *ThisDecl = Actions.ActOnDeclarator(getCurScope(), D);
if (IsForRangeLoop)
Actions.ActOnCXXForRangeDecl(ThisDecl);
Actions.FinalizeDeclaration(ThisDecl);
D.complete(ThisDecl);
return Actions.FinalizeDeclaratorGroup(getCurScope(), DS, ThisDecl);
}
SmallVector<Decl *, 8> DeclsInGroup;
Decl *FirstDecl = ParseDeclarationAfterDeclaratorAndAttributes(
D, ParsedTemplateInfo(), FRI);
```
However the code in SemaTemplateInstantiateDecl was inconsistent,
guarding only against C++ for-in loops.
rdar://38391075
Differential Revision: https://reviews.llvm.org/D44989
llvm-svn: 328749
When the declare target variables are emitted for the device,
constructors|destructors for these variables must emitted and registered
by the runtime in the offloading sections.
llvm-svn: 328705
The diagnostic system for Clang can already handle many AST nodes. Instead
of converting them to strings first, just hand the AST node directly to
the diagnostic system and let it handle the output. Minor changes in some
diagnostic output.
llvm-svn: 328688
This allows users to turn off warnings about this pragma specifically,
while still receiving warnings about other ignored pragmas.
Differential Revision: https://reviews.llvm.org/D44630
llvm-svn: 327959
Summary:
This fixes [PR35381](https://llvm.org/pr35381) and an additional bug where clang didn't warn about the C++17 extension when having an expression in the init statement.
Thanks Nicolas Lesser for contributing the patch.
Reviewers: rsmith
Reviewed By: rsmith
Subscribers: erik.pilkington, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D40445
llvm-svn: 327782
Added initial codegen for device side of declarations inside `omp
declare target` construct + codegen for implicit `declare target`
functions, which are used in the target regions.
llvm-svn: 327636
We need to treat __unaligned like the other 'cvr' qualifiers when it
appears at the end of a function prototype. We weren't doing that in
some tentative parsing.
Fixes PR36638.
llvm-svn: 326962
Specifically, we would not properly parse these types within template arguments
(for non-type template parameters), and in tentative parses. Fixing both of
these essentially requires that we parse deduced template specialization types
as types in all contexts, even in template argument lists -- in particular,
tentative parsing may look ahead and annotate a deduced template specialization
type before we figure out that we're actually supposed to treat the tokens as a
template-name. We deal with this by simply permitting deduced template
specialization types when parsing template arguments, and converting them to
template template arguments.
llvm-svn: 326299
The TypeTagForDatatype attribute had custom parsing rules that previously prevented it from being supported with square bracket notation. The ArgumentWithTypeTag attribute previously had unnecessary custom parsing that could be handled declaratively.
llvm-svn: 326052
This attribute has custom parsing rules that previously prevented it from being supported with square bracket notation. Rework the clang attribute argument parsing to be more easily extended for other custom-parsed attributes.
llvm-svn: 326036
This patch adds a base-class called TemplateInstantiationObserver which gets
notified whenever a template instantiation is entered or exited during
semantic analysis. This is a base class used to implement the template
profiling and debugging tool called
Templight (https://github.com/mikael-s-persson/templight).
The patch also makes a few more changes:
* ActiveTemplateInstantiation class is moved out of the Sema class (so it can be used with inclusion of Sema.h).
* CreateFrontendAction function in front-end utilities is given external linkage (not longer a hidden static function).
* TemplateInstObserverChain data member added to Sema class to hold the list of template-inst observers.
* Notifications to the template-inst observer are added at the key places where templates are instantiated.
Patch by: Abel Sinkovics!
Differential Revision: https://reviews.llvm.org/D5767
llvm-svn: 324808
This adds the frontend support required to support the use of the
comment pragma to enable auto linking on ELFish targets. This is a
generic ELF extension supported by LLVM. We need to change the handling
for the "dependentlib" in order to accommodate the previously discussed
encoding for the dependent library descriptor. Without the custom
handling of the PCK_Lib directive, the -l prefixed option would be
encoded into the resulting object (which is treated as a frontend
error).
llvm-svn: 324438
We could in principle support such pack expansion, using techniques similar to
what we do for pack expansion of lambdas, but it's not clear it's worthwhile.
For now at least, cleanly reject these cases rather than crashing.
llvm-svn: 324160
When parsing C++ type construction expressions with list initialization,
forward the locations of the braces to Sema.
Without these locations, the code coverage pass crashes on the given test
case, because the pass relies on getLocEnd() returning a valid location.
Here is what this patch does in more detail:
- Forwards init-list brace locations to Sema (ParseExprCXX),
- Builds an InitializationKind with these locations (SemaExprCXX), and
- Uses these locations for constructor initialization (SemaInit).
The remaining changes fall out of introducing a new overload for
creating direct-list InitializationKinds.
Testing: check-clang, and a stage2 coverage-enabled build of clang with
asserts enabled.
Differential Revision: https://reviews.llvm.org/D41921
llvm-svn: 322729
Summary:
First, this patch fixes an assert failure when, for example, "omp for"
has num_teams.
Second, this patch prevents duplicate diagnostics when, for example,
"omp for" has uniform.
This patch makes the general assumption (even where it doesn't
necessarily fix an existing bug) that it is worthless to perform sema
for a clause that appears on a directive on which OpenMP does not
permit that clause. However, due to this assumption, this patch
suppresses some diagnostics that were expected in the test suite. I
assert that those diagnostics were likely just distracting to the
user.
Reviewers: ABataev
Reviewed By: ABataev
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D41841
llvm-svn: 322107
Summary:
#pragma STDC FP_CONTRACT handler is only registered in parser so we
should keep the unknown STDC pragma through preprocessor and we also
should not emit warning for unknown STDC pragma during preprocessor.
rdar://problem/35724351
Reviewers: efriedma, rsmith, arphaman
Reviewed By: efriedma
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D41780
llvm-svn: 321909
- reverts r321622, r321625, and r321626.
- the use of bit-fields is still resulting in warnings - even though we can use static-asserts to harden the code and ensure the bit-fields are wide enough. The bots still complain of warnings being seen.
- to silence the warnings requires specifying the bit-fields with the underlying enum type (as opposed to the enum type itself), which then requires lots of unnecessary static casts of each enumerator within DeclSpec to the underlying-type, which even though could be seen as implementation details, it does hamper readability - and given the additional litterings, makes me question the value of the change.
So in short - I give up (for now at least).
Sorry about the noise.
llvm-svn: 321628
- Since these enums are used as bit-fields - for the bit-fields to be interpreted as unsigned, the underlying type must be specified as unsigned.
Previous failed attempt - wherein I did not specify an underlying type - was the sum of:
https://reviews.llvm.org/rC321614https://reviews.llvm.org/rC321615
llvm-svn: 321622
- the enum changes to TypeSpecifierType are breaking some tests - and will require a more careful integration.
Sorry about rushing these changes - thought I could sneak them in prior to heading out for new years ;)
llvm-svn: 321616
Suggest moving the following erroneous attrib list (based on location)
[[]] struct X;
to
struct [[]] X;
Additionally, added a fixme for the current implementation that diagnoses misplaced attributes to consider using the newly introduced diagnostic (that I think is more user-friendly).
llvm-svn: 321449
This patch addresses a FIXME and has the template-parameter processing functions return a more derived common type NamedDecl (as opposed to a type needlessly higher up in the inheritance hierarchy : Decl).
llvm-svn: 321409
Adding the new enumerator forced a bunch more changes into this patch than I
would have liked. The -Wtautological-compare warning was extended to properly
check the new comparison operator, clang-format needed updating because it uses
precedence levels as weights for determining where to break lines (and several
operators increased their precedence levels with this change), thread-safety
analysis needed changes to build its own IL properly for the new operator.
All "real" semantic checking for this operator has been deferred to a future
patch. For now, we use the relational comparison rules and arbitrarily give
the builtin form of the operator a return type of 'void'.
llvm-svn: 320707
Summary:
This feature was discussed but not yet proposed. It allows a structured binding to appear as a //condition//
if (auto [ok, val] = f(...))
So the user can save an extra //condition// if the statement can test the value to-be-decomposed instead. Formally, it makes the value of the underlying object of the structured binding declaration also the value of a //condition// that is an initialized declaration.
Considering its logicality which is entirely evident from its trivial implementation, I think it might be acceptable to land it as an extension for now before I write the paper.
Reviewers: rsmith, faisalv, aaron.ballman
Reviewed By: rsmith
Subscribers: aaron.ballman, cfe-commits
Differential Revision: https://reviews.llvm.org/D39284
llvm-svn: 320011
Summary:
This is so we can implement concepts per P0734R0. Relevant failing test
cases are disabled.
Reviewers: hubert.reinterpretcast, rsmith, saar.raz, nwilson
Reviewed By: saar.raz
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D40380
Patch by Changyu Li!
llvm-svn: 319992
OpenMP 5.0 introduces asynchronous data update/dependecies clauses on
target data directives. Patch adds initial support for outer task
regions to use task-based codegen for future async target data
directives.
llvm-svn: 318781
This implements [dcl.modules.export] from the C++ Modules TS, which lets a module re-export another module with the "export import" syntax.
Differential Revision: https://reviews.llvm.org/D40270
llvm-svn: 318744
It seems this somehow made -Wempty-body fire in some macro cases where
it didn't before, e.g.
../../third_party/ffmpeg/libavcodec/bitstream.c(169,5): error: if statement has empty body [-Werror,-Wempty-body]
ff_dlog(NULL, "new table index=%d size=%d\n", table_index, table_size);
^
../../third_party/ffmpeg\libavutil/internal.h(276,80): note: expanded from macro 'ff_dlog'
# define ff_dlog(ctx, ...) do { if (0) av_log(ctx, AV_LOG_DEBUG, __VA_ARGS__); } while (0)
^
../../third_party/ffmpeg/libavcodec/bitstream.c(169,5): note: put the
semicolon on a separate line to silence this warning
Reverting until this can be figured out.
> Do not show it when `if` or `else` come from macros.
> E.g.,
>
> #define USED(A) if (A); else
> #define SOME_IF(A) if (A)
>
> void test() {
> // No warnings are shown in those cases now.
> USED(0);
> SOME_IF(0);
> }
>
> Patch by Ilya Biryukov!
>
> Differential Revision: https://reviews.llvm.org/D40185
llvm-svn: 318665
Do not show it when `if` or `else` come from macros.
E.g.,
#define USED(A) if (A); else
#define SOME_IF(A) if (A)
void test() {
// No warnings are shown in those cases now.
USED(0);
SOME_IF(0);
}
Patch by Ilya Biryukov!
Differential Revision: https://reviews.llvm.org/D40185
llvm-svn: 318556
The right shift operator was not seen as a valid operator in a fold expression, which is PR32563.
Patch by Nicolas Lesser ("Blitz Rakete")!
llvm-svn: 317032
With enabled CINDEXTEST_CODE_COMPLETE_PATTERNS env option (which enables
IncludeCodePatterns in completion options) code completion after colon
currently suggests access modifiers with 2 completion chunks which is
incorrect.
Example:
class A : <Cursor>B
{
}
Currently we get 'NotImplemented:{TypedText public}{Colon :} (40)'
but the correct line is just 'NotImplemented:{TypedText public} (40)'
The fix introduces more specific scope that occurs between ':' and '{'
It allows us to determine when we don't need to add ':' as a second
chunk to the public/protected/private access modifiers.
Patch by Ivan Donchevskii!
Differential Revision: https://reviews.llvm.org/D38618
llvm-svn: 316436
Treat 'f()' as 'f(void)' rather than a function w/o a prototype.
Reviewers: Anastasia, yaxunl
Reviewed By: Anastasia, yaxunl
Subscribers: cfe-commits, echuraev, chapuni
Differential Revision: https://reviews.llvm.org/D33681
Re-apply revision 306653.
llvm-svn: 315453
declaration.
Patch allows using of the `#pragma omp declare target`| `#pragma omp end
declare target` directives inside the structures if we need to mark as
declare target only some static members.
llvm-svn: 314833
Allow the proper recognition of Enum values and global variables inside ms inline-asm memory / immediate expressions, as they require some additional overhead and treated incorrect if doesn't early recognized.
supersedes D33278, D35774
Differential Revision: https://reviews.llvm.org/D37413
llvm-svn: 314494
This implements the proposed approach in https://github.com/itanium-cxx-abi/cxx-abi/issues/33
This reinstates r313827, reverted in r313856, with a fix for the 'out-of-bounds
enumeration value' ubsan error in that change.
llvm-svn: 313955
This is a recommit of r312781; in some build configurations
variable names are omitted, so changed the new regression
test accordingly.
llvm-svn: 312794
Summary: The crash occured when FunctionDecl was parsed with an initializer.
Reviewers: bkramer, klimek, francisco.lopes
Reviewed By: bkramer
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D37382
llvm-svn: 312788
This adds _Float16 as a source language type, which is a 16-bit floating point
type defined in C11 extension ISO/IEC TS 18661-3.
In follow up patches documentation and more tests will be added.
Differential Revision: https://reviews.llvm.org/D33719
llvm-svn: 312781
When we have enabled cache for global completions we did not have
diagnostics for Bar and could not complete Ba as in provided code
example.
template <typename T>
struct Foo { T member; };
template<typename T> using Bar = Foo<T>;
int main() {
Ba
}
(This is the fixed version of r 311442, which was reverted in r311445.)
Patch by Ivan Donchevskii!
Differential Revision: https://reviews.llvm.org/D35355
llvm-svn: 312780
move constructor.
Previously user-defined reduction initializer was considered as an
assignment expression, not as initializer. Fixed this by treating the
initializer expression as an initializer.
llvm-svn: 312638
This is the same assertion as in https://reviews.llvm.org/D25206 that is
triggered when RecordLayoutBuilder tries to compute the size of a field
(for capture "typo_boo" in the test case) whose type hasn't been
deduced.
The fix is to add CorrectDelayedTyposInExpr call to the cases when we
aren't disambiguating between an Obj-C message send and a lambda
expression.
rdar://problem/31760839
Reviewers: rsmith, ahatanak
Reviewed By: arphaman
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D36853
llvm-svn: 311480
When we have enabled cache for global completions we did not have
diagnostics for Bar and could not complete Ba as in provided code
example.
template <typename T>
struct Foo { T member; };
template<typename T> using Bar = Foo<T>;
int main() {
Ba
}
Patch by Ivan Donchevskii!
Differential Revision: https://reviews.llvm.org/D35355
llvm-svn: 311442
Summary:
The crash occurs when the first token after a preamble is a macro
expansion.
Fixed by moving replayPreambleConditionalStack from Parser into
Preprocessor. It is now called right after the predefines file is
processed.
Reviewers: erikjv, bkramer, klimek, yvvan
Reviewed By: bkramer
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D36872
llvm-svn: 311330
the class becoming complete and its inline methods being parsed.
This replaces the hack of using the "late parsed template" flag to track member
functions with bodies we've not parsed yet; instead we now use the "will have
body" flag, which carries the desired implication that the function declaration
*is* a definition, and that we've just not parsed its body yet.
llvm-svn: 310776
Such implicitly declared functions behave as if the enclosing block
contained the declaration extern int name() (C90, 6.3.3.2 Function calls),
thus their names should have block scope (C90, 6.1.2.1 Scope of identifiers).
This patch fixes https://bugs.llvm.org/show_bug.cgi?id=33224
Differential Revision: https://reviews.llvm.org/D33676
llvm-svn: 310616
'#pragma pack (pop)' and suspicious uses of '#pragma pack' in included files
The second recommit (r309106) was reverted because the "non-default #pragma
pack value chages the alignment of struct or union members in the included file"
warning proved to be too aggressive for external projects like Chromium
(https://bugs.chromium.org/p/chromium/issues/detail?id=749197). This recommit
makes the problematic warning a non-default one, and gives it the
-Wpragma-pack-suspicious-include warning option.
The first recommit (r308441) caused a "non-default #pragma pack value might
change the alignment of struct or union members in the included file" warning
in LLVM itself. This recommit tweaks the added warning to avoid warnings for
#includes that don't have any records that are affected by the non-default
alignment. This tweak avoids the previously emitted warning in LLVM.
Original message:
This commit adds a new -Wpragma-pack warning. It warns in the following cases:
- When a translation unit is missing terminating #pragma pack (pop) directives.
- When entering an included file if the current alignment value as determined
by '#pragma pack' directives is different from the default alignment value.
- When leaving an included file that changed the state of the current alignment
value.
rdar://10184173
Differential Revision: https://reviews.llvm.org/D35484
llvm-svn: 309386
The warning fires on non-suspicious code in Chromium. Reverting until a
solution is figured out.
> Recommit r308327 2nd time: Add a warning for missing
> '#pragma pack (pop)' and suspicious uses of '#pragma pack' in included files
>
> The first recommit (r308441) caused a "non-default #pragma pack value might
> change the alignment of struct or union members in the included file" warning
> in LLVM itself. This recommit tweaks the added warning to avoid warnings for
> #includes that don't have any records that are affected by the non-default
> alignment. This tweak avoids the previously emitted warning in LLVM.
>
> Original message:
>
> This commit adds a new -Wpragma-pack warning. It warns in the following cases:
>
> - When a translation unit is missing terminating #pragma pack (pop) directives.
> - When entering an included file if the current alignment value as determined
> by '#pragma pack' directives is different from the default alignment value.
> - When leaving an included file that changed the state of the current alignment
> value.
>
> rdar://10184173
>
> Differential Revision: https://reviews.llvm.org/D35484
llvm-svn: 309186
'#pragma pack (pop)' and suspicious uses of '#pragma pack' in included files
The first recommit (r308441) caused a "non-default #pragma pack value might
change the alignment of struct or union members in the included file" warning
in LLVM itself. This recommit tweaks the added warning to avoid warnings for
#includes that don't have any records that are affected by the non-default
alignment. This tweak avoids the previously emitted warning in LLVM.
Original message:
This commit adds a new -Wpragma-pack warning. It warns in the following cases:
- When a translation unit is missing terminating #pragma pack (pop) directives.
- When entering an included file if the current alignment value as determined
by '#pragma pack' directives is different from the default alignment value.
- When leaving an included file that changed the state of the current alignment
value.
rdar://10184173
Differential Revision: https://reviews.llvm.org/D35484
llvm-svn: 309106
This seems to have broken the sanitizer-x86_64-linux buildbot. Reverting until
it's fixed, especially since this landed just before the 5.0 branch.
> This commit adds a new -Wpragma-pack warning. It warns in the following cases:
>
> - When a translation unit is missing terminating #pragma pack (pop) directives.
> - When entering an included file if the current alignment value as determined
> by '#pragma pack' directives is different from the default alignment value.
> - When leaving an included file that changed the state of the current alignment
> value.
>
> rdar://10184173
>
> Differential Revision: https://reviews.llvm.org/D35484
llvm-svn: 308455
and suspicious uses of '#pragma pack' in included files
This commit adds a new -Wpragma-pack warning. It warns in the following cases:
- When a translation unit is missing terminating #pragma pack (pop) directives.
- When entering an included file if the current alignment value as determined
by '#pragma pack' directives is different from the default alignment value.
- When leaving an included file that changed the state of the current alignment
value.
rdar://10184173
Differential Revision: https://reviews.llvm.org/D35484
llvm-svn: 308441
of '#pragma pack' in included files
This commit adds a new -Wpragma-pack warning. It warns in the following cases:
- When a translation unit is missing terminating #pragma pack (pop) directives.
- When entering an included file if the current alignment value as determined
by '#pragma pack' directives is different from the default alignment value.
- When leaving an included file that changed the state of the current alignment
value.
rdar://10184173
Differential Revision: https://reviews.llvm.org/D35484
llvm-svn: 308327
Allow ODR for ObjC/C in the sense that we won't keep more that
one definition around (merge them). However, ensure the decl
pass the structural compatibility check in C11 6.2.7/1, for that,
reuse the structural equivalence checks used by the ASTImporter.
Few other considerations:
- Create error diagnostics for tag types mismatches and thread
them into the structural equivalence checks.
- Note that by doing this we only support redefinition between types
that are considered "compatible types" by C.
This is mixed approach of the suggestions discussed in
http://lists.llvm.org/pipermail/cfe-dev/2017-March/053257.html
Differential Revision: https://reviews.llvm.org/D31778
rdar://problem/31909368
llvm-svn: 306918
definition or non-reference class type.
The crash occurs when there is a template parameter list in a class that
is missing the closing angle bracket followed by a definition of a
struct. For example:
class C0 {
public:
template<typename T, typename T1 = T // missing closing angle bracket
struct S0 {};
C0() : m(new S0<int>) {}
S0<int> *m;
};
This happens because the parsed struct is added to the scope of the
enclosing class without having its access specifier set, which results
in an assertion failure in SemaAccess.cpp later.
This commit fixes the crash by adding the parsed struct to the enclosing
file scope and marking structs as invalid if they are defined in
template parameter lists.
rdar://problem/31783961
rdar://problem/19570630
Differential Revision: https://reviews.llvm.org/D33606
llvm-svn: 306317
This change avoid a crash that occurred when skipping to EOF while parsing an
ObjC interface/implementation.
rdar://31963299
Differential Revision: https://reviews.llvm.org/D34185
llvm-svn: 305719
This patch provides a means to specify section-names for global variables,
functions and static variables, using #pragma directives.
This feature is only defined to work sensibly for ELF targets.
One can specify section names as:
#pragma clang section bss="myBSS" data="myData" rodata="myRodata" text="myText"
One can "unspecify" a section name with empty string e.g.
#pragma clang section bss="" data="" text="" rodata=""
Reviewers: Roger Ferrer, Jonathan Roelofs, Reid Kleckner
Differential Revision: https://reviews.llvm.org/D33412
llvm-svn: 304705
A refactoring of TemplateIdAnnotation that uses TrailingObjects to create a variably-sized object on the heap.
https://reviews.llvm.org/D31414
Thanks to Aaron B for the review!
llvm-svn: 303594
This patch ensures that clang processes the expression-nodes that are generated when disambiguating between types and expressions within template arguments as constant-expressions by installing the ConstantEvaluated ExpressionEvaluationContext just before attempting the disambiguation - and then making sure that Context carries through into ParseConstantExpression (by refactoring it out into a function that does not create its own EvaluationContext: ParseConstantExpressionInExprEvalContext)
Note, prior to this patch, trunk would correctly disambiguate and identify the expression as an expression - and while it would annotate the token with the expression - it would fail to complete the odr-use processing (specifically, failing to trigger Sema::UpdateMarkingForLValueToRValue as is done for all Constant Expressions, which would remove it from being considered odr-used). By installing the ConstantExpression Evaluation Context prior to disambiguation, and making sure it carries though, we ensure correct processing of the expression-node.
For e.g:
template<int> struct X { };
void f() {
const int N = 10;
X<N> x; // should be OK.
[] { return X<N>{}; }; // Should be OK - no capture - but clang errors!
}
See a related bug: https://bugs.llvm.org//show_bug.cgi?id=25627
In summary (and reiteration), the fix is as follows:
- Remove the EnteredConstantEvaluatedContext action from ParseTemplateArgumentList (relying on ParseTemplateArgument getting it right)
- Add the EnteredConstantEvaluatedContext action just prior to undergoing the disambiguating parse, and if the parse succeeds for an expression, carry the context though into a refactored version of ParseConstantExpression that does not create its own ExpressionEvaluationContext.
See https://reviews.llvm.org/D31588 for additional context regarding some of the more fragile and complicated approaches attempted, and Richard's feedback that eventually shaped the simpler and more robust rendition that is being committed.
Thanks Richard!
llvm-svn: 303492
Summary:
The trial parse for declarative syntax accepts an invalid pack
declaration syntax, which is ambiguous with valid pack expansions of
expressions. This commit removes the invalid pack declaration syntax to
avoid mistaking valid pack expansions as invalid declarator components.
Additionally, the trial parse of a //template-argument-list// then needs
to handle the optional ellipsis that is part of that grammar, as opposed
to relying on the trial parse for declarators accepting stray ellipses.
Reviewers: rsmith, rcraik, aaron.ballman
Reviewed By: rsmith
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D33339
llvm-svn: 303472
We were incorrectly setting PrevTokLocation to the first token in the
annotation token instead of the last when consuming it. To fix this without
adding a complex switch to the hot path through ConsumeToken, we now have a
ConsumeAnnotationToken function for consuming annotation tokens in addition
to the other Consume*Token special case functions.
llvm-svn: 303372
When an undeclared identifier in a context that requires a type is followed by
'<', only look for type templates when typo-correcting, tweak the diagnostic
text to say that a template name (not a type name) was undeclared, and parse
the template arguments when recovering from the error.
llvm-svn: 302732
The heuristic that we use here is:
* the left-hand side must be a simple identifier or a class member access
* the right-hand side must be '<' followed by either a '>' or by a type-id that
cannot be an expression (in particular, not followed by '(' or '{')
* there is a '>' token matching the '<' token
The second condition guarantees the expression would otherwise be ill-formed.
If we're confident that the user intended the name before the '<' to be
interpreted as a template, diagnose the fact that we didn't interpret it
that way, rather than diagnosing that the template arguments are not valid
expressions.
llvm-svn: 302615
`__builtin_available`
This commit allows us to use the macOS/iOS/tvOS/watchOS platform names in
`@available`/`__builtin_available`.
rdar://32067795
Differential Revision: https://reviews.llvm.org/D33000
llvm-svn: 302540
https://reviews.llvm.org/D32807
This patch allows the map modifier 'always' to be separated by the map type (to, from, tofrom) only by a whitespace, rather than strictly by a comma as in current trunk.
llvm-svn: 302031
This switches from the prototype syntax in P0273R0 ('module' and 'module
implementation') to the consensus syntax 'export module' and 'module'.
In passing, drop the "module declaration must be first" enforcement, since EWG
seems to have changed its mind on that.
llvm-svn: 301056
This commit teaches Clang to recognize editor placeholders that are produced
when an IDE like Xcode inserts a code-completion result that includes a
placeholder. Now when the lexer sees a placeholder token, it emits an
'editor placeholder in source file' error and creates an identifier token
that represents the placeholder. The parser/sema can now recognize the
placeholders and can suppress the diagnostics related to the placeholders. This
ensures that live issues in an IDE like Xcode won't get spurious diagnostics
related to placeholders.
This commit also adds a new compiler option named '-fallow-editor-placeholders'
that silences the 'editor placeholder in source file' error. This is useful
for an IDE like Xcode as we don't want to display those errors in live issues.
rdar://31581400
Differential Revision: https://reviews.llvm.org/D32081
llvm-svn: 300667
This is a recommit of r300539 that was reverted in r300543 due to test failures.
The original commit message is displayed below:
The new '#pragma clang attribute' directive can be used to apply attributes to
multiple declarations. An attribute must satisfy the following conditions to
be supported by the pragma:
- It must have a subject list that's defined in the TableGen file.
- It must be documented.
- It must not be late parsed.
- It must have a GNU/C++11 spelling.
Differential Revision: https://reviews.llvm.org/D30009
llvm-svn: 300556
The new '#pragma clang attribute' directive can be used to apply attributes to
multiple declarations. An attribute must satisfy the following conditions to
be supported by the pragma:
- It must have a subject list that's defined in the TableGen file.
- It must be documented.
- It must not be late parsed.
- It must have a GNU/C++11 spelling.
Differential Revision: https://reviews.llvm.org/D30009
llvm-svn: 300539
as identifiers in Objective-C++
This commit improves the 'expected identifier' errors that are presented when a
C++ keyword is used as an identifier in Objective-C++ by mentioning that this is
a C++ keyword in the diagnostic message. It also improves the error recovery:
the parser will now treat the C++ keywords as identifiers to prevent unrelated
parsing errors.
rdar://20626062
Differential Revision: https://reviews.llvm.org/D26503
llvm-svn: 299950
This adds the new pragma and the first variant, contract(on/off/fast).
The pragma has the same block scope rules as STDC FP_CONTRACT, i.e. it can be
placed at the beginning of a compound statement or at file scope.
Similarly to STDC FP_CONTRACT there is no need to use attributes. First an
annotate token is inserted with the parsed details of the pragma. Then the
annotate token is parsed in the proper contexts and the Sema is updated with
the corresponding FPOptions using the shared ActOn function with STDC
FP_CONTRACT.
After this the FPOptions from the Sema is propagated into the AST expression
nodes. There is no change here.
I was going to add a 'default' option besides 'on/off/fast' similar to STDC
FP_CONTRACT but then decided against it. I think that we'd have to make option
uppercase then to avoid using 'default' the keyword. Also because of the
scoped activation of pragma I am not sure there is really a need a for this.
Differential Revision: https://reviews.llvm.org/D31276
llvm-svn: 299470
- also replace direct equality checks against the ConstantEvaluated enumerator with isConstantEvaluted(), in anticipation of adding finer granularity to the various ConstantEvaluated contexts and reinstating certain restrictions on where lambda expressions can occur in C++17.
- update the clang tablegen backend that uses these Enumerators, and add the relevant scope where needed.
llvm-svn: 299316
Alexey Bataev