| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 304481
|
|
|
|
| |
llvm-svn: 304479
|
|
|
|
| |
llvm-svn: 304478
|
|
|
|
| |
llvm-svn: 304477
|
|
|
|
| |
llvm-svn: 304475
|
|
|
|
| |
llvm-svn: 304473
|
|
|
|
| |
llvm-svn: 304472
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
syntax unless we have a reason to think otherwise.
This improves error recovery in a couple of cases.
llvm-svn: 303398
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
in r302737. [-Wdocumentation]
llvm-svn: 302758
|
|
|
|
| |
llvm-svn: 302737
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
rdar://32074504
llvm-svn: 302545
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`__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
|
|
|
|
|
|
| |
https://reviews.llvm.org/D32879
llvm-svn: 302255
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Clean up some bleeding whitespace that I noticed. NFC
llvm-svn: 300908
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
Some tests fail on the Windows buildbots. I will have to investigate more.
This commit reverts r300539, r300540 and r300542.
llvm-svn: 300543
|
|
|
|
|
|
| |
The warning was caused by r300539.
llvm-svn: 300542
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
[LWG 2911](http://cplusplus.github.io/LWG/lwg-defects.html#2911) adds `std::is_aggregate` to the library, which requires a new builtin trait. This patch implements `__is_aggregate`.
Reviewers: rsmith, majnemer, aaron.ballman
Reviewed By: aaron.ballman
Subscribers: STL_MSFT, cfe-commits
Differential Revision: https://reviews.llvm.org/D31513
llvm-svn: 300116
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
- also replace direct equality checks against the ConstantEvaluated enumerator with isConstantEvaluted(), in anticipation of adding finer granularity to the various ConstantEvaluated contexts and reinstating certain restrictions on where lambda expressions can occur in C++17.
- update the clang tablegen backend that uses these Enumerators, and add the relevant scope where needed.
llvm-svn: 299316
|
|
|
|
| |
llvm-svn: 299083
|
|
|
|
| |
llvm-svn: 298992
|
|
|
|
| |
llvm-svn: 298978
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: cfe-commits, Anastasia
Reviewed By: Anastasia
Subscribers: yaxunl, bader
Differential Revision: https://reviews.llvm.org/D31183
llvm-svn: 298976
|
|
|
|
| |
llvm-svn: 298842
|
|
|
|
|
|
|
|
|
| |
Some clients (eg the cling interpreter) need to recover their parser from
errors.
Patch by Axel Naumann (D31190)!
llvm-svn: 298606
|
|
|
|
|
|
|
|
| |
rdar://31095315
Differential Revision: https://reviews.llvm.org/D31179
llvm-svn: 298589
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
3.4.6 [basic.lookup.udir] paragraph 1:
In a using-directive or namespace-alias-definition, during the lookup for a namespace-name or for a name in a nested-name-specifier, only namespace names are considered.
Reviewers: rsmith, aaron.ballman
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D30848
llvm-svn: 298126
|
|
|
|
|
|
|
|
|
|
|
| |
related property getter/setter role fixes
This enhances the AST to keep track of locations of the names in those ObjC property attributes, and reports them for indexing.
Patch by Nathan Hawes!
https://reviews.llvm.org/D30907
llvm-svn: 297972
|
|
|
|
|
|
| |
https://reviews.llvm.org/D30945
llvm-svn: 297756
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The changes contained in this patch are:
1. Defines a new AST node `CoawaitDependentExpr` for representing co_await expressions while the promise type is still dependent.
2. Correctly detect and transform the 'co_await' operand to `p.await_transform(<expr>)` when possible.
3. Change the initial/final suspend points to build during the initial parse, so they have the correct operator co_await lookup results.
4. Fix transformation of the CoroutineBodyStmt so that it doesn't re-build the final/initial suspends.
@rsmith: This change is a little big, but it's not trivial for me to split it up. Please let me know if you would prefer this submitted as multiple patches.
Reviewers: rsmith, GorNishanov
Reviewed By: rsmith
Subscribers: ABataev, rsmith, mehdi_amini, cfe-commits
Differential Revision: https://reviews.llvm.org/D26057
llvm-svn: 297093
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
permits typedef union __attribute__((transparent_union)) {...}
Differential Revision: https://reviews.llvm.org/D28266
llvm-svn: 296518
|
|
|
|
|
|
| |
of a cast-expression.
llvm-svn: 295224
|
|
|
|
| |
llvm-svn: 295125
|
|
|
|
|
|
|
|
| |
__declspec as a keyword.
Fixes PR31936.
llvm-svn: 295114
|
|
|
|
|
|
|
| |
Since r295004, LLVM has started modelling this new register, but we
don't have GCC constraint inline asm spellings for it yet.
llvm-svn: 295107
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit adds context sensitive code completion support for the C++11
keywords that currently don't have completion results.
The following keywords are supported by this patch:
alignas
constexpr
static_assert
noexcept (as a function/method qualifier)
thread_local
The following special identifiers are also supported:
final (as a method qualifier or class qualifier)
override
rdar://29219185
Differential Revision: https://reviews.llvm.org/D28286
llvm-svn: 295001
|
|
|
|
|
|
| |
Previously Clang would simply ignore the 'template' keyword in this case.
llvm-svn: 294639
|