NoMemberException does not contain enough information to determine which constructor(s) are missing

Can you provide details? I dont understand enough from your bug to reproduce it.

An example reproducing the bug is best.

If I have the following x10 src:

public class Hello{
class hello1
{
def this(m : String)
{

}

def this(m1 : String, m2 : String)
{

}
}

class hello3 extends hello1
{
def this()
{

}
}
}

I'll get an error: "No valid constructor found for Hello.hello1()." This error message is created at line 2089 of x10.types.X10TypeEnv_c (NoMemberException).

At the point where this is created there is not enough information available to determine which super class constructor(s) are available/expected. That is, I expect something like a list containing hello1.this(m : String), hello1.this(m1 : String, m2 : String) to be available at this time

This is not really a blocker. There are existing mechanisms to find potential matches (see, e.g., the code for X10Call_c.tryImplicitConversions() or X10New_c.tryImplicitConversions()) that can be used until the functionality you're asking for is implemented.

Bulk-assigning unscheduled issues to the next release.

bulk defer of unresolved 2.1.0 bugs to 2.1.1.

bulk move of all unresolved issues from 2.1.1 to 2.1.2

defer all non-critical 2.1.2 issues to 2.2.

There's enough API in the compiler to do what we need. It will require writing a bit of code that arguably replicates some logic in the compiler, but that's ok for now.

I'd like to keep the Jira open as a request for additional API, but we don't need this for 2.2.0. Reassigning to 2.2.1.

bulk defer of open issues to 2.2.2.

bulk defer of issues to 2.2.3.

bulk defer of 2.3.0 open issues to 2.3.1.

bulk defer to 2.3.2