Integrated: 7903611: Position-based deduplication logic is insufficient

Maurizio Cimadamore mcimadamore at openjdk.org
Fri Dec 15 09:57:14 UTC 2023


On Thu, 14 Dec 2023 22:09:24 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This PR adds a new way to deduplicate declarations in TreeMaker that is no longer dependent on cursor positions.
> Instead, we now deduplicate using cursor equality (`clang_equalCursors`), which is more precise, and works even when declarations are reused via macros (see test).
> 
> The main issue with using cursor equality is that the cursors we want to compare have their segment closed by the time the comparison needs to be performed. So, instead, we dump the contents of the cursor segment on-heap, and stash it in a `Cursor.Key` class. Later, if we need to compare two cursors, we dump the heap contents back on an off-heap segment, and then call `clang_equalCursors` on the two segments. Since we can only compare two cursors at any given time, and we don't use multiple thread, it is safe to share the comparison space.
> 
> One problem with using cursor equality is that it doesn't work when the same header is reparsed multiple times - in that case clang will just say that the new cursor and the old cursor are different, even if they point at the same declaration. Presumably that's because the two cursors belong to different translation units.
> 
> Because of this, when parsing macros with pointer values, we have to downgrade the pointer type to `void*` (e.g. we lose information on the actual pointee type). This is not too bad, given that this type information was not used anyways.

This pull request has now been integrated.

Changeset: d118a231
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.org/jextract/commit/d118a2313fc12a0b6a3b348ca207d18f8f255b33
Stats:     270 lines in 9 files changed: 235 ins; 19 del; 16 mod

7903611: Position-based deduplication logic is insufficient

Reviewed-by: jvernee

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

PR: https://git.openjdk.org/jextract/pull/163


More information about the jextract-dev mailing list