| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 112458
|
|
|
|
|
|
|
|
|
| |
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: 111863
|
|
|
|
|
|
|
|
| |
argument in a for-each statement (e.g., "for (id x in <blah>)"), which
restricts the expression completions provided to Objective-C types (or
class types in C++).
llvm-svn: 111843
|
|
|
|
| |
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
|
|
|
|
|
|
| |
patch by Per Linden!
llvm-svn: 111235
|
|
|
|
|
|
|
| |
the code-completion consumer. The consumer can use this information to
augument, filter, or display the code-completion results.
llvm-svn: 110858
|
|
|
|
| |
llvm-svn: 110433
|
|
|
|
| |
llvm-svn: 109087
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
In a line like:
(;
the semicolon leaves Parser:ParenCount unbalanced (it's 1 even though we stopped looking for a right paren).
This may affect later parsing and result in bad recovery for parsing errors.
llvm-svn: 106213
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 105128
|
|
|
|
|
|
|
| |
completions. Plus, tweak a few completion patterns to better reflect
the language grammar.
llvm-svn: 104905
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
<rdar://problem/7971948>.
llvm-svn: 104291
|
|
|
|
| |
llvm-svn: 103198
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
fields to two 16-bit values instead of using bitfields.
llvm-svn: 101020
|
|
|
|
|
|
| |
returned by SetTypeSpecType.
llvm-svn: 100443
|
|
|
|
| |
llvm-svn: 99972
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
we would just leak them all over the place, with no clear ownership of
these objects at all. AttributeList objects would get leaked on both
error and non-error paths.
Note: I introduced the usage of llvm::OwningPtr<AttributeList> to
manage these objects, which is particularly useful for methods with
multiple return sites. In at least one method I used them even when
they weren't strictly necessary because it clarified the ownership
semantics and made the code easier to read. Should the excessive
'take()' and 'reset()' calls become a performance issue we can always
re-evaluate.
Note+1: I believe I have not introduced any double-frees, but it would
be nice for someone to review this.
This fixes <rdar://problem/7635046>.
llvm-svn: 95847
|
|
|
|
| |
llvm-svn: 94925
|
|
|
|
|
|
| |
unbalanced.
llvm-svn: 94347
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 93134
|
|
|
|
| |
llvm-svn: 92526
|
|
|
|
| |
llvm-svn: 91802
|
|
|
|
|
|
| |
pull ':' eating out of ParseAsmOperandsOpt.
llvm-svn: 91801
|
|
|
|
|
|
| |
Action::FullExpr to Action::MakeFullExpr to avoid name clashes.
llvm-svn: 91494
|
|
|
|
| |
llvm-svn: 91079
|
|
|
|
| |
llvm-svn: 91016
|
|
|
|
| |
llvm-svn: 91008
|
|
|
|
|
|
|
| |
still parse the body of the switch to try to avoid spurious
diagnostics. Fixes PR5606.
llvm-svn: 89847
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
All statements that involve conditions can now hold on to a separate
condition declaration (a VarDecl), and will use a DeclRefExpr
referring to that VarDecl for the condition expression. ForStmts now
have such a VarDecl (I'd missed those in previous commits).
Also, since this change reworks the Action interface for
if/while/switch/for, use FullExprArg for the full expressions in those
expressions, to ensure that we're emitting
Note that we are (still) not generating the right cleanups for
condition variables in for statements. That will be a follow-on
commit.
llvm-svn: 89817
|
|
|
|
| |
llvm-svn: 89801
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The following attributes are currently supported in C++0x attribute
lists (and in GNU ones as well):
- align() - semantics believed to be conformant to n3000, except for
redeclarations and what entities it may apply to
- final - semantics believed to be conformant to CWG issue 817's proposed
wording, except for redeclarations
- noreturn - semantics believed to be conformant to n3000, except for
redeclarations
- carries_dependency - currently ignored (this is an optimization hint)
llvm-svn: 89543
|
|
|
|
|
|
| |
(radar 7409165).
llvm-svn: 89400
|
|
|
|
|
|
|
| |
declarators are parsed primarily within a single function (at least for
these cases). Remove some excess diagnostics arising during parse failures.
llvm-svn: 85924
|
|
|
|
|
|
| |
are updated.
llvm-svn: 84447
|
|
|
|
|
|
|
|
|
| |
- strcmp -> ==
- OS.write(II->getName() ...) -> OS << II->getNameStr()
- Avoid std::string concatenation
- Use getNameStr().str() when an std::string is really needed.
llvm-svn: 84437
|
|
|
|
|
|
| |
expression, or statement
llvm-svn: 82481
|
|
|
|
|
|
| |
of enumeration type, providing the various unused enumerators as options.
llvm-svn: 82467
|
|
|
|
| |
llvm-svn: 81346
|
|
|
|
|
|
| |
the return expr inside a CXXExprWithTemporaries if needed.
llvm-svn: 79342
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ExpectAndConsume instead of custom diag logic. This gets us an
insertion hint and positions the ; at the end of the line
instead of on the next token. Before:
t.c:5:1: error: expected ';' after return statement
}
^
after:
t.c:4:11: error: expected ';' after return statement
return 4
^
;
llvm-svn: 73315
|
|
|
|
|
|
| |
diagnostics in some cases.
llvm-svn: 73314
|
|
|
|
|
|
| |
This fixes a source range problem reported by Olaf Krzikalla.
llvm-svn: 73266
|
|
|
|
| |
llvm-svn: 72834
|