[foreign] RFR:8223105

[Maurizio Cimadamore]

On 02/05/2019 18:08, Henry Jen wrote:
> I noticed that inconsistency, but because the static name field of VarTree is use for the accessor function name, we cannot use that field. But we can put in the name annotation of layout. The reason I didn’t go with that is because I am not sure if current behavior(layout without name annotation) is for a reason.

I think that, whenever the underlying name doesn't match the cursor 
spelling, it is reasonable to have a name annotation embedded in the 
layout. Currently we do not add any name annotation to the global var 
layouts simply because we assume that cursor spelling == name. That 
might be a fine assumption, but the _asm_ label changes that.

I think where I'd like to land is a place where these things are handled 
in an uniform way - so, the layout associated to a FunctionTree/VarTree 
can either:

* have no name annotation - in which case: cursor spelling == Java 
member name == native symbol name
* have a name annotation - in which case: cursor spelling == Java member 
name != native symbol name

There's a catch though; when we emit layouts for global variables, we 
always need a name annotation, no matter what (that's how we can 
associate global layouts to global symbols), e.g. :

@NativeHeader(globals = {
             "i32(errno)",
             "u64(environ):u64:v"}
     )

This introduces a slight asymmetry w.r.t. functions, because, 
essentially, globals always need some name annotation (to be referenced 
by accessors) whereas functions don't.

That said, I think that adding a name annotation on the global VarTree 
layout which takes into account the label thingie is likely the right 
thing to do. That way, globals will always come equipped with the 
'right' name annotation, which can then be used when generating both the 
toplevel annotation and the associated accessors.

Maurizio