| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
|
| |
with another component in the nested-name-specifiers, updating its
representation (a NestedNameSpecifier) and source-location information
(currently a SourceRange) simultaneously. This is groundwork for
adding source-location information to nested-name-specifiers.
llvm-svn: 126346
|
| |
|
|
|
|
|
|
| |
* Flag indicating 'we're parsing this auto typed variable's initializer' moved from VarDecl to Sema
* Temporary template parameter list for auto deduction is now allocated on the stack.
* Deduced 'auto' types are now uniqued.
llvm-svn: 126139
|
| |
|
|
|
|
| |
This fixes PR 8738, 9060 and 9132.
llvm-svn: 126069
|
| |
|
|
|
|
|
|
|
|
| |
semantics after the C++0x is_convertible type trait. This
implementation is not 100% complete, because it allows access errors
to be hard errors (rather than just evaluating false).
Original patch by Steven Watanabe!
llvm-svn: 124425
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
a pack expansion, e.g., the parameter pack Values in:
template<typename ...Types>
struct Outer {
template<Types ...Values>
struct Inner;
};
This new implementation approach introduces the notion of an
"expanded" non-type template parameter pack, for which we have already
expanded the types of the parameter pack (to, say, "int*, float*",
for Outer<int*, float*>) but have not yet expanded the values. Aside
from creating these expanded non-type template parameter packs, this
patch updates template argument checking and non-type template
parameter pack instantiation to make use of the appropriate types in
the parameter pack.
llvm-svn: 123845
|
| |
|
|
|
|
| |
-Wint-to-pointer-cast.
llvm-svn: 123719
|
| |
|
|
| |
llvm-svn: 123201
|
| |
|
|
|
|
|
| |
on array and function declarators. This is pretty far from complete, and I'll
revisit it later if someone doesn't beat me to it.
llvm-svn: 122535
|
| |
|
|
|
|
| |
BinaryTypeTraitExpr.
llvm-svn: 121298
|
| |
|
|
| |
llvm-svn: 121084
|
| |
|
|
|
|
| |
New AST node introduced: BinaryTypeTraitExpr; to be reused for more intrinsics.
llvm-svn: 121074
|
| |
|
|
|
|
| |
correct.
llvm-svn: 119969
|
| |
|
|
| |
llvm-svn: 119968
|
| |
|
|
| |
llvm-svn: 119966
|
| |
|
|
|
|
| |
PR7702.
llvm-svn: 118181
|
| |
|
|
|
|
| |
protocol-qualified types such as id<Protocol>.
llvm-svn: 117081
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
a typo:
t.c:1:7: error: invalid '==' at end of declaration; did you mean '='?
int x == 0;
^~
=
Implements rdar://8488464.
llvm-svn: 116035
|
| |
|
|
|
|
|
|
| |
with comma-separated lists. We never actually used the comma
locations, nor did we store them in the AST, but we did manage to
waste time during template instantiation to produce fake locations.
llvm-svn: 113495
|
| |
|
|
|
|
| |
libclang visitation.
llvm-svn: 113492
|
| |
|
|
|
|
|
|
| |
typeid expressions:
- make sure we have a proper source location for the closing ')'
- cache the declaration of std::type_info once we've found it
llvm-svn: 113441
|
| |
|
|
| |
llvm-svn: 113356
|
| |
|
|
|
|
|
|
| |
CXXTemporaryObjectExpr, CXXScalarValueInitExpr, and
CXXUnresolvedConstructExpr, getting rid of a bunch of FIXMEs in the
process.
llvm-svn: 113319
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
an '&' expression from the second caller of ActOnIdExpression.
Teach template argument deduction that an overloaded id-expression
doesn't give a valid type for deduction purposes to a non-static
member function unless the expression has the correct syntactic
form.
Teach ActOnIdExpression that it shouldn't try to create implicit
member expressions for '&function', because this isn't a
permitted form of use for member functions.
Teach CheckAddressOfOperand to diagnose these more carefully.
Some of these cases aren't reachable right now because earlier
diagnostics interrupt them.
llvm-svn: 112258
|
| |
|
|
|
|
|
|
|
| |
One who seeks the Tao unlearns something new every day.
Less and less remains until you arrive at non-action.
When you arrive at non-action,
nothing will be left undone.
llvm-svn: 112244
|
| |
|
|
|
|
|
| |
M-x query-replace-regexp
\(Sema::\|Action::\|Parser::\|\)Owning\(Expr\|Stmt\)Result -> \2Result
llvm-svn: 111903
|
| |
|
|
| |
llvm-svn: 111901
|
| |
|
|
| |
llvm-svn: 111863
|
| |
|
|
|
|
| |
through the parser.
llvm-svn: 111800
|
| |
|
|
| |
llvm-svn: 111795
|
| |
|
|
| |
llvm-svn: 111733
|
| |
|
|
|
|
|
|
|
| |
- move DeclSpec &c into the Sema library
- move ParseAST into the Parse library
Reflect this change in a thousand different includes.
Reflect this change in the link orders.
llvm-svn: 111667
|
| |
|
|
|
|
|
| |
the code-completion consumer. The consumer can use this information to
augument, filter, or display the code-completion results.
llvm-svn: 110858
|
| |
|
|
| |
llvm-svn: 110441
|
| |
|
|
|
|
|
|
|
|
|
|
| |
size" error for code like
new (int [size])
to a warning, add a Fix-It to remove the parentheses, and make this
diagnostic work properly when it occurs in a template
instantiation. <rdar://problem/8018245>.
llvm-svn: 108242
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
allows Sema some limited access to the current scope, which we only
use in one way: when Sema is performing some kind of declaration that
is not directly driven by the parser (e.g., due to template
instantiatio or lazy declaration of a member), we can find the Scope
associated with a DeclContext, if that DeclContext is still in the
process of being parsed.
Use this to make the implicit declaration of special member functions
in a C++ class more "scope-less", rather than using the NULL Scope hack.
llvm-svn: 107491
|
| |
|
|
|
|
|
|
|
|
|
| |
For
void f( a::b::c );
we would cache the tokens "a::b::" but then we would try to annotate them using the range "a::".
Before annotating them with the (invalid) C++ scope spec, set it to the range of "a::b::".
llvm-svn: 106536
|
| |
|
|
|
|
|
|
|
|
|
| |
(or operator-function-id) as a template, but the context is actually
non-dependent or the current instantiation, allow us to use knowledge
of what kind of template it is, e.g., type template vs. function
template, for further syntactic disambiguation. This allows us to
parse properly in the presence of stray "template" keywords, which is
necessary in C++0x and it's good recovery in C++98/03.
llvm-svn: 106167
|
| |
|
|
|
|
|
|
|
| |
disambiguation keywords outside of templates in C++98/03. Previously,
the warning would fire when the associated nested-name-specifier was
not dependent, but that was a misreading of the C++98/03 standard:
now, we complain only when we're outside of any template.
llvm-svn: 106161
|
| |
|
|
|
|
| |
Andric!
llvm-svn: 105328
|
| |
|
|
|
|
|
|
|
|
|
| |
1) Suppress diagnostics as soon as we form the code-completion
token, so we don't get any error/warning spew from the early
end-of-file.
2) If we consume a code-completion token when we weren't expecting
one, go into a code-completion recovery path that produces the best
results it can based on the context that the parser is in.
llvm-svn: 104585
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the required "template" keyword, using the same heuristics we do for
dependent template names in member access expressions, e.g.,
test/SemaTemplate/dependent-template-recover.cpp:11:8: error: use 'template'
keyword to treat 'getAs' as a dependent template name
T::getAs<U>();
^
template
Fixes PR5404.
llvm-svn: 104409
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
that is missing the 'template' keyword, e.g.,
t->getAs<T>()
where getAs is a member of an unknown specialization. C++ requires
that we treat "getAs" as a value, but that would fail to parse since T
is the name of a type. We would then fail at the '>', since a type
cannot be followed by a '>'.
This is a very common error for C++ programmers to make, especially
since GCC occasionally allows it when it shouldn't (as does Visual
C++). So, when we are in this case, we use tentative parsing to see if
the tokens starting at "<" can only be parsed as a template argument
list. If so, we produce a diagnostic with a fix-it that states that
the 'template' keyword is needed:
test/SemaTemplate/dependent-template-recover.cpp:5:8: error: 'template' keyword
is required to treat 'getAs' as a dependent template name
t->getAs<T>();
^
template
This is just a start of this patch; I'd like to apply the same
approach to everywhere that a template-id with dependent template name
can be parsed.
llvm-svn: 104406
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
if/switch/while/do/for statements. Previously, we would end up either:
(1) Forgetting to destroy temporaries created in the condition (!),
(2) Destroying the temporaries created in the condition *before*
converting the condition to a boolean value (or, in the case of a
switch statement, to an integral or enumeral value), or
(3) In a for statement, destroying the condition's temporaries at
the end of the increment expression (!).
We now destroy temporaries in conditions at the right times. This
required some tweaking of the Parse/Sema interaction, since the parser
was building full expressions too early in many places.
Fixes PR7067.
llvm-svn: 103187
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
ParseOptionalCXXScopeSpecifier() only annotates the subset of
template-ids which are not subject to lexical ambiguity. Add support
for the more general case in ParseUnqualifiedId() to handle cases
such as A::template B().
Also improve some diagnostic locations.
Fixes PR7030, from Alp Toker!
llvm-svn: 103081
|
| |
|
|
|
|
|
|
|
| |
ConsumeAndStoreUntil would stop at tok::unknown when caching an inline method
definition while SkipUntil would go past it while parsing the method.
Fixes PR 6903.
llvm-svn: 102214
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Objective-C++ have a more complex grammar than in Objective-C
(surprise!), because
(1) The receiver of an instance message can be a qualified name such
as ::I or identity<I>::type.
(2) Expressions in C++ can start with a type.
The receiver grammar isn't actually ambiguous; it just takes a bit of
work to parse past the type before deciding whether we have a type or
expression. We do this in two places within the grammar: once for
message sends and once when we're determining whether a []'d clause in
an initializer list is a message send or a C99 designated initializer.
This implementation of Objective-C++ message sends contains one known
extension beyond GCC's implementation, which is to permit a
typename-specifier as the receiver type for a class message, e.g.,
[typename compute_receiver_type<T>::type method];
Note that the same effect can be achieved in GCC by way of a typedef,
e.g.,
typedef typename computed_receiver_type<T>::type Computed;
[Computed method];
so this is merely a convenience.
Note also that message sends still cannot involve dependent types or
values.
llvm-svn: 102031
|
| |
|
|
|
|
| |
the C-only "optimization".
llvm-svn: 100022
|
| |
|
|
| |
llvm-svn: 100018
|
| |
|
|
|
|
|
| |
term "fix-it" everywhere and even *I* get tired of long names
sometimes. No functionality change.
llvm-svn: 100008
|
| |
|
|
|
|
|
|
|
|
| |
propagating error conditions out of the various annotate-me-a-snowflake
routines. Generally (but not universally) removes redundant diagnostics
as well as, you know, not crashing on bad code. On the other hand,
I have just signed myself up to fix fiddly parser errors for the next
week. Again.
llvm-svn: 97221
|