These flags control the inheritance model initially used by the
translation unit.
Differential Revision: http://llvm-reviews.chandlerc.com/D2741
llvm-svn: 201175
Introduce a notion of a 'current representation method' for
pointers-to-members.
When starting out, this is set to 'best case' (representation method is
chosen by examining the class, selecting the smallest representation
that would work given the class definition or lack thereof).
This pragma allows the translation unit to dictate exactly what
representation to use, similar to how the inheritance model keywords
operate.
N.B. PCH support is forthcoming.
Differential Revision: http://llvm-reviews.chandlerc.com/D2723
llvm-svn: 201105
A return type is the declared or deduced part of the function type specified in
the declaration.
A result type is the (potentially adjusted) type of the value of an expression
that calls the function.
Rule of thumb:
* Declarations have return types and parameters.
* Expressions have result types and arguments.
llvm-svn: 200082
allow this, and we should warn on it, but it turns out that people were already
relying on this.
We should introduce a -Wgcc-compat warning for this if the attributes are known
to GCC, but we don't currently track enough information about attributes to do
so reliably.
llvm-svn: 200045
member-declaration. In the process, fix a couple of bugs that had crept in
where we would parse the first and subsequent member-declarators differently
(in particular, we didn't accept an asm-label on a member function definition
within a class, and we would accept virt-specifiers and attributes in the wrong
order on the first declarator but not on subsequent ones).
llvm-svn: 199957
Due to statement expressions supported as GCC extension, it is possible
to put 'break' or 'continue' into a loop/switch statement but outside
its body, for example:
for ( ; ({ if (first) { first = 0; continue; } 0; }); )
This code is rejected by GCC if compiled in C mode but is accepted in C++
code. GCC bug 44715 tracks this discrepancy. Clang used code generation
that differs from GCC in both modes: only statement of the third
expression of 'for' behaves as if it was inside loop body.
This change makes code generation more close to GCC, considering 'break'
or 'continue' statement in condition and increment expressions of a
loop as it was inside the loop body. It also adds error for the cases
when 'break'/'continue' appear outside loop due to this syntax. If
code generation differ from GCC, warning is issued.
Differential Revision: http://llvm-reviews.chandlerc.com/D2518
llvm-svn: 199897
Lift the getFunctionDecl() utility out of the parser into a general
Decl::getAsFunction() and use it to simplify other parts of the implementation.
Reduce isFunctionOrFunctionTemplate() to a simple type check that works the
same was as the other is* functions and move unwrapping of shadowed decls to
callers so it doesn't get run twice.
Shuffle around canSkipFunctionBody() to reduce virtual dispatch on ASTConsumer.
There's no need to query when we already know the body can't be skipped.
llvm-svn: 199794
handling C++11 default initializers. Without this, other parts of Sema (such as
lambda capture) would think the default initializer is part of the surrounding
function scope.
llvm-svn: 199453
Changes made in r192200 fixed PR16992, which requested fixit suggesting
parenthesis if sizeof is followed by type-id. However expression in form
T() followed by ')' was incorrectly considered as a type-id if 'T' is
typedef name. This change fixes this case.
Differential Revision: http://llvm-reviews.chandlerc.com/D2440
llvm-svn: 199284
There's been long-standing confusion over the role of these two options. This
commit makes the necessary changes to differentiate them clearly, following up
from r198936.
MicrosoftExt (aka. fms-extensions):
Enable largely unobjectionable Microsoft language extensions to ease
portability. This mode, also supported by gcc, is used for building software
like FreeBSD and Linux kernel extensions that share code with Windows drivers.
MSVCCompat (aka. -fms-compatibility, formerly MicrosoftMode):
Turn on a special mode supporting 'heinous' extensions for drop-in
compatibility with the Microsoft Visual C++ product. Standards-compilant C and
C++ code isn't guaranteed to work in this mode. Implies MicrosoftExt.
Note that full -fms-compatibility mode is currently enabled by default on the
Windows target, which may need tuning to serve as a reasonable default.
See cfe-commits for the full discourse, thread 'r198497 - Move MS predefined
type_info out of InitializePredefinedMacros'
No change in behaviour.
llvm-svn: 199209
It's not worth keeping two copies of the identifier init and comparison code
just to save a pointer coparison.
This should reduce further once we get proper contextual keywords in the token
stream, so having the identifier checks in one place is a step towards that.
Cleanup only.
llvm-svn: 198814
type-specifier in C++. Some checks will assert in this case otherwise (in
particular, the access specifier may be missing if this happens inside a class
definition, due to a violation of an AST invariant).
llvm-svn: 198721
encodes the canonical rules for LLVM's style. I noticed this had drifted
quite a bit when cleaning up LLVM, so wanted to clean up Clang as well.
llvm-svn: 198686
This backs out changes in commit r198605 and part of r198604, replacing the
original tok::kw_template with a slightly more obvious placeholder
tok::unknown.
llvm-svn: 198666
Cover a hypothetical case when we might not have reached the final argument
declaration for some reason during recovery, and split out for readability.
llvm-svn: 198542
void knrNoSemi(i) int i { }
Adherents of The C Programming Language unfortunate enough to miss a semicolon
as above would be met with a cascade of errors spanning the remainder of the
TU.
This patch introduces a beautiful parse error recovery, complete with helpful
FixIt to restore sanity.
Before (output redacted for brevity):
error: 'error' diagnostics seen but not expected:
File declarators.c Line 119: declaration does not declare a parameter
File declarators.c Line 123: declaration does not declare a parameter
File declarators.c Line 127: parameter named 'func_E12' is missing
File declarators.c Line 127: expected ';' at end of declaration
File declarators.c Line 133: parameter named 'func_E13' is missing
File declarators.c Line 133: expected ';' at end of declaration
File declarators.c Line 139: parameter named 'func_E14' is missing
File declarators.c Line 139: expected ';' at end of declaration
File declarators.c Line 145: parameter named 'func_E15' is missing
File declarators.c Line 145: expected ';' at end of declaration
File declarators.c Line 150: expected function body after function declarator
File declarators.c Line 119: declaration of 'enum E11' will not be visible outside of this function
File declarators.c Line 123: declaration of 'enum E12' will not be visible outside of this function
File declarators.c Line 133: ISO C forbids forward references to 'enum' types
File declarators.c Line 133: declaration of 'enum E13' will not be visible outside of this function
File declarators.c Line 139: ISO C forbids forward references to 'enum' types
File declarators.c Line 139: declaration of 'enum E14' will not be visible outside of this function
File declarators.c Line 145: ISO C forbids forward references to 'enum' types
File declarators.c Line 145: declaration of 'enum E15' will not be visible outside of this function
...
After:
declarators.c:103:24: error: expected ';' at end of declaration
void knrNoSemi(i) int i { }
^
;
Patch found in a sealed envelope dated 1978 with the message "Do not open until
January 2014"
llvm-svn: 198540
Remove UnaryTypeTraitExpr and switch all remaining type trait related handling
over to TypeTraitExpr.
The UTT/BTT/TT enum prefix and evaluation code is retained pending further
cleanup.
This is part of the ongoing work to unify type traits following the removal of
BinaryTypeTraitExpr in r197273.
llvm-svn: 198271
1) Teach ExpectAndConsume() to emit expected and expected-after diagnostics
using the generic diagnostic descriptions added in r197972, eliminating another
set of trivial err_expected_* variations while maintaining existing behaviour.
2) Lift SkipUntil() recovery out of ExpectAndConsume(). The Expect/Consume
family of functions are primitive parser operations that now have the
well-defined property of operating on single tokens. Factoring out recovery
exposes opportunities for more consistent and tailored error recover at the
call sites instead of just relying on a bottled SkipUntil formula.
llvm-svn: 198270
Previously any error in enum definition body stopped parsing it. With this
change parser tries to recover from errors.
The patch fixes PR10982.
Differential Revision: http://llvm-reviews.chandlerc.com/D2018
llvm-svn: 198259
Introduce proper facilities to render token spellings using the diagnostic
formatter.
Replaces most of the hard-coded diagnostic messages related to expected tokens,
which all shared the same semantics but had to be multiply defined due to
variations in token order or quote marks.
The associated parser changes are largely mechanical but they expose
commonality in whole chunks of the parser that can now be factored away.
This commit uses C++11 typed enums along with a speculative legacy fallback
until the transition is complete.
Requires corresponding changes in LLVM r197895.
llvm-svn: 197972
The recovery was failing due to a missing case in SkipUntil().
Also add back tests from r197553 that were reverted in the previous commit.
llvm-svn: 197598
These parser changes were redundant. The same or better recovery can be
achieved with a one-line fix to SkipUntil() due to land in the next commit.
This reverts commit r197553.
llvm-svn: 197597
This commit kills off custom type specifier and keyword handling of OpenCL C
data types.
Although the OpenCL spec describes them as keywords, we can handle them more
elegantly as predefined types. This should provide better error correction and
code completion as well as simplifying the implementation.
The primary intention is however to simplify the C/C++ parser and save some
packed bits on AST structures that had been extended in r170432 just for
OpenCL.
llvm-svn: 197578
Avoid the gratuitous repurposing of C++ keyword 'private' by using a keyword
alias.
Also attempt to document the OpenCL keywords based on scraps of information
found online.
The purpose of this commit is to reduce impact on the C++ parser.
llvm-svn: 197511
1) Introduce TryConsumeToken() to handle the common test-and-consume pattern.
This brings about readability improvements in the parser and optimizes to avoid
redundant checks in the common case.
2) Eliminate the ConsumeCodeCompletionTok special case from ConsumeToken(). This
was used by only one caller which has been switched over to the more
appropriate ConsumeCodeCompletionToken() function.
llvm-svn: 197497
Now that we emit diagnostics for keyword-as-identifier hacks (-Wkeyword-compat)
we can go ahead and simplify some of the old revertible keyword support.
This commit adds a TryIdentKeywordUpgrade() function to mirror the recently
added TryKeywordIdentFallback() and uses it to replace the hard-coded list of
REVERTIBLE_TYPE_TRAITs.
llvm-svn: 197496
There's nothing special about type traits accepting two arguments.
This commit eliminates BinaryTypeTraitExpr and switches all related handling
over to TypeTraitExpr.
Also fixes a CodeGen failure with variadic type traits appearing in a
non-constant expression.
The BTT/TT prefix and evaluation code is retained as-is for now but will soon
be further cleaned up.
This is part of the ongoing work to unify type traits.
llvm-svn: 197273
Type trait parsing is all over the place at the moment with unary, binary and
n-ary C++11 type traits that were developed independently at different points
in clang's history.
There's no good reason to handle them separately -- there are three parsers,
three AST nodes and lots of duplicated handling code with slightly different
implementations and diags for each kind.
This commit unifies parsing of type traits and sets the stage for further
consolidation.
No change in behaviour other than more consistent error recovery.
llvm-svn: 197179
When parsing invalid top-level asm statements, we were ignoring the
return code of the SkipUntil we used for recovery. This led to crashes
when we hit the end of file and tried to continue parsing anyway.
This fixes the crash and adds a couple of tests for parsing related
problems.
llvm-svn: 196961
For an init capture, process the initialization expression
right away. For lambda init-captures such as the following:
const int x = 10;
auto L = [i = x+1](int a) {
return [j = x+2,
&k = x](char b) { };
};
keep in mind that each lambda init-capture has to have:
- its initialization expression executed in the context
of the enclosing/parent decl-context.
- but the variable itself has to be 'injected' into the
decl-context of its lambda's call-operator (which has
not yet been created).
Each init-expression is a full-expression that has to get
Sema-analyzed (for capturing etc.) before its lambda's
call-operator's decl-context, scope & scopeinfo are pushed on their
respective stacks. Thus if any variable is odr-used in the init-capture
it will correctly get captured in the enclosing lambda, if one exists.
The init-variables above are created later once the lambdascope and
call-operators decl-context is pushed onto its respective stack.
Since the lambda init-capture's initializer expression occurs in the
context of the enclosing function or lambda, therefore we can not wait
till a lambda scope has been pushed on before deciding whether the
variable needs to be captured. We also need to process all
lvalue-to-rvalue conversions and discarded-value conversions,
so that we can avoid capturing certain constant variables.
For e.g.,
void test() {
const int x = 10;
auto L = [&z = x](char a) { <-- don't capture by the current lambda
return [y = x](int i) { <-- don't capture by enclosing lambda
return y;
}
};
If x was not const, the second use would require 'L' to capture, and
that would be an error.
Make sure TranformLambdaExpr is also aware of this.
Patch approved by Richard (Thanks!!)
http://llvm-reviews.chandlerc.com/D2092
llvm-svn: 196454
We would skip until the next comma, hoping good things whould lie there,
however this would fail when we have such things as this:
struct A {};
template <typename>
struct D;
template <>
struct D<C> : B, A::D;
Once this happens, we would believe that D with a nested namespace
specifier of A was a variable that was being declared. We would go on
to complain that there was an extraneous 'template <>' on their variable
declaration.
Crashes would happen when 'A' gets defined as 'enum class A {}' as
various asserts would fire.
Instead, we should skip up until the semicolon if we see that we are in
the middle of a definition and the current token is a ':'
This fixes PR17084.
llvm-svn: 196453
nested-name-specifier, rather than crashing. (In fact, reject all
literal-operator-ids that have a non-namespace nested-name-specifier). The
grammar doesn't allow these in some cases, and in other cases does allow them
but instantiation will always fail.
llvm-svn: 196443
which specifies couple of (optional) method selectors
for bridging a CFobject to or from an ObjectiveC
object. This is wip. // rdsr://15499111
llvm-svn: 196408
In delayed template parsing mode, adjust the template depth counter for each template parameter list associated with an out of line member template specialization.
llvm-svn: 196351
clang converts keywords to identifiers for compatibility with various system
headers such as GNU libc.
Implement a -Wkeyword-compat extension warning to diagnose those cases. The
warning is on by default but will generally be ignored in system headers. It
can however be enabled globally to aid standards conformance testing.
This also changes the __uptr keyword avoidance from r195710 to no longer
special-case system headers, bringing it in line with other similar workarounds
in clang.
Implementation returns bool for symmetry with token annotation functions.
Some examples:
warning: keyword '__is_pod' will be treated as an identifier for the remainder of the translation unit [-Wkeyword-compat]
struct __is_pod
warning: keyword '__uptr' will be treated as an identifier here [-Wkeyword-compat]
union w *__uptr;
llvm-svn: 196212
lookup, if parsing failed, we did not restore the lexer state properly, and
eventually crashed. This change ensures that we always consume all the tokens
from the new token stream we started to parse the name from inline asm.
llvm-svn: 196182
GNU libc uses '__uptr' as a member name in C mode, conflicting with the
eponymous MSVC pointer modifier keyword.
Detect and mark the token as an identifier when these specific conditions are
met. __uptr will continue to work as a keyword for the remainder of the
translation unit.
Fixes PR17824.
llvm-svn: 195710
MSVC applies these to the following declaration only if present, otherwise
silently ignores them whereas we'll issue a warning.
Handling differs from ordinary attributes appearing in the same place, so add a
Sema test to make sure we get it right.
llvm-svn: 195577
module. Use the marker to diagnose cases where we try to transition between
submodules when not at the top level (most likely because a closing brace was
missing at the end of a header file, but is also possible if submodule headers
attempt to do something fundamentally non-modular, like our .def files).
llvm-svn: 195543
and we see an ill-formed declarator that would probably be well-formed if the
tag definition were just missing a semicolon, use that as the diagnostic
instead of producing some other mysterious error.
llvm-svn: 195163
the GNU documentation: the attribute only appertains to the label if it is
followed by a semicolon. Based on a patch by Aaron Ballman!
llvm-svn: 194869
representing the module import rather than making the module immediately
visible. This serves two goals:
* It avoids making declarations in the module visible prematurely, if we
walk past the #include during a tentative parse, for instance, and
* It gives a diagnostic (although, admittedly, not a very nice one) if
a header with a corresponding module is included anywhere other than
at the top level.
llvm-svn: 194782
This patch fixes PR8264. Duplicate qualifiers already are diagnozed,
now the same diagnostics is issued for duplicate function specifiers.
Differential Revision: http://llvm-reviews.chandlerc.com/D2025
llvm-svn: 194559
definition. If we see something that looks like a namespace definition inside a
class, that strongly indicates that a close brace was missing somewhere.
llvm-svn: 194319
Summary:
Similar to __FUNCTION__, MSVC exposes the name of the enclosing mangled
function name via __FUNCDNAME__. This implementation is very naive and
unoptimized, it is expected that __FUNCDNAME__ would be used rarely in
practice.
Reviewers: rnk, rsmith, thakis
CC: cfe-commits, silvas
Differential Revision: http://llvm-reviews.chandlerc.com/D2109
llvm-svn: 194181
Similar C code isn't caught as it seems to hit a different code path.
Also, as the check is only done for record pointers, cases involving
an overloaded operator-> are not handled either. Note that the reason
this check is done in the parser instead of Sema is not related to
having enough knowledge about the current state as it is about being
able to fix up the parser's state to be able to recover and traverse the
correct code paths.
llvm-svn: 194002
- can't think of a way to test this without generic lambda captures, but will include a test once that patch is made commit-ready.
patch was ok'd by Doug.
http://llvm-reviews.chandlerc.com/D2029
llvm-svn: 193757
into a separate "parse an attribute that takes a type argument" codepath. This
results in both codepaths being a lot cleaner and simpler, and fixes some bugs
where the type argument handling bled into the expression argument handling and
caused us to both accept invalid and reject valid attribute arguments.
llvm-svn: 193731
It's possible to embed the frontend in applications that haven't initialized
backend targets so we need to handle this condition gracefully.
llvm-svn: 193685
which we don't think can't have one, only allow it in the tiny number of
attributes which opts into this weird parse rule.
I've manually checked that the handlers for all these attributes can in fact
cope with an identifier as the argument. This is still somewhat terrible; we
should move more fully towards picking the parsing rules based on the
attribute, and make the Parse -> Sema interface more type-safe.
llvm-svn: 193295
David Majnemer