summaryrefslogtreecommitdiffstats
path: root/clang/lib/Parse
Commit message (Collapse)AuthorAgeFilesLines
* Allow pretty platform names in availability attributesAlex Lorenz2017-08-151-7/+12
| | | | | | rdar://32076651 llvm-svn: 310921
* Rename cxx1z -> cxx17 across all diagnostic IDs.Richard Smith2017-08-132-3/+3
| | | | llvm-svn: 310805
* PR34163: Don't cache an incorrect key function for a class if queried betweenRichard Smith2017-08-121-18/+5
| | | | | | | | | | | 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
* Place implictly declared functions at block scopeMomchil Velikov2017-08-1010-31/+48
| | | | | | | | | | | | 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
* Update for llvm change.Rafael Espindola2017-08-021-2/+1
| | | | llvm-svn: 309885
* Recommit r308327 3rd time: Add a warning for missingAlex Lorenz2017-07-281-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | '#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
* Revert r309106 "Recommit r308327 2nd time: Add a warning for missing"Hans Wennborg2017-07-261-7/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Recommit r308327 2nd time: Add a warning for missingAlex Lorenz2017-07-261-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | '#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
* [OPENMP] Initial support for 'in_reduction' clause.Alexey Bataev2017-07-211-10/+17
| | | | | | | Parsing/sema analysis for 'in_reduction' clause for task-based directives. llvm-svn: 308768
* Revert r308441 "Recommit r308327: Add a warning for missing '#pragma pack ↵Hans Wennborg2017-07-191-7/+2
| | | | | | | | | | | | | | | | | | | | | (pop)' and suspicious uses of '#pragma pack' in included files" 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
* Recommit r308327: Add a warning for missing '#pragma pack (pop)'Alex Lorenz2017-07-191-2/+7
| | | | | | | | | | | | | | | | | | 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
* [OPENMP] Initial support for 'task_reduction' clause.Alexey Bataev2017-07-181-10/+13
| | | | | | Parsing/sema analysis of the 'task_reduction' clause. llvm-svn: 308352
* Revert r308327Alex Lorenz2017-07-181-7/+2
| | | | | | I forgot to test clang-tools-extra which is now failing. llvm-svn: 308328
* Add a warning for missing '#pragma pack (pop)' and suspicious usesAlex Lorenz2017-07-181-2/+7
| | | | | | | | | | | | | | | | | | 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
* [index] Objective-C method declarations and message sends withAlex Lorenz2017-07-131-0/+4
| | | | | | | | an empty first selector piece should store the location of the first ':' rdar://33188656 llvm-svn: 307901
* fix typos in comments; NFCHiroshi Inoue2017-07-131-1/+1
| | | | llvm-svn: 307886
* Fix invalid warnings for header guards in preamblesErik Verbruggen2017-07-051-0/+2
| | | | | | | | Fixes https://bugs.llvm.org/show_bug.cgi?id=33574 Differential Revision: https://reviews.llvm.org/D34882 llvm-svn: 307134
* [modules ts] Declarations from a module interface unit are only visible outsideRichard Smith2017-07-051-0/+2
| | | | | | the module if declared in an export block. llvm-svn: 307115
* Add a fixit for -Wobjc-protocol-property-synthesisAlex Lorenz2017-07-031-1/+1
| | | | | | | | rdar://32132756 Differential Revision: https://reviews.llvm.org/D34886 llvm-svn: 307014
* fix trivial typos in comments; NFCHiroshi Inoue2017-07-022-3/+3
| | | | llvm-svn: 306969
* [Modules] Implement ODR-like semantics for tag types in C/ObjCBruno Cardoso Lopes2017-07-012-9/+24
| | | | | | | | | | | | | | | | | | | | | | 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
* [Parse] Use normalized attr name for late-parsing checks.George Burgess IV2017-06-301-8/+8
| | | | llvm-svn: 306899
* fix trivial typos, NFCHiroshi Inoue2017-06-301-1/+1
| | | | llvm-svn: 306789
* [Sema] Fix a crash-on-invalid when a template parameter list has a classAkira Hatanaka2017-06-263-3/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [Parser][ObjC] Use an artificial EOF token while parsing lexed ObjC methodsAlex Lorenz2017-06-191-1/+11
| | | | | | | | | | | 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
* PR33318: Add missing full-expression checking to static_assert expression.Richard Smith2017-06-061-1/+3
| | | | | | | This fixes missing lambda-captures for variables referenced only inside a static_assert (!), among other things. llvm-svn: 304760
* Add support for #pragma clang sectionJaved Absar2017-06-051-0/+60
| | | | | | | | | | | | | | | 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
* Added LLVM_FALLTHROUGH to address warning: this statement may fall through. NFC.Galina Kistanova2017-06-031-0/+2
| | | | llvm-svn: 304646
* Added LLVM_FALLTHROUGH to address warning: this statement may fall through. NFC.Galina Kistanova2017-06-011-0/+2
| | | | llvm-svn: 304481
* Added LLVM_FALLTHROUGH to address warning: this statement may fall through. NFC.Galina Kistanova2017-06-011-0/+1
| | | | llvm-svn: 304479
* Added LLVM_FALLTHROUGH to address warning: this statement may fall through. NFC.Galina Kistanova2017-06-011-0/+4
| | | | llvm-svn: 304478
* Added LLVM_FALLTHROUGH to address warning: this statement may fall through. NFC.Galina Kistanova2017-06-011-1/+2
| | | | llvm-svn: 304477
* Added LLVM_FALLTHROUGH to address warning: this statement may fall through. NFC.Galina Kistanova2017-06-011-2/+3
| | | | llvm-svn: 304475
* Added LLVM_FALLTHROUGH to address warning: this statement may fall through. NFC.Galina Kistanova2017-06-011-0/+1
| | | | llvm-svn: 304473
* Added LLVM_FALLTHROUGH to address warning: this statement may fall through. NFC.Galina Kistanova2017-06-011-0/+4
| | | | llvm-svn: 304472
* [NFC, Refactor] Modernize TemplateIdAnnotation using TrailingObjectsFaisal Vali2017-05-232-41/+24
| | | | | | | | | | 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
* Fix PR25627: constant expressions being odr-used in template arguments.Faisal Vali2017-05-202-9/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix valid-for-expr ellipses eaten as invalid declHubert Tong2017-05-201-12/+13
| | | | | | | | | | | | | | | | | | | | | | 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
* When a type-id is unexpectedly given a name, assume that the name is unrelatedRichard Smith2017-05-191-5/+22
| | | | | | | | syntax unless we have a reason to think otherwise. This improves error recovery in a couple of cases. llvm-svn: 303398
* Fix the location of "missing ';'" suggestions after annotation tokens.Richard Smith2017-05-1811-122/+107
| | | | | | | | | | 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
* Prune unused \param(s) of clang::Parser::ParseTemplateIdAfterTemplateName() ↵NAKAMURA Takumi2017-05-111-7/+0
| | | | | | in r302737. [-Wdocumentation] llvm-svn: 302758
* Changes missed from r302732.Richard Smith2017-05-103-16/+8
| | | | llvm-svn: 302737
* Improve diagnosis of unknown template name.Richard Smith2017-05-101-2/+9
| | | | | | | | | 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
* When we see a '<' operator, check whether it's a probable typo for a ↵Richard Smith2017-05-101-0/+34
| | | | | | | | | | | | | | | | | | | template-id. 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
* [CodeCompletion] Complete platform names in @available expressionsAlex Lorenz2017-05-091-0/+5
| | | | | | rdar://32074504 llvm-svn: 302545
* Add support for pretty platform names to `@available`/Alex Lorenz2017-05-091-2/+4
| | | | | | | | | | | | | `__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
* Warn that the [] spelling of uuid(...) is deprecated.Nico Weber2017-05-051-2/+0
| | | | | | https://reviews.llvm.org/D32879 llvm-svn: 302255
* [OpenMP] Extended parse for 'always' map modifierCarlo Bertolli2017-05-031-0/+24
| | | | | | | | 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
* P0629R0: Switch to latest proposal for distinguishing module interface from ↵Richard Smith2017-04-211-39/+28
| | | | | | | | | | | | 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
* Parse: cleanup some bleeding whitespaceSaleem Abdulrasool2017-04-201-2/+3
| | | | | | Clean up some bleeding whitespace that I noticed. NFC llvm-svn: 300908
OpenPOWER on IntegriCloud