| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
llvm-svn: 82543
|
|
|
|
|
|
| |
change.
llvm-svn: 82540
|
|
|
|
|
|
| |
breaking some projects, but I don't have a test case yet.
llvm-svn: 82539
|
|
|
|
| |
llvm-svn: 82526
|
|
|
|
| |
llvm-svn: 82525
|
|
|
|
|
|
| |
(via integer) to function call not invalidated
llvm-svn: 82523
|
|
|
|
|
|
| |
- Switching all of them out-of-my-current-scope-of-interest, sorry.
llvm-svn: 82515
|
|
|
|
| |
llvm-svn: 82514
|
|
|
|
| |
llvm-svn: 82513
|
|
|
|
| |
llvm-svn: 82512
|
|
|
|
| |
llvm-svn: 82511
|
|
|
|
| |
llvm-svn: 82508
|
|
|
|
| |
llvm-svn: 82502
|
|
|
|
|
|
|
|
|
|
|
| |
Several of the existing methods were identical to their respective
specializations, and so have been removed entirely. Several more 'leaf'
optimizations were introduced.
The getAsFoo() methods which imposed extra conditions, like
getAsObjCInterfacePointerType(), have been left in place.
llvm-svn: 82501
|
|
|
|
|
|
| |
gcc-style write-barrier api only.
llvm-svn: 82493
|
|
|
|
|
|
|
|
| |
integer pointer. For now just invalidate the fields of the struct.
This addresses: <rdar://problem/7185607> [RegionStore] support invalidation of bit fields using integer assignment
llvm-svn: 82492
|
|
|
|
|
|
| |
expression, or statement
llvm-svn: 82481
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
a nested-name-specifier that describes how to refer to that name. For
example, given:
struct Base { int member; };
struct Derived : Base { int member; };
the code-completion result for a member access into "Derived" will
provide both "member" to refer to Derived::member (no qualification needed) and
"Base::member" to refer to Base::member (qualification included).
llvm-svn: 82476
|
|
|
|
|
|
|
|
|
| |
enumerators when either the user intentionally wrote a qualified name
(in which case we just use that nested-name-specifier to match
the user's code) or when this is the first "case" statement and we
need a qualified name to refer to an enumerator in a different scope.
llvm-svn: 82474
|
|
|
|
| |
llvm-svn: 82472
|
|
|
|
|
|
| |
of enumeration type, providing the various unused enumerators as options.
llvm-svn: 82467
|
|
|
|
|
|
|
| |
real work is performed within Sema. Addresses Chris's comments, but
still retains the heavyweight list-of-multimaps data structure.
llvm-svn: 82459
|
|
|
|
| |
llvm-svn: 82435
|
|
|
|
| |
llvm-svn: 82433
|
|
|
|
|
|
|
|
| |
predefines.
- It isn't really clear what to do with the preprocessor here, but this is more sensible.
llvm-svn: 82431
|
|
|
|
|
|
| |
control of this.
llvm-svn: 82430
|
|
|
|
| |
llvm-svn: 82423
|
|
|
|
|
|
| |
after the optimizer may have hacked on the module. Use a WeakVH instead.
llvm-svn: 82324
|
|
|
|
|
|
| |
which will be going away (ie. it's becoming a required parameter) later today.
llvm-svn: 82323
|
|
|
|
| |
llvm-svn: 82321
|
|
|
|
|
|
| |
- No functionality change.
llvm-svn: 82320
|
|
|
|
|
|
|
| |
"->", or "::" if we will be looking into a dependent context. It's not
wrong to use the "template" keyword, but it's to needed, either.
llvm-svn: 82307
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
template smarter, by taking into account which function template
parameters are deducible from the call arguments. For example,
template<typename RandomAccessIterator>
void sort(RandomAccessIterator first, RandomAccessIterator last);
will have a code-completion string like
sort({RandomAccessIterator first}, {RandomAccessIterator last})
since the template argument for its template parameter is
deducible. On the other hand,
template<class X, class Y>
X* dyn_cast(Y *Val);
will have a code-completion string like
dyn_cast<{class X}>({Y *Val})
since the template type parameter X is not deducible from the function
call.
llvm-svn: 82306
|
|
|
|
|
|
| |
angle brackets < > along with placeholder template arguments.
llvm-svn: 82304
|
|
|
|
|
|
|
| |
r82198 and then reverted. This is an intermediate solution, as diagnostic
caching should not rely on static variables.
llvm-svn: 82301
|
|
|
|
| |
llvm-svn: 82299
|
|
|
|
|
|
| |
invalid CFGs to get analyzed.
llvm-svn: 82297
|
|
|
|
|
|
|
| |
results of code completion, e.g., by providing function call syntax
with placeholders for each of the parameters.
llvm-svn: 82293
|
|
|
|
| |
llvm-svn: 82265
|
|
|
|
|
|
| |
operators, type specifiers, type names, and nested-name-specifiers.
llvm-svn: 82264
|
|
|
|
| |
llvm-svn: 82262
|
|
|
|
|
|
| |
compilation with C++ and -fno-lax-vector-conversions
llvm-svn: 82254
|
|
|
|
| |
llvm-svn: 82253
|
|
|
|
|
|
|
|
|
|
| |
- after "using", show anything that can be a nested-name-specifier.
- after "using namespace", show any visible namespaces or namespace aliases
- after "namespace", show any namespace definitions in the current scope
- after "namespace identifier = ", show any visible namespaces or
namespace aliases
llvm-svn: 82251
|
|
|
|
| |
llvm-svn: 82250
|
|
|
|
| |
llvm-svn: 82247
|
|
|
|
| |
llvm-svn: 82246
|
|
|
|
|
|
| |
during code completion
llvm-svn: 82234
|
|
|
|
| |
llvm-svn: 82233
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
look into the current scope for anything that could start a
nested-names-specifier. These results are ranked worse than any of the
results actually found in the lexical scope.
Perform a little more pruning of the result set, eliminating
constructors, __va_list_tag, and any duplication of declarations in
the result set. For the latter, implemented
NamespaceDecl::getCanonicalDecl.
llvm-svn: 82231
|