RFR: 7903933: Move sharable items from different generations to a common file [v4]

[Maurizio Cimadamore]

On Thu, 27 Mar 2025 10:33:26 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Then there's (6). The first reaction I got was: well, whether primitive layouts should be emitted or not seems like another filtering decision (e.g. let's add some options to filter these out). Except this would not work -- it's not just about filtering -- it's also about telling every other file where to find the layouts for such primitive types. If they are defined somewhere else, then jextract need to know _where_ to find them (e.g. if they are referenced by some other layout jextract is building). Which seems a similar problem as the one this PR is trying to solve anyway.

Note/history: while tempting, we can't really put (6) inside the main FFM API. We have thought about this for a long time -- the issue is that the types of the primitive layouts is not guaranteed to be stable. E.g. `C_LONG` might be either a `ValueLayout.OfLong` or a `ValueLayout.OfInt`, depending on the platforms. Other layouts, such as `C_LONG_DOUBLE` might only be available on some platforms and not others. This is why, long ago, we decided that the main FFM API should not concern with providing layout constants for C types -- as the set of such constant is not stable. Instead, such primitive C layouts can be "discovered" using the `Linker::canonicalLayouts` API.

-------------

PR Comment: https://git.openjdk.org/jextract/pull/278#issuecomment-2757548082