The issue was raised recently that there must be generated forwarders
for some method signatures that we had not previously mentioned in
nosuchmethod-forwarders.md: Private methods with an inaccessible name,
that is, private methods declared in a different library than the
current target of nSM forwarder generation.
Given that such forwarders are semantically significant (a tear-off
performed in the library where the abstract private method declaration
is located would tear off a generated forwarder, rather than causing
an invocation of `noSuchMethod`), we need to specify this.
This CL adds such a specification to nosuchmethod-forwarders.md.
This CL addresses SDK issue #33725, and SDK issue #33727 is related
being concerned with the implementation in the common front
end.
Change-Id: Iedbcdd8b4c8df95c6038022f72b3211ec1b76649
Reviewed-on: https://dart-review.googlesource.com/64380
Reviewed-by: Erik Ernst <eernst@google.com>
This CL changes said document to drop support for requested generation
of forwarder in case of a conflict. Developers must then write a
disambiguating method implementation themselves.
Note that this is what we already agreed during discussions about
this feature, but I noted that it hadn't yet been written into the
document.
Also changes the status to 'under implementation'.
Change-Id: I31b3dd8d65438484824225ad7067d36462d26aa7
Reviewed-on: https://dart-review.googlesource.com/22421
Commit-Queue: Erik Ernst <eernst@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
Erik Ernst