aboutsummaryrefslogtreecommitdiff
path: root/clang/lib/Parse/Parser.cpp
AgeCommit message (Collapse)AuthorFilesLines
2017-04-18Add #pragma clang attributeAlex Lorenz1-0/+4
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
2017-04-18Revert r300539 - Add #pragma clang attributeAlex Lorenz1-4/+0
Some tests fail on the Windows buildbots. I will have to investigate more. This commit reverts r300539, r300540 and r300542. llvm-svn: 300543
2017-04-18Add #pragma clang attributeAlex Lorenz1-0/+4
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
2017-04-11[Parser][ObjC++] Improve diagnostics and recovery when C++ keywords are usedAlex Lorenz1-0/+15
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
2017-04-04Add #pragma clang fpAdam Nemet1-0/+3
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
2017-03-27Publish one more parser RAII for external use.Vassil Vassilev1-20/+0
llvm-svn: 298842
2017-03-23Publish RAIIObjectsForParser.h for external usage.Vassil Vassilev1-1/+1
Some clients (eg the cling interpreter) need to recover their parser from errors. Patch by Axel Naumann (D31190)! llvm-svn: 298606
2017-03-01Introduce an 'external_source_symbol' attribute that describes the originAlex Lorenz1-0/+2
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 llvm-svn: 296649
2017-02-07P0091R3: Implement basic parsing support for C++17 deduction-guides.Richard Smith1-2/+4
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). llvm-svn: 294266
2017-01-26PR0091R3: Implement parsing support for using templates as types.Richard Smith1-1/+2
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. llvm-svn: 293207
2017-01-19PR13403 (+duplicates): implement C++ DR1310 (http://wg21.link/cwg1310).Richard Smith1-0/+1
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. llvm-svn: 292518
2017-01-12Remove redundant passing around of a "ContainsAutoType" flag.Richard Smith1-1/+1
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. llvm-svn: 291737
2017-01-10Remove dead code.Richard Smith1-5/+0
llvm-svn: 291610
2017-01-10Remove a couple of parameters that are always false.Richard Smith1-21/+14
llvm-svn: 291608
2016-12-18Recommit r289979 [OpenCL] Allow disabling types and declarations associated ↵Yaxun Liu1-0/+2
with extensions Fixed undefined behavior due to cast integer to bool in initializer list. llvm-svn: 290056
2016-12-16Revert r289979 due to regressionsYaxun Liu1-2/+0
llvm-svn: 289991
2016-12-16[OpenCL] Allow disabling types and declarations associated with extensionsYaxun Liu1-0/+2
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 llvm-svn: 289979
2016-12-06[modules] Use the "redundant #include" diagnostic rather than the "moduleRichard Smith1-6/+21
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. llvm-svn: 288737
2016-09-13[SemaObjC] Be more strict while parsing type arguments and protocolsBruno Cardoso Lopes1-0/+4
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 llvm-svn: 281383
2016-09-08C++ Modules TS: Add parsing and some semantic analysis support forRichard Smith1-1/+7
export-declarations. These don't yet have an effect on name visibility; we still export everything by default. llvm-svn: 280999
2016-09-03Move calls of MaybeParseMicrosoftAttributes() before ParseExternalDeclaration()Nico Weber1-2/+1
into ParseDeclOrFunctionDefInternal() (which is called by MaybeParseMicrosoftAttributes()), so that the attributes can be stored in the DeclSpec. No behavior change yet, part of https://reviews.llvm.org/D23895 llvm-svn: 280574
2016-09-03Remove function name from comment.Nico Weber1-6/+5
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. llvm-svn: 280572
2016-08-30Unrevert r280035 now that the clang-cl bug it exposed has been fixed byRichard Smith1-1/+7
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. llvm-svn: 280134
2016-08-30Revert r280035 (and followups r280057, r280085), it caused PR30195Nico Weber1-7/+1
llvm-svn: 280091
2016-08-30C++ Modules TS: driver support for building modules.Richard Smith1-1/+7
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. llvm-svn: 280035
2016-08-26C++ Modules TS: add frontend support for building pcm files from moduleRichard Smith1-3/+18
interface files. At the moment, all declarations (and no macros) are exported, and 'export' declarations are not supported yet. llvm-svn: 279794
2016-08-19C++ Modules TS: support parsing the 'module' declaration (including extensionsRichard Smith1-30/+98
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. llvm-svn: 279196
2016-08-18C++ Modules TS: Add parsing support for module import declaration.Richard Smith1-11/+32
llvm-svn: 279163
2016-07-29Ensure Ident_GNU_final is properly initialized in the Parser Initialize functionDavid Majnemer1-0/+1
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 llvm-svn: 277206
2016-07-18[NFC] Header cleanupMehdi Amini1-1/+0
Summary: Removed unused headers, replaced some headers with forward class declarations Patch by: Eugene <claprix@yandex.ru> Differential Revision: https://reviews.llvm.org/D20100 llvm-svn: 275882
2016-06-16Fix a few issues while skipping function bodiesOlivier Goffart1-0/+13
- 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 llvm-svn: 272963
2016-06-15Revert accidential "[MSVC] Late parsing of in-class defined member functions ↵Alexey Bataev1-31/+6
in template" This reverts commit 0253605771b8bd9d414aba74fe2742c730d6fd1a. llvm-svn: 272776
2016-06-15[MSVC] Late parsing of in-class defined member functions in templateAlexey Bataev1-6/+31
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. llvm-svn: 272774
2016-03-30[OPENMP 4.0] Initial support for '#pragma omp declare simd' directive.Alexey Bataev1-2/+4
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 llvm-svn: 264853
2016-03-21Add replacement = "xxx" to AvailabilityAttr.Manman Ren1-0/+1
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 llvm-svn: 263958
2016-03-17Revert r263687 for ubsan bot failure.Manman Ren1-1/+0
llvm-svn: 263752
2016-03-17Add an optional named argument (replacement = "xxx") to AvailabilityAttr.Manman Ren1-0/+1
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 llvm-svn: 263687
2016-03-03[OPENMP 4.0] Initial support for 'omp declare reduction' construct.Alexey Bataev1-1/+1
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 llvm-svn: 262582
2016-02-22Addressing review comments for r261163.Manman Ren1-1/+1
Use "strict" instead of "nopartial". Also make strictly not-introduced share the same diagnostics as Obsolete and Unavailable. rdar://23791325 llvm-svn: 261512
2016-02-17Add 'nopartial' qualifier for availability attributes.Manman Ren1-0/+1
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 llvm-svn: 261163
2016-01-28Include RecordDecls from anonymous unions in the AST.Nico Weber1-1/+7
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). llvm-svn: 259079
2016-01-15OpaquePtr: Use nullptr construction for ParsedType OpaquePtr typedefDavid Blaikie1-25/+21
llvm-svn: 257958
2016-01-15OpaquePtr: Use nullptr construction for DeclGroupPtrTy OpaquePtr typedefDavid Blaikie1-29/+29
llvm-svn: 257956
2016-01-12Improve AST dumping:Richard Smith1-0/+3
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. llvm-svn: 257529
2015-11-14Merge some similar diagnostics using %select.Craig Topper1-4/+6
llvm-svn: 253136
2015-10-19[OPENMP] Fix for http://llvm.org/PR25221: Infinite loop while parsing OpenMP ↵Alexey Bataev1-0/+1
directive Clang skipped annot_pragma_openmp token, while it should be considered as a stop token while skipping tokens. llvm-svn: 250684
2015-09-19[Modules] More descriptive diagnostics for misplaced import directiveSerge Pavlov1-1/+35
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 llvm-svn: 248085
2015-08-21[modules] When we see a definition of a function for which we already have aRichard Smith1-4/+33
non-visible definition, skip the new definition to avoid ending up with a function with multiple definitions. llvm-svn: 245664
2015-07-30Fix sanitizer fallout from r243642Ulrich Weigand1-0/+3
The memory-sanitizer build bot reported: ==5574== WARNING: MemorySanitizer: use-of-uninitialized-value #0 0x7f03089e15f6 in clang::Parser::TryAltiVecTokenOutOfLine(clang::DeclSpec&, clang::SourceLocation, char const*&, unsigned int&, bool&) /mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/Parse/ParseDecl.cpp:6290:11 This is because the "Ident_pixel" variable was uninitialized in the getLangOpts().ZVector case, but we'd still call into clang::Parser::TryAltiVecTokenOutOfLine, which uses the variable. The simplest fix for this without sprinkling !getLangOpts().ZVector checks all over the code seems to be to just initialize the variable to nullptr; this will then do the right thing on ZVector. Checked in to unbreak the build bots. llvm-svn: 243644
2015-07-30Add support for System z vector language extensionsUlrich Weigand1-2/+3
The z13 vector facility has an associated language extension, closely modeled on AltiVec/VSX. The main differences are: - vector long, vector float and vector pixel are not supported - vector long long and vector double are supported (like VSX) - comparison operators return a vector rather than a scalar integer - shift operators behave like the OpenCL shift operators - vector bool is only supported as argument to certain operators; some operators allow mixing a bool with a non-bool vector This patch adds clang support for the extension. It is closely modelled on the AltiVec support. Similarly to the -faltivec option, there's a new -fzvector option to enable the extensions (as well as an -mzvector alias for compatibility with GCC). There's also a separate LangOpt. The extension as implemented here is intended to be compatible with the -mzvector extension recently implemented by GCC. Based on a patch by Richard Sandiford. Differential Revision: http://reviews.llvm.org/D11001 llvm-svn: 243642
generated by cgit v1.1 at 2025-10-02 04:03:42 +0000