John McCall d14a86427f "Incremental" progress on using expressions, by which I mean totally ripping ... into pretty much everything about overload resolution in order to wean BuildDeclarationNameExpr off LookupResult::getAsSingleDecl(). Replace UnresolvedFunctionNameExpr with UnresolvedLookupExpr, which generalizes the idea of a non-member lookup that we haven't totally resolved yet, whether by overloading, argument-dependent lookup, or (eventually) the presence of a function template in the lookup results. Incidentally fixes a problem with argument-dependent lookup where we were still performing ADL even when the lookup results contained something from a block scope. Incidentally improves a diagnostic when using an ObjC ivar from a class method. This just fell out from rewriting BuildDeclarationNameExpr's interaction with lookup, and I'm too apathetic to break it out. The only remaining uses of OverloadedFunctionDecl that I know of are in TemplateName and MemberExpr. llvm-svn: 89544		2009-11-21 08:51:07 +00:00
..
dcl.init/dcl.init.aggr	In some dependent contexts, incomplete array types persist into FinalizeDeclaratorGroup. Don't require them to have a complete type. This allows us to compile Hello World with the Apache stdcxx library. If you don't use endl, it even links and runs.	2009-10-17 19:37:06 +00:00
dcl.meaning	"Incremental" progress on using expressions, by which I mean totally ripping	2009-11-21 08:51:07 +00:00