| Age | Commit message (Collapse) | Author |
|---|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@113356 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@112905 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@112577 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
some issues being sorted out.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@112493 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
The extra data stored on user-defined literal Tokens is stored in extra
allocated memory, which is managed by the PreprocessorLexer because there isn't
a better place to put it that makes sure it gets deallocated, but only after
it's used up. My testing has shown no significant slowdown as a result, but
independent testing would be appreciated.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@112458 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@112258 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@112244 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@111999 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
M-x query-replace-regexp
\(Sema::\|Action::\|Parser::\|\)Owning\(Expr\|Stmt\)Result -> \2Result
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@111903 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@111901 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@111863 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@111795 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
- 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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@111667 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
the code-completion consumer. The consumer can use this information to
augument, filter, or display the code-completion results.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@110858 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
but we were parsing the C grammar. Handle the C++ grammar
appropriately. Fixes PR7794.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@110445 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
parenthesized, unlike in C++, e.g.,
C has: typeof ( expression)
C++ has: typeof unary-expression
So, once we've parsed a parenthesized expression after typeof, we
should only go on to parse the postfix expression suffix if we're in
C++. Fixes <rdar://problem/8237491>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@109606 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@108676 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@107491 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
of isSimpleObjCMessageExpression checks the language,
so change a dynamic check into an assert.
isSimpleObjCMessageExpression is expensive, so only do it
in the common case when it is likely to matter: when the [
of the postfix expr starts on a new line. This should avoid
doing lookahead for every array expression.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@105229 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
a simple, quick check to determine whether the expression starting
with '[' can only be an Objective-C message send. If so, don't parse
it as an array subscript expression. This improves recovery for, e.g.,
[a method1]
[a method2]
so that we now produce
t.m:10:13: error: expected ';' after expression
[a method]
^
instead of some mess about expecting ']'.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@105221 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
called function itself is invalid (e.g., because of a semantic error
referring to that declaration). Fixes <rdar://problem/8044142>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@105175 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
type that we expect to see at a given point in the grammar, e.g., when
initializing a variable, returning a result, or calling a function. We
don't prune the candidate set at all, just adjust priorities to favor
things that should type-check, using an ultra-simplified type system.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@105128 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
expression, "forget" about the object type; only the
nested-name-specifier matters for name lookup purposes. Fixes PR7239.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@104834 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@104585 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
there are already two spaces before the token where the : was expected,
put the : in between the spaces. This means we get it right in both
of these cases:
t.c:2:17: error: expected ':'
return a ? b c;
^
:
t.c:3:16: error: expected ':'
return a ? b c;
^
:
In the later case, the diagnostic says to insert ": ", in the former
case it says to insert ":" between the spaces. This fixes rdar://8007231
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@104569 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
try to annotate as a type first to determine whether we have a
functional-style cast. Patch by Eli Friedman, fixes PR6830.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@102161 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@102031 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
sends. Major changes include:
- Expanded the interface from two actions (ActOnInstanceMessage,
ActOnClassMessage), where ActOnClassMessage also handled sends to
"super" by checking whether the identifier was "super", to three
actions (ActOnInstanceMessage, ActOnClassMessage,
ActOnSuperMessage). Code completion has the same changes.
- The parser now resolves the type to which we are sending a class
message, so ActOnClassMessage now accepts a TypeTy* (rather than
an IdentifierInfo *). This opens the door to more interesting
types (for Objective-C++ support).
- Split ActOnInstanceMessage and ActOnClassMessage into parser
action functions (with their original names) and semantic
functions (BuildInstanceMessage and BuildClassMessage,
respectively). At present, this split is onyl used by
ActOnSuperMessage, which decides which kind of super message it
has and forwards to the appropriate Build*Message. In the future,
Build*Message will be used by template instantiation.
- Use getObjCMessageKind() within the disambiguation of Objective-C
message sends vs. array designators.
Two notes about substandard bits in this patch:
- There is some redundancy in the code in ParseObjCMessageExpr and
ParseInitializerWithPotentialDesignator; this will be addressed
shortly by centralizing the mapping from identifiers to type names
for the message receiver.
- There is some #if 0'd code that won't likely ever be used---it
handles the use of 'super' in methods whose class does not have a
superclass---but could be used to model GCC's behavior more
closely. This code will die in my next check-in, but I want it in
Subversion.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@102021 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@101943 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@101073 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
rdar://7853261
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@101048 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
by David Chisnall
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@101024 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@101022 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This also fixes cases where super is used in a block in a
method which isn't valid.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@101021 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
LookupInObjCMethod. Doing so allows all sorts of invalid code
to slip through to codegen. This patch does not change the
AST representation of super, though that would now be a natural
thing to do since it can only be in the receiver position and
in the base of a ObjCPropertyRefExpr.
There are still several ugly areas handling super in the parser,
but this is definitely a step in the right direction.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@100959 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
e.g., the right-hand side of binary expressions.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@100526 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@97221 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
class types, dependent types, and namespaces. I had previously
weakened this invariant while working on parsing pseudo-destructor
expressions, but recent work in that area has made these changes
unnecessary.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@97112 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
destructor calls, e.g.,
p->T::~T
We now detect when the member access that we've parsed, e.g.,
p-> or x.
may be a pseudo-destructor expression, either because the type of p or
x is a scalar or because it is dependent (and, therefore, may become a
scalar at template instantiation time).
We then parse the pseudo-destructor grammar specifically:
::[opt] nested-name-specifier[opt] type-name :: ∼ type-name
and hand those results to a new action, ActOnPseudoDestructorExpr,
which will cope with both dependent member accesses of destructors and
with pseudo-destructor expressions.
This commit affects the parsing of pseudo-destructors, only; the
semantic actions still go through the semantic actions for member
access expressions. That will change soon.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@97045 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
nested-name-specifier, e.g.,
typedef int Int;
int *p;
p->Int::~Int();
This weakens the invariant that the only types in nested-name-specifiers are tag types (restricted to class types in C++98/03). However, we weaken this invariant as little as possible, accepting arbitrary types in nested-name-specifiers only when we're in a member access expression that looks like a pseudo-destructor expression.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@96743 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
declaration, we can end up with template-id annotation tokens for
types that have not been converted into type annotation tokens. When
this is the case, translate the template-id into a type and parse as
an expression.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@95404 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@95335 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
C++ grammatical constructs that show up in top-level (namespace-level)
declarations, member declarations, template declarations, statements,
expressions, conditions, etc. For example, we now provide a pattern
for
static_cast<type>(expr)
when we can have an expression, or
using namespace identifier;
when we can have a using directive.
Also, improves the results of code completion at the beginning of a
top-level declaration. Previously, we would see value names (function
names, global variables, etc.); now we see types, namespace names,
etc., but no values.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@93134 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
as a type or scope token if the next token requires it.
This eliminates a lot of redundant lookups in C++, but there's room for
improvement; a better solution would do a single lookup whose kind and
results would be passed through the parser.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@92930 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
a better diagnostic in the second example.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@91040 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@91039 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@91008 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@90361 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
to build casted expression-list AST to Sema.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@89827 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
type-casts in the parser.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@89691 91177308-0d34-0410-b5e6-96231b3b80d8
|
