summaryrefslogtreecommitdiffstats
path: root/clang/test/Parser
Commit message (Collapse)AuthorAgeFilesLines
* Warn that the [] spelling of uuid(...) is deprecated.Nico Weber2017-05-052-2/+2
| | | | | | https://reviews.llvm.org/D32879 llvm-svn: 302255
* [modules ts] Diagnose 'export' declarations outside of a module interface.Richard Smith2017-04-241-2/+1
| | | | llvm-svn: 301271
* Rearrange some Modules TS testcases into test/CXX/modules-ts.Richard Smith2017-04-221-60/+0
| | | | llvm-svn: 301066
* P0629R0: Switch to latest proposal for distinguishing module interface from ↵Richard Smith2017-04-212-23/+25
| | | | | | | | | | | | implementation. 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
* Add #pragma clang attribute support to the availability attributeAlex Lorenz2017-04-201-3/+3
| | | | | | rdar://31707804 llvm-svn: 300826
* Add support for editor placeholders to ClangAlex Lorenz2017-04-192-5/+79
| | | | | | | | | | | | | | | | | | | | | 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
* Add #pragma clang attributeAlex Lorenz2017-04-182-0/+194
| | | | | | | | | | | | | | | | | 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
* Revert r300539 - Add #pragma clang attributeAlex Lorenz2017-04-182-194/+0
| | | | | | | Some tests fail on the Windows buildbots. I will have to investigate more. This commit reverts r300539, r300540 and r300542. llvm-svn: 300543
* Add #pragma clang attributeAlex Lorenz2017-04-182-0/+194
| | | | | | | | | | | | | | 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
* Add support for __builtin_available to __has_builtinAlex Lorenz2017-04-121-0/+5
| | | | | | rdar://31576715 llvm-svn: 300049
* [Parser][ObjC++] Improve diagnostics and recovery when C++ keywords are usedAlex Lorenz2017-04-111-0/+62
| | | | | | | | | | | | | | | | 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
* [OpenCL] Extended diagnostics for atomic initializationEgor Churaev2017-04-051-1/+1
| | | | | | | | | | | | | | | | | | Summary: I saw the same changes in the following review: https://reviews.llvm.org/D17438 I don't know in that way I could determine that atomic variable was initialized by macro ATOMIC_VAR_INIT. Anyway I added check that atomic variables can be initialize only in global scope. I think that we can discuss this change. Reviewers: Anastasia, cfe-commits Reviewed By: Anastasia Subscribers: bader, yaxunl Differential Revision: https://reviews.llvm.org/D30643 llvm-svn: 299537
* Add #pragma clang fpAdam Nemet2017-04-042-0/+65
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* Reapplied r298976 [OpenCL] Added parsing for OpenCL vector types.Egor Churaev2017-03-291-0/+10
| | | | llvm-svn: 298992
* Reverted r298976 [OpenCL] Added parsing for OpenCL vector types.Egor Churaev2017-03-291-10/+0
| | | | llvm-svn: 298978
* [OpenCL] Added parsing for OpenCL vector types.Egor Churaev2017-03-291-0/+10
| | | | | | | | | | | | Reviewers: cfe-commits, Anastasia Reviewed By: Anastasia Subscribers: yaxunl, bader Differential Revision: https://reviews.llvm.org/D31183 llvm-svn: 298976
* Remove the -faltivec alias option and replace it with -maltivec everywhere.Eric Christopher2017-03-214-10/+10
| | | | | | | | | | | The alias was only ever used on darwin and had some issues there, and isn't used in practice much. Also fixes a problem with -mno-altivec not turning off -maltivec. Also add a diagnostic for faltivec/fno-altivec that directs users to use maltivec options and include the altivec.h file explicitly. llvm-svn: 298449
* Introduce an 'external_source_symbol' attribute that describes the originAlex Lorenz2017-03-012-0/+89
| | | | | | | | | | | | | | | | 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
* PR24440: Do not silently discard a fold-expression appearing as the operand ↵Richard Smith2017-02-151-0/+9
| | | | | | of a cast-expression. llvm-svn: 295224
* Improve diagnostic reporting when using __declspec without enabling ↵Aaron Ballman2017-02-142-0/+18
| | | | | | | | __declspec as a keyword. Fixes PR31936. llvm-svn: 295114
* clang/test/Parser/cxx1z-class-template-argument-deduction.cpp: Tweak to ↵NAKAMURA Takumi2017-02-141-1/+1
| | | | | | | | ignore thiscall. Line 38: multiple overloads of 'f' instantiate to the same signature 'void (int) __attribute__((thiscall))' llvm-svn: 295020
* [c++1z] Synthesize implicit deduction guides from constructors on demand. RankRichard Smith2017-02-141-15/+13
| | | | | | | | | | | | | | | | | | | such guides below explicit ones, and ensure that references to the class's template parameters are not treated as forwarding references. We make a few tweaks to the wording in the current standard: 1) The constructor parameter list is copied faithfully to the deduction guide, without losing default arguments or a varargs ellipsis (which the standard wording loses by omission). 2) If the class template declares no constructors, we add a T() -> T<...> guide (which will only ever work if T has default arguments for all non-pack template parameters). 3) If the class template declares nothing that looks like a copy or move constructor, we add a T(T<...>) -> T<...> guide. #2 and #3 follow from the "pretend we had a class type with these constructors" philosophy for deduction guides. llvm-svn: 295007
* [c++1z] Require an initializer for deduced class template specialization types.Richard Smith2017-02-101-2/+2
| | | | | | | | It's actually meaningful and useful to allow such variables to have no initializer, but we are strictly following the standard here until the C++ committee reaches consensus on allowing this. llvm-svn: 294785
* Diagnose attempts to explicitly instantiate a template at class scope. ↵Richard Smith2017-02-092-1/+11
| | | | | | Previously Clang would simply ignore the 'template' keyword in this case. llvm-svn: 294639
* [c++1z] P0091R3: Basic support for deducing class template arguments via ↵Richard Smith2017-02-091-45/+53
| | | | | | deduction-guides. llvm-svn: 294613
* Fix constructor declarator detection for the case when the name is followed byRichard Smith2017-02-081-4/+6
| | | | | | an attribute-specifier-seq. (Also fixes the same problem for deduction-guides.) llvm-svn: 294396
* Towards P0091R3: parsing support for class template argument deduction in ↵Richard Smith2017-01-301-1/+58
| | | | | | | | | typename-specifiers. This reinstates r293455, reverted in r293455, with a fix for cv-qualifier handling on dependent typename-specifiers. llvm-svn: 293544
* Revert r293455, which breaks v8 with a spurious error. Testcase added.Sam McCall2017-01-301-58/+1
| | | | | | | | | | | | Summary: Revert r293455, which breaks v8 with a spurious error. Testcase added. Reviewers: klimek Subscribers: cfe-commits, rsmith Differential Revision: https://reviews.llvm.org/D29271 llvm-svn: 293473
* Towards P0091R3: parsing support for class template argument deduction in ↵Richard Smith2017-01-301-1/+58
| | | | | | typename-specifiers. llvm-svn: 293455
* PR0091R3: Implement parsing support for using templates as types.Richard Smith2017-01-262-2/+138
| | | | | | | | | | | | | | | 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
* PR13403 (+duplicates): implement C++ DR1310 (http://wg21.link/cwg1310).Richard Smith2017-01-191-1/+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
* Make some diagnostic tests C++11 clean.Paul Robinson2016-12-211-2/+6
| | | | | | Differential Revision: http://reviews.llvm.org/D27794 llvm-svn: 290262
* [c++1z] P0195R2: Support pack-expansion of using-declarations.Richard Smith2016-12-201-2/+7
| | | | | | | | | | | | | | This change introduces UsingPackDecl as a marker for the set of UsingDecls produced by pack expansion of a single (unresolved) using declaration. This is not strictly necessary (we just need to be able to map from the original using declaration to its expansions somehow), but it's useful to maintain the invariant that each declaration reference instantiates to refer to one declaration. This is a re-commit of r290080 (reverted in r290092) with a fix for a use-after-lifetime bug. llvm-svn: 290203
* Fix the spelling of 'bitfield' in diagnostics to be consistently 'bit-field'.Chandler Carruth2016-12-201-1/+1
| | | | | | | | The latter agrees with most existing diagnostics and the C and C++ standards. Differential Revision: https://reviews.llvm.org/D26530 llvm-svn: 290159
* Undo accidental comitPaul Robinson2016-12-191-6/+2
| | | | llvm-svn: 290121
* Make a few OpenMP tests "C++11 clean."Paul Robinson2016-12-191-2/+6
| | | | | | Reviewed by abataev (in D27794) llvm-svn: 290120
* Revert "[c++1z] P0195R2: Support pack-expansion of using-declarations."Daniel Jasper2016-12-191-7/+2
| | | | | | | This reverts commit r290080 as it leads to many Clang crashes, e.g.: http://lab.llvm.org:8011/builders/clang-cmake-aarch64-quick/builds/1814 llvm-svn: 290092
* [c++1z] P0195R2: Support pack-expansion of using-declarations.Richard Smith2016-12-191-2/+7
| | | | | | | | | | | This change introduces UsingPackDecl as a marker for the set of UsingDecls produced by pack expansion of a single (unresolved) using declaration. This is not strictly necessary (we just need to be able to map from the original using declaration to its expansions somehow), but it's useful to maintain the invariant that each declaration reference instantiates to refer to one declaration. llvm-svn: 290080
* Recommit r289979 [OpenCL] Allow disabling types and declarations associated ↵Yaxun Liu2016-12-182-10/+13
| | | | | | | | with extensions Fixed undefined behavior due to cast integer to bool in initializer list. llvm-svn: 290056
* Revert r289979 due to regressionsYaxun Liu2016-12-162-13/+10
| | | | llvm-svn: 289991
* [OpenCL] Allow disabling types and declarations associated with extensionsYaxun Liu2016-12-162-10/+13
| | | | | | | | | | | | | | | | | | 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
* [c++1z] P0195R2: Allow multiple using-declarators in a single using-declaration.Richard Smith2016-12-162-1/+31
| | | | llvm-svn: 289905
* __uuidof() and declspec(uuid("...")) should be allowed on enumeration typesReid Kleckner2016-12-131-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Although not specifically mentioned in the documentation, MSVC accepts __uuidof(…) and declspec(uuid("…")) attributes on enumeration types in addition to structs/classes. This is meaningful, as such types *do* have associated UUIDs in ActiveX typelibs, and such attributes are included by default in the wrappers generated by their #import construct, so they are not particularly unusual. clang currently rejects the declspec with a –Wignored-attributes warning, and errors on __uuidof() with “cannot call operator __uuidof on a type with no GUID” (because it rejected the uuid attribute, and therefore finds no value). This is causing problems for us while trying to use clang-tidy on a codebase that makes heavy use of ActiveX. I believe I have found the relevant places to add this functionality, this patch adds this case to clang’s implementation of these MS extensions. patch is against r285994 (or actually the git mirror 80464680ce). Both include an update to test/Parser/MicrosoftExtensions.cpp to exercise the new functionality. This is my first time contributing to LLVM, so if I’ve missed anything else needed to prepare this for review just let me know! __uuidof: https://msdn.microsoft.com/en-us/library/zaah6a61.aspx declspec(uuid("…")): https://msdn.microsoft.com/en-us/library/3b6wkewa.aspx #import: https://msdn.microsoft.com/en-us/library/8etzzkb6.aspx Reviewers: aaron.ballman, majnemer, rnk Differential Revision: https://reviews.llvm.org/D26846 llvm-svn: 289567
* [c++17] P0490R0, NB comment FI 20: allow direct-initialization of ↵Richard Smith2016-12-091-1/+3
| | | | | | decomposition declarations. llvm-svn: 289286
* Remove special error recovery for ::(id)Reid Kleckner2016-12-091-14/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The code pattern used to implement the token rewriting hack doesn't interact well with token caching in the pre-processor. As a result, clang would crash on 'int f(::(id));' while doing a tenative parse of the contents of the outer parentheses. The original code from PR11852 still doesn't crash the compiler. This error recovery also often does the wrong thing with member function pointers. The test case from the original PR doesn't recover the right way either: void S::(*pf)() = S::f; // should be 'void (S::*pf)()' Instead we were recovering as 'void S::*pf()', which is still wrong. If we still think that users mistakenly parenthesize identifiers in nested name specifiers, we should change clang to intentionally parse that form with an error, rather than doing a token rewrite. Fixes PR26623, but I think there will be many more bugs like this around token rewriting in the parser. Reviewers: rsmith, rtrieu Differential Revision: https://reviews.llvm.org/D25882 llvm-svn: 289273
* [ObjC] Avoid a @try/@finally/@autoreleasepool fixit when parsing an expressionAlex Lorenz2016-12-011-0/+28
| | | | | | | | | | | | This patch ensures that the typo fixit for the @try/@finally/@autoreleasepool {} directive is shown only when we're parsing an actual statement where such directives can actually be present. rdar://19669565 Differential Revision: https://reviews.llvm.org/D26916 llvm-svn: 288334
* Accept nullability qualifiers on array parameters.Jordan Rose2016-11-101-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since array parameters decay to pointers, '_Nullable' and friends should be available for use there as well. This is especially important for parameters that are typedefs of arrays. The unsugared syntax for this follows the syntax for 'static'-sized arrays in C: void test(int values[_Nullable]); This syntax was previously accepted but the '_Nullable' (and any other attributes) were silently discarded. However, applying '_Nullable' to a typedef was previously rejected and is now accepted; therefore, it may be necessary to test for the presence of this feature: #if __has_feature(nullability_on_arrays) One important change here is that DecayedTypes don't always immediately contain PointerTypes anymore; they may contain an AttributedType instead. This only affected one place in-tree, so I would guess it's not likely to cause problems elsewhere. This commit does not change -Wnullability-completeness just yet. I want to think about whether it's worth doing something special to avoid breaking existing clients that compile with -Werror. It also doesn't change '#pragma clang assume_nonnull' behavior, which currently treats the following two declarations as equivalent: #pragma clang assume_nonnull begin void test(void *pointers[]); #pragma clang assume_nonnull end void test(void * _Nonnull pointers[]); This is not the desired behavior, but changing it would break backwards-compatibility. Most likely the best answer is going to be adding a new warning. Part of rdar://problem/25846421 llvm-svn: 286519
* Fix off-by-one error in PPCaching.cpp token annotation assertionReid Kleckner2016-10-201-0/+17
| | | | | | | | | | | This assert is intended to defend against backtracking into the middle of a sequence of tokens that is being replaced with an annotation, but it's OK if we backtrack to the exact position of the start of the annotation sequence. Use a <= comparison instead of <. Fixes PR25946 llvm-svn: 284777
* PR26276: Fix detection of non-cast-expressions as operands of fold-expressions.Richard Smith2016-10-201-0/+7
| | | | llvm-svn: 284684
* [CUDA] Rework tests now that we emit deferred diagnostics during sema. ↵Justin Lebar2016-10-191-3/+2
| | | | | | | | | | | | | | | | | | | | | | Test-only change. Summary: Previously we had to split out a lot of our tests into a test that checked only immediate errors and a test that checked only deferred errors. This was because, if you emitted any immediate errors, we wouldn't run codegen, where the deferred errors were emitted. We've fixed this, and now emit deferred errors during sema. This lets us merge a bunch of tests, and lets us convert some other tests to -fsyntax-only. Reviewers: tra Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D25755 llvm-svn: 284553
OpenPOWER on IntegriCloud