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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@301056 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@300667 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@300556 91177308-0d34-0410-b5e6-96231b3b80d8
Some tests fail on the Windows buildbots. I will have to investigate more.
This commit reverts r300539, r300540 and r300542.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@300543 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@300539 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@299950 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@299470 91177308-0d34-0410-b5e6-96231b3b80d8
Some clients (eg the cling interpreter) need to recover their parser from
errors.
Patch by Axel Naumann (D31190)!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@298606 91177308-0d34-0410-b5e6-96231b3b80d8
and the nature of a declaration
This commit adds an external_source_symbol attribute to Clang. This attribute
specifies that a declaration originates from an external source and describes
the nature of that source. This attribute will be used to improve IDE features
like 'jump-to-definition' for mixed-language projects or project that use
auto-generated code.
rdar://30423368
Differential Revision: https://reviews.llvm.org/D29819
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@296649 91177308-0d34-0410-b5e6-96231b3b80d8
We model deduction-guides as functions with a new kind of name that identifies
the template whose deduction they guide; the bulk of this patch is adding the
new name kind. This gives us a clean way to attach an extensible list of guides
to a class template in a way that doesn't require any special handling in AST
files etc (and we're going to need these functions we come to performing
deduction).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@294266 91177308-0d34-0410-b5e6-96231b3b80d8
This change adds a new type node, DeducedTemplateSpecializationType, to
represent a type template name that has been used as a type. This is modeled
around AutoType, and shares a common base class for representing a deduced
placeholder type.
We allow deduced class template types in a few more places than the standard
does: in conditions and for-range-declarators, and in new-type-ids. This is
consistent with GCC and with discussion on the core reflector. This patch
does not yet support deduced class template types being named in typename
specifiers.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@293207 91177308-0d34-0410-b5e6-96231b3b80d8
Under this defect resolution, the injected-class-name of a class or class
template cannot be used except in very limited circumstances (when declaring a
constructor, in a nested-name-specifier, in a base-specifier, or in an
elaborated-type-specifier). This is apparently done to make parsing easier, but
it's a pain for us since we don't know whether a template-id using the
injected-class-name is valid at the point when we annotate it (we don't yet
know whether the template-id will become part of an elaborated-type-specifier).
As a tentative resolution to a perceived language defect, mem-initializer-ids
are added to the list of exceptions here (they generally follow the same rules
as base-specifiers).
When the reference to the injected-class-name uses the 'typename' or 'template'
keywords, we permit it to be used to name a type or template as an extension;
other compilers also accept some cases in this area. There are also a couple of
corner cases with dependent template names that we do not yet diagnose, but
which will also get this treatment.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@292518 91177308-0d34-0410-b5e6-96231b3b80d8
This flag serves no purpose other than to prevent us walking through a type to
check whether it contains an 'auto' specifier; this duplication of information
is error-prone, does not appear to provide any performance benefit, and will
become less practical once we support C++1z deduced class template types and
eventually constrained types from the Concepts TS.
No functionality change intended.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@291737 91177308-0d34-0410-b5e6-96231b3b80d8
Added a map to associate types and declarations with extensions.
Refactored existing diagnostic for disabled types associated with extensions and extended it to declarations for generic situation.
Fixed some bugs for types associated with extensions.
Allow users to use pragma to declare types and functions for supported extensions, e.g.
#pragma OPENCL EXTENSION the_new_extension_name : begin
// declare types and functions associated with the extension here
#pragma OPENCL EXTENSION the_new_extension_name : end
Differential Revision: https://reviews.llvm.org/D21698
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@289979 91177308-0d34-0410-b5e6-96231b3b80d8
import can't appear here" diagnostic if an already-visible module is textually
entered (because we have the module map but not the AST file) within a
function/namespace scope.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@288737 91177308-0d34-0410-b5e6-96231b3b80d8
Fix a crash-on-invalid.
When parsing type arguments and protocols,
parseObjCTypeArgsOrProtocolQualifiers() calls ParseTypeName(), which tries to
find matching tokens for '[', '(', etc whenever they appear among potential
type names. If unmatched, ParseTypeName() yields a tok::eof token stream. This
leads to crashes since the parsing at this point is not expected to go beyond
the param list closing '>'.
Fix that by properly handling tok::eof in
parseObjCTypeArgsOrProtocolQualifiers() callers.
Differential Revision: https://reviews.llvm.org/D23852
rdar://problem/25063557
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@281383 91177308-0d34-0410-b5e6-96231b3b80d8
export-declarations. These don't yet have an effect on name visibility;
we still export everything by default.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@280999 91177308-0d34-0410-b5e6-96231b3b80d8
The comment starting with "ParseDeclarationOrFunctionDefinition -" is above
a function called ParseDeclOrFunctionDefInternal. Fix the comment by not
mentioning a function name, like the style guide requests nowadays. No behavior
change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@280572 91177308-0d34-0410-b5e6-96231b3b80d8
r280133. Original commit message:
C++ Modules TS: driver support for building modules.
This works as follows: we add --precompile to the existing gamut of options for
specifying how far to go when compiling an input (-E, -c, -S, etc.). This flag
specifies that an input is taken to the precompilation step and no further, and
this can be specified when building a .pcm from a module interface or when
building a .pch from a header file.
The .cppm extension (and some related extensions) are implicitly recognized as
C++ module interface files. If --precompile is /not/ specified, the file is
compiled (via a .pcm) to a .o file containing the code for the module (and then
potentially also assembled and linked, if -S, -c, etc. are not specified). We
do not yet suppress the emission of object code for other users of the module
interface, so for now this will only work if everything in the .cppm file has
vague linkage.
As with the existing support for module-map modules, prebuilt modules can be
provided as compiler inputs either via the -fmodule-file= command-line argument
or via files named ModuleName.pcm in one of the directories specified via
-fprebuilt-module-path=.
This also exposes the -fmodules-ts cc1 flag in the driver. This is still
experimental, and in particular, the concrete syntax is subject to change as
the Modules TS evolves in the C++ committee. Unlike -fmodules, this flag does
not enable support for implicitly loading module maps nor building modules via
the module cache, but those features can be turned on separately and used in
conjunction with the Modules TS support.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@280134 91177308-0d34-0410-b5e6-96231b3b80d8
This works as follows: we add --precompile to the existing gamut of options for
specifying how far to go when compiling an input (-E, -c, -S, etc.). This flag
specifies that an input is taken to the precompilation step and no further, and
this can be specified when building a .pcm from a module interface or when
building a .pch from a header file.
The .cppm extension (and some related extensions) are implicitly recognized as
C++ module interface files. If --precompile is /not/ specified, the file is
compiled (via a .pcm) to a .o file containing the code for the module (and then
potentially also assembled and linked, if -S, -c, etc. are not specified). We
do not yet suppress the emission of object code for other users of the module
interface, so for now this will only work if everything in the .cppm file has
vague linkage.
As with the existing support for module-map modules, prebuilt modules can be
provided as compiler inputs either via the -fmodule-file= command-line argument
or via files named ModuleName.pcm in one of the directories specified via
-fprebuilt-module-path=.
This also exposes the -fmodules-ts cc1 flag in the driver. This is still
experimental, and in particular, the concrete syntax is subject to change as
the Modules TS evolves in the C++ committee. Unlike -fmodules, this flag does
not enable support for implicitly loading module maps nor building modules via
the module cache, but those features can be turned on separately and used in
conjunction with the Modules TS support.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@280035 91177308-0d34-0410-b5e6-96231b3b80d8
interface files. At the moment, all declarations (and no macros) are exported,
and 'export' declarations are not supported yet.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@279794 91177308-0d34-0410-b5e6-96231b3b80d8
from p0273r0 approved by EWG). We'll eventually need to handle this from the
lexer as well, in order to disallow preprocessor directives preceding the
module declaration and to support macro import.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@279196 91177308-0d34-0410-b5e6-96231b3b80d8
The recent change implementing __final forgot to initialize a variable.
This was caught by the Memory Sanitizer.
Properly initialize the value to nullptr to ensure proper memory reads.
Patch by Erich Keane!
Differential Revision: https://reviews.llvm.org/D22970
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@277206 91177308-0d34-0410-b5e6-96231b3b80d8
- In functions with try { } catch { }, only the try block would be
skipped, not the catch blocks
- The template functions would still be parsed.
- The initializers within a constructor would still be parsed.
- The inline functions within class would still be stored, only to be
discared later.
- Invalid code with try would assert (as in "int foo() try assert_here")
This attempt to do even less while skipping function bodies.
Differential Revision: http://reviews.llvm.org/D20821
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@272963 91177308-0d34-0410-b5e6-96231b3b80d8
classes.
MSVC actively uses unqualified lookup in dependent bases, lookup at the
instantiation point (non-dependent names may be resolved on things
declared later) etc. and all this stuff is the main cause of
incompatibility between clang and MSVC.
Clang tries to emulate MSVC behavior but it may fail in many cases.
clang could store lexed tokens for member functions definitions within
ClassTemplateDecl for later parsing during template instantiation.
It will allow resolving many possible issues with lookup in dependent
base classes and removing many already existing MSVC-specific
hacks/workarounds from the clang code.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@272774 91177308-0d34-0410-b5e6-96231b3b80d8
Initial parsing/sema/serialization/deserialization support for '#pragma
omp declare simd' directive.
The 'declare simd' construct can be applied to a function to enable the
creation of one or more versions that can process multiple arguments
using SIMD instructions from a single invocation from a SIMD loop.
If the function has any declarations, then the declare simd construct
for any declaration that has one must be equivalent to the one specified
for the definition. Otherwise, the result is unspecified.
This pragma can be applied many times to the same declaration.
Internally this pragma is represented as an attribute. But we need special processing for this pragma because it must be used before function declaration, this directive is applied to.
Differential Revision: http://reviews.llvm.org/D10599
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@264853 91177308-0d34-0410-b5e6-96231b3b80d8
This commit adds a named argument to AvailabilityAttr, while r263652 adds an
optional string argument to __attribute__((deprecated)).
This was commited in r263687 and reverted in 263752 due to misaligned
access.
rdar://20588929
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@263958 91177308-0d34-0410-b5e6-96231b3b80d8
This commit adds a named argument to AvailabilityAttr, while r263652 adds an
optional string argument to __attribute__((deprecated)). This enables the
compiler to provide Fix-Its for deprecated declarations.
rdar://20588929
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@263687 91177308-0d34-0410-b5e6-96231b3b80d8
Add parsing, sema analysis and serialization/deserialization for 'declare reduction' construct.
User-defined reductions are defined as
#pragma omp declare reduction( reduction-identifier : typename-list : combiner ) [initializer ( initializer-expr )]
These custom reductions may be used in 'reduction' clauses of OpenMP constructs. The combiner specifies how partial results can be combined into a single value. The
combiner can use the special variable identifiers omp_in and omp_out that are of the type of the variables being reduced with this reduction-identifier. Each of them will
denote one of the values to be combined before executing the combiner. It is assumed that the special omp_out identifier will refer to the storage that holds the resulting
combined value after executing the combiner.
As the initializer-expr value of a user-defined reduction is not known a priori the initializer-clause can be used to specify one. Then the contents of the initializer-clause
will be used as the initializer for private copies of reduction list items where the omp_priv identifier will refer to the storage to be initialized. The special identifier
omp_orig can also appear in the initializer-clause and it will refer to the storage of the original variable to be reduced.
Differential Revision: http://reviews.llvm.org/D11182
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@262582 91177308-0d34-0410-b5e6-96231b3b80d8
Use "strict" instead of "nopartial". Also make strictly not-introduced
share the same diagnostics as Obsolete and Unavailable.
rdar://23791325
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@261512 91177308-0d34-0410-b5e6-96231b3b80d8
An optional nopartial can be placed after the platform name.
int bar() __attribute__((availability(macosx,nopartial,introduced=10.12))
When deploying back to a platform version prior to when the declaration was
introduced, with 'nopartial', Clang emits an error specifying that the function
is not introduced yet; without 'nopartial', the behavior stays the same: the
declaration is `weakly linked`.
A member is added to the end of AttributeList to save the location of the
'nopartial' keyword. A bool member is added to AvailabilityAttr.
The diagnostics for 'nopartial' not-yet-introduced is handled in the same way as
we handle unavailable cases.
Reviewed by Doug Gregor and Jordan Rose.
rdar://23791325
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@261163 91177308-0d34-0410-b5e6-96231b3b80d8
For
void f() {
union { int i; };
}
clang used to omit the RecordDecl from the anonymous union from the AST.
That's because the code creating it only called PushOnScopeChains(), which adds
it to the current DeclContext, which here is the function's DeclContext. But
RecursiveASTVisitor doesn't descent into all decls in a FunctionDecl.
Instead, for DeclContexts that contain statements, return the RecordDecl so
that it can be included in the DeclStmt containing the VarDecl for the union.
Interesting bits from the AST before this change:
|-FunctionDecl
| `-CompoundStmt
| |-DeclStmt
| | `-VarDecl 0x589cd60 <col:3> col:3 implicit used 'union (anonymous at test.cc:3:3)' callinit
After this change:
-FunctionDecl
| `-CompoundStmt
| |-DeclStmt
| | |-CXXRecordDecl 0x4612e48 <col:3, col:18> col:3 union definition
| | | |-FieldDecl 0x4612f70 <col:11, col:15> col:15 referenced i 'int'
| | `-VarDecl 0x4613010 <col:3> col:3 implicit used 'union (anonymous at test.cc:3:3)' callinit
This is now closer to how anonymous struct and unions are represented as
members of structs. It also enabled deleting some one-off code in the
template instantiation code.
Finally, it fixes a crash with ASTMatchers, see the included test case
(this fixes http://crbug.com/580749).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@259079 91177308-0d34-0410-b5e6-96231b3b80d8
1) When dumping a declaration that declares a name for a type, also dump the named type.
2) Add a #pragma clang __debug dump X, that dumps the lookup results for X in
the current context.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@257529 91177308-0d34-0410-b5e6-96231b3b80d8
Clang skipped annot_pragma_openmp token, while it should be considered as a stop token while skipping tokens.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@250684 91177308-0d34-0410-b5e6-96231b3b80d8
If an import directive was put into wrong context, the error message was obscure,
complaining on misbalanced braces. To get more descriptive messages, annotation
tokens related to modules are processed where they must not be seen.
Differential Revision: http://reviews.llvm.org/D11844
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@248085 91177308-0d34-0410-b5e6-96231b3b80d8
non-visible definition, skip the new definition to avoid ending up with a
function with multiple definitions.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@245664 91177308-0d34-0410-b5e6-96231b3b80d8
Richard Smith