| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
function template declared within a class template did not match a
function in another scope. We really need to rework how
friends-in-templates are semantically checked.
llvm-svn: 93642
|
| |
|
|
| |
llvm-svn: 93584
|
| |
|
|
| |
llvm-svn: 93574
|
| |
|
|
| |
llvm-svn: 93500
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
do not look into base classes if there are any dependent base
classes. Instead, note in the lookup result that we couldn't look into
any dependent bases. Use that new result kind to detect when this case
occurs, so that we can fall back to treating the type/value/etc. as a
member of an unknown specialization.
Fixes an issue where we were resolving lookup at template definition
time and then missing an ambiguity at template instantiation time.
llvm-svn: 93497
|
| |
|
|
| |
llvm-svn: 93452
|
| |
|
|
|
|
|
|
| |
finds nothing), and the current instantiation has dependent base
classes, treat the qualified lookup as if it referred to an unknown
specialization. Fixes PR6031.
llvm-svn: 93433
|
| |
|
|
|
|
| |
Thanks Ted.
llvm-svn: 93413
|
| |
|
|
|
|
|
|
| |
need an error term for the CFG. I suspect we'll always have to cope
with getCFG returning 0, though, I'd love to see even that possibility
removed.
llvm-svn: 93411
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
that name constructors, the endless joys of out-of-line constructor
definitions, and various other corner cases that the previous hack
never imagined. Fixes PR5688 and tightens up semantic analysis for
constructor names.
Additionally, fixed a problem where we wouldn't properly enter the
declarator scope of a parenthesized declarator. We were entering the
scope, then leaving it when we saw the ")"; now, we re-enter the
declarator scope before parsing the parameter list.
Note that we are forced to perform some tentative parsing within a
class (call it C) to tell the difference between
C(int); // constructor
and
C (f)(int); // member function
which is rather unfortunate. And, although it isn't necessary for
correctness, we use the same tentative-parsing mechanism for
out-of-line constructors to improve diagnostics in icky cases like:
C::C C::f(int); // error: C::C refers to the constructor name, but
// we complain nicely and recover by treating it as
// a type.
llvm-svn: 93322
|
| |
|
|
|
|
|
| |
This now rejects literal operators that don't meet the requirements.
Templates are not yet checked for.
llvm-svn: 93315
|
| |
|
|
| |
llvm-svn: 93287
|
| |
|
|
|
|
|
| |
is not also a typedef-name" actually means. For anyone keeping score,
that's John: 2, Doug: 0.
llvm-svn: 93196
|
| |
|
|
|
|
|
| |
latter may (eventually) perform multiple levels of desugaring (thus
breaking the newly-added tests) and the former is faster. Thanks, John!
llvm-svn: 93192
|
| |
|
|
|
|
|
|
|
| |
they redefine is a class-name but not a typedef-name, per C++0x
[dcl.typedef]p4. The code in the test was valid C++98 and is valid
C++0x, but an unintended consequence of DR56 made it ill-formed in
C++03 (which we were luck enough to implement). Fixes PR5455.
llvm-svn: 93188
|
| |
|
|
|
|
|
| |
pointing to the declaration that we found that has that name (if it is
unique).
llvm-svn: 92877
|
| |
|
|
|
|
|
|
| |
result for a nested class whose first non-pure virtual member function
has an inline body. Previously, we were checking for the key function
before we had seen the (delayed) inline body.
llvm-svn: 92839
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
deterministic and work properly with templates. Once a class that
needs a vtable has been defined, we now do one if two things:
- If the class has no key function, we place the class on a list of
classes whose virtual functions will need to be "marked" at the
end of the translation unit. The delay until the end of the
translation unit is needed because we might see template
specializations of these virtual functions.
- If the class has a key function, we do nothing; when the key
function is defined, the class will be placed on the
aforementioned list.
At the end of the translation unit, we "mark" all of the virtual
functions of the classes on the list as used, possibly causing
template instantiation and other classes to be added to the
list. This gets LLVM's lib/Support/CommandLine.cpp compiling again.
llvm-svn: 92821
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- All classes can have a key function; templates don't change that.
non-template classes when computing the key function.
- We always mark all of the virtual member functions of class
template instantiations.
- The vtable for an instantiation of a class template has weak
linkage.
We could probably use available_externally linkage for vtables of
classes instantiated by explicit instantiation declarations (extern
templates), but GCC doesn't do this and I'm not 100% that the ABI
permits it.
llvm-svn: 92753
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
assembly code. This avoids changing the bahvior when normal asm("")
statements are used.
The type of code affected would be:
void* t4(void) { __asm mov eax, fs:[0x10] }
I hope people like this version, if not, let me know.
llvm-svn: 92531
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
constructs:
- Instance variable lookup ("foo->ivar" and, in instance methods, "ivar")
- Property name lookup ("foo.prop")
- Superclasses
- Various places where a class name is required
- Protocol names (e.g., id<proto>)
This seems to cover many of the common places where typos could occur.
llvm-svn: 92449
|
| |
|
|
|
|
|
|
| |
attach the appropriate attributes to it. I don't think
this manifests as any real change though, we're still
not getting the right LLVM IR attributes out of codegen.
llvm-svn: 92316
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
tring str2;
we produce the following diagnostic + fix-it:
typo.cpp:15:1: error: unknown type name 'tring'; did you mean 'string'?
tring str2;
^~~~~
string
To make this really useful, we'll need to introduce typo correction in
many more places (wherever we do name lookup), and implement
declaration-vs-expression heuristics that cope with typos
better. However, for now this will handle the simple cases where we
already get good "unknown type name" diagnostics.
The LookupVisibleDecls functions are intended to be used by code
completion as well as typo correction; that refactoring will happen
later.
llvm-svn: 92308
|
| |
|
|
|
|
| |
the AST lest we run into some crazy canonicalization bug like PR5874.
llvm-svn: 92283
|
| |
|
|
|
|
|
|
|
|
| |
Darwin's sekrit fourth argument. This should probably be factored to
let targets make target-specific decisions about what main() should look like.
Fixes rdar://problem/7414990
or if different platforms have radically different ideas of what they want in
llvm-svn: 92128
|
| |
|
|
| |
llvm-svn: 92090
|
| |
|
|
| |
llvm-svn: 91881
|
| |
|
|
|
|
| |
since the context is available in the Decl
llvm-svn: 91862
|
| |
|
|
|
|
|
|
|
|
| |
Sema::getTypeName.
"LookupNestedNameSpecifierName" isn't quite the right kind of lookup, though;
it doesn't ignore namespaces. Someone more familiar with the lookup code
should fix this properly.
llvm-svn: 91809
|
| |
|
|
|
|
| |
assignment.
llvm-svn: 91798
|
| |
|
|
|
|
| |
over to InitializationSequence. I could swear that this fixes a PR somewhere, but I couldn't figure out which one
llvm-svn: 91796
|
| |
|
|
| |
llvm-svn: 91795
|
| |
|
|
| |
llvm-svn: 91794
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Because of the rules of base-class lookup* and the restrictions on typedefs, it
was actually impossible for this to cause any problems more serious than the
spurious acceptance of
template <class T> class A : B<A> { ... };
instead of
template <class T> class A : B<A<T> > { ... };
but I'm sure we can all agree that that is a very important restriction which
is well worth making another Parser->Sema call for.
(*) n.b. clang++ does not implement these rules correctly; we are not ignoring
non-type names
llvm-svn: 91792
|
| |
|
|
|
|
|
| |
the redeclaration problems in the [temp.explicit]p3 testcase worse, but I can
live with that; they'll need to be fixed more holistically anyhow.
llvm-svn: 91771
|
| |
|
|
|
|
| |
instantiation, since we're not using a Scope object for that anyway.
llvm-svn: 91770
|
| |
|
|
|
|
|
|
| |
small bug fixes in SemaInit, switch over SemaDecl to use it more often, and
change a bunch of diagnostics which are different with the new initialization
code.
llvm-svn: 91767
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
different functions and pick the function at lookup initialization time.
In theory we could actually divide the criteria functions into N different
functions for the N cases, but it's so not worth it.
Among other things, lets us invoke LookupQualifiedName without recomputing
IDNS info every time.
Do some refactoring in SemaDecl to avoid an awkward special case in LQN
that was only necessary for redeclaration testing for anonymous structs/unions ---
which could be done more efficiently with a scoped lookup anyway.
llvm-svn: 91676
|
| |
|
|
| |
llvm-svn: 91629
|
| |
|
|
|
|
| |
qualifier. this also removes a FIXME
llvm-svn: 91601
|
| |
|
|
|
|
| |
noalias. the rest will be infered by llvm optz
llvm-svn: 91600
|
| |
|
|
| |
llvm-svn: 91563
|
| |
|
|
|
|
|
|
| |
default, and adds the malloc attribute to the global function new() and to the overloaded new operators.
feel free to chage the name to this lengthy argument
llvm-svn: 91543
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
than using its own partial implementation of initialization.
Switched CheckInitializerTypes over to
InitializedEntity/InitializationKind, to help move us closer to
InitializationSequence.
Added InitializedEntity::getName() to retrieve the name of the entity,
for diagnostics that care about such things.
Implemented support for default initialization in
InitializationSequence.
Clean up the determination of the "source expressions" for an
initialization sequence in InitializationSequence::Perform.
Taught CXXConstructExpr to store more location information.
llvm-svn: 91492
|
| |
|
|
| |
llvm-svn: 91450
|
| |
|
|
|
|
|
|
|
| |
attribute to function pointers. It also fixes Sema to check function
pointers for the noreturn attribute when checking for fallthrough.
Patch by Chip Davis, with a slight fix to pass the testsuite.
llvm-svn: 91408
|
| |
|
|
| |
llvm-svn: 91089
|
| |
|
|
|
|
|
| |
block, if the function is supposed to return a value as we don't know
exactly what the asm code does.
llvm-svn: 91073
|
| |
|
|
|
|
| |
recently introduced crash.
llvm-svn: 91070
|
| |
|
|
|
|
|
|
| |
declaration. Rename note_using_decl to note_using, which is possibly less confusing.
Add a test for non-class-scope using decl collisions and be sure to note the case
we can't diagnose yet.
llvm-svn: 91057
|