The code in Attr.attribDiamond is designed to find a suitable consructor where class type-parameters are replaced by fresh inference variables - it is, in all aspects, a true overload resolution process - only performed on a set of slightly modified members - where all constructors have been turned into generic factory methods, according to the process described in the spec.

After diamond inference is completed, we can have two results:

*) a suitable constructor has been found so that inference is possible
*) no suitable constructor exists such that inference constraints can be satisfied

In the first case, we already know what is the symbol (and the type) iof the applicable constructor - so it would not be necessary (in principle) to apply another overload resolution step to look up those info.

The fact that the code is currently performing two lookups is problematic in terms of code evolution, as the code path for type-checking diamond is very different from the code for checking a generic method call with inference variables in the return type. This difference needs to be minimized moving forward, in order to take advantage of the new target-typing support in method context.