[foreign] RFR 8208199: Revisit one interface per header file approach

[Maurizio Cimadamore]

On 08/08/18 13:25, Sundararajan Athijegannathan wrote:
>   May I suggest that we go with the current scheme (which is minimal 
> changes) and revisit based on use-cases? 
While I'm fine with the changes, and I agree that they are 'minimal', 
I'm also worried that they add a new design dimension that is not fully 
explored. Some of the issues with the approach are the lack of 
granularity in specifying the set of headers to be 'followed', as well 
as the fact that this new multi-header mode completely invalidates the 
assumptions of unresolved layout resolution - the assumption there was 
that any layout mentioned in a class C could be resolvable by looking at 
the outermost enclosing class of C (**).

My feeling is that we have both missing metadata and missing jextract 
options here.

(**) Consider this example:

//a.h
import "b.h"

void fn(struct S);

//b.h
struct S { int i; };

If you extract this with jextract, you get two headers, one for 'a' and 
one for 'b'. The function descriptor for 'fn', which is in 'a.class' 
will refer to the layout of S, which is in B.class. With your patch, 
a.class will also 'implement' b.class. Here, the resolver for a.class 
knows nothing about S. The only way to support this resolution is via 
ad-hoc prescanning of all classes in the signatures of a.class (which we 
currently do, but it's a mouthful, design-wise).

My hope here is to come up with a mechanism to specify related headers 
both from a point of view of jextract flag (e.g. so that jextract will 
follow headers), but also in a way so that the information about the 
header relationship is preserved at runtime into some metadata; that 
way, the information can be used to perform layout resolution in a 
precise and well-defined way.

While this patch defines no additional metadata, one could argue that 
the injected subtyping relationship it provides is, itself, some form of 
metadata we could exploit during resolution. And, using inheritance has 
the obvious advantage of exposing a model that 'makes sense' for Java users.

With all these things in mind, let's give this code a try - and see if 
we can fit a story for better layout resolution on top of it.

Cheers
Maurizio