Fix a bug in how we were resolving the address of overloaded functions
when the resolution took place due to a single template specialization being named with an explicit template argument list. In this case, the "resolution" doesn't take into account the target type at all, and therefore can take place for functions, static member functions, and *non-static* member functions. The latter weren't being properly checked and their proper form enforced in this scenario. We now do so. The result of this last form slipping through was some confusing logic in IsStandardConversion handling of these resolved address-of expressions which eventually exploded in an assert. Simplify this logic a bit and add some more aggressive asserts to catch improperly formed expressions getting into this routine. Finally add systematic testing of member functions, both static and non-static, in the various forms they can take. One of these is essentially PR9563, and this commit fixes the crash in that PR. However, the diagnostics for this are still pretty terrible. We at least are now accepting the correct constructs and rejecting the invalid ones rather than accepting invalid or crashing as before. llvm-svn: 128456
Loading
Please register or sign in to comment