8261511: jextract fails to handle name clashes between unrelated constants

[sundararajana]

constants class is nested properly. piggybacking to fix long whitespace string in pretty printer

---

Progress

• Change must not contain extraneous whitespace
• Change must be properly reviewed

Issue

• JDK-8261511: jextract fails to handle name clashes between unrelated constants

Reviewers

• Maurizio Cimadamore (@mcimadamore - Committer)

Download

$ git fetch https://git.openjdk.java.net/panama-foreign pull/468/head:pull/468
$ git checkout pull/468

[bridgekeeper]

👋 Welcome back sundar! A progress list of the required criteria for merging this PR into foreign-jextract will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[mlbridge]

Webrevs

• 01: Full - Incremental (4d20e93)
• 00: Full (7efcbd1)

[mcimadamore]

Not super sure about this fix.

If I undrerstand correctly, this will generate a nested constant class inside the enclosing struct, right (rather than going back to the enclosing header class). This is ok for clashes between header functions and function pointers, but how about cases like:

struct Foo {
    int (*sum)(int x, int y);
    struct Bar {
      int (*sum)(float x, float y);
    } bar;
};

I tried this, and it seems like we're probably ok, there are only two possible cases here:

• the innermost struct is anon (e.g. doesn't have a name, and doesn't introduce a new struct field) - in this case it is an error if the anon struct declares a field that clashes with some enclosing field

• the innermost struct is not anon (e.g. has a name, or introduces a struct field name); in this case a nested struct class is generated, and constants are added in there instead.

So, I believe the logic works, but I think it generates a redundant constant class (note that the struct class already acts as a constant holder - in fact, StructBuilder extends ConstantBuilder).

It would be nice if, instead, this method would do something like:

public void emitWithConstantClass(String javaName, Consumer<ConstantBuilder> constantConsumer) {
if (this instanceof ConstantBuilder cb) {
   // use this class to emit constants
   constantConsumer.accept(cb);
   
} else {
    enclosing.emitWithConstantClass(javaName, constantConsumer);
}
}

By doing so, we should skip the generation of the extra constant class?

[mcimadamore]

Looks good - as discussed offline there is a risk (present already) that reusing structs as constant holder might end up with scalability issues (e.g, if a struct has too many fields) so we probably will have to keep an eye on this.

[openjdk]

@sundararajana This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8261511: jextract fails to handle name clashes between unrelated constants

Reviewed-by: mcimadamore

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been no new commits pushed to the foreign-jextract branch. If another commit should be pushed before you perform the /integrate command, your PR will be automatically rebased. If you prefer to avoid any potential automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the foreign-jextract branch, type /integrate in a new comment.

[sundararajana]

/integrate

[openjdk]

@sundararajana Pushed as commit a11bb7d.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.