From wo6980 at gmail.com Mon Oct 2 09:44:58 2023 From: wo6980 at gmail.com (Oliver Weiler) Date: Mon, 2 Oct 2023 11:44:58 +0200 Subject: Why are java and javac included in the prebuilt binaries? Message-ID: Hi everyone! A few users of SDKMAN! have requested to add jextract as a new candidate to SDKMAN!. After adding some of the prebuilt versions, we realized that the bin/ directory contains java and javac in addition to jextract itself. The problem is that SDKMAN! adds the path of jextract's bin/ directory to the PATH, which collides the java and javac versions SDKMAN!s respective Java candidate. Would it be possible to remove java/javac from the prebuilt binaries? Best regards, Oliver -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Mon Oct 2 12:13:54 2023 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 2 Oct 2023 13:13:54 +0100 Subject: Why are java and javac included in the prebuilt binaries? In-Reply-To: References: Message-ID: Hi, While removing javac should be doable, I think dropping the java launcher is more problematic, as that launcher is called by the jextract launcher. So, doing something like that would require a deeper restructuring of the build layout I'm afraid. Maurizio On 02/10/2023 10:44, Oliver Weiler wrote: > Hi everyone! > > A few users of SDKMAN! have requested to add jextract as a new > candidate to SDKMAN!. After adding some of the prebuilt versions, we > realized that the bin/ directory contains java and javac in addition > to jextract itself. > > The problem is that SDKMAN! adds the path of jextract's?bin/ directory > to the PATH, which collides the java and javac versions SDKMAN!s > respective Java candidate. > > Would it be possible to remove java/javac from the prebuilt binaries? > > Best regards, > Oliver From jorn.vernee at oracle.com Tue Oct 17 07:34:47 2023 From: jorn.vernee at oracle.com (Jorn Vernee) Date: Tue, 17 Oct 2023 09:34:47 +0200 Subject: [External] : Re: Jextract failure on llvm 17.0.1 with sdl In-Reply-To: References: <9aef2015-db7c-4c96-a26e-a1d8d94ece22@oracle.com> Message-ID: > I can update my branch with those changes and make an mr out of it if you'd like to use it as reference? Thanks, that could be useful for reference. I think we might want to change the error handling strategy of unexposed types in general, and instead filter them out, rather than crashing with an exception. Jorn On 17/10/2023 02:15, Clayton Walker wrote: > Thanks for the additional details, other than working around it I was > pretty lost when I found out that its kind was (as you mentioned) > unexposed. > > To get around that locally (pretty sure nothing in SDL requires > __bf16) I ended up adding a case to canonical.equalType(t) where if > t.spelling().equals("__bf16") I return > Type.primitive(Primitive.Kind.BFloat16). (Which itself is added to the > Type.Primitive.Kind class as an unsupported layout size 2). > > I can update my branch with those changes and make an mr out of it if > you'd like to use it as reference? > > On Mon, Oct 16, 2023 at 3:06?PM Jorn Vernee > wrote: > > Hi, > > This exception comes from the following section in > TypeMaker::makeTypeInternal:" > > ???????????? case Unexposed: > ???????????? case Elaborated: > ???????????????? org.openjdk.jextract.clang.Type canonical = > t.canonicalType(); > ???????????????? if (canonical.equalType(t)) { > ???????????????????? throw new TypeException("Unknown type with same > canonical type: " + t.spelling()); > ???????????????? } > ???????????????? return makeType(canonical); > > I think in this case we're looking at an 'Unexposed' type, which > means > that libclang (the C interface of clang) does not support this > type [1]. > Looking at the implementation of `GetTypeKind` in libclang [2], it > delegates to `GetBuiltinTypeKind` [3] for builtin types, and this > doesn't have a case for BFloat16, so instead it returns > `CXType_Unexposed`. i.e. this seems to be an issue that needs to be > fixed in libclang itself. There might be other changes that are > needed > to fully support this type, but I can't say off the top of my head. > > As a workaround, we might be able to specifically detect __bf16 > based on > its name/spelling, and then return an instance of Type.Primitive from > TypeMaker::makeTypeInternal, that is later filtered out in > `UnsupportedLayouts`. That would allow jextract to continue and > generate > something, but wouldn't work for cases where the __bf16 type is > actually > required since we would just omit any function/variable that used > this > type in its declaration. > > Jorn > > [1]: > https://clang.llvm.org/doxygen/group__CINDEX__TYPES.html#gaad39de597b13a18882c21860f92b095a > > [2]: > https://github.com/llvm/llvm-project/blob/llvmorg-17.0.1/clang/tools/libclang/CXType.cpp#L94 > > [3]: > https://github.com/llvm/llvm-project/blob/llvmorg-17.0.1/clang/tools/libclang/CXType.cpp#L29 > > > On 16/10/2023 20:15, Clayton Walker wrote: > > Hello, > > > > I've been working on creating a set of bindings against sdl2, > and have > > encountered the following issue: > > > > Unknown type with same canonical type: __bf16 > > > > I wasn't sure what needed to be fixed, perhaps a missing > declaration > > or mapping in jextract, but after a bit of digging I tried > adding the > > clang BFloat16 data type but had no luck. > > > https://github.com/openjdk/jextract/compare/jdk21...Sineaggi:jextract:jdk-21-bf16 > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Fri Oct 20 00:05:58 2023 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 20 Oct 2023 01:05:58 +0100 Subject: jextract fails to parse stdatomic.h In-Reply-To: References: Message-ID: Hi Artem, thanks for the report. This issue is probably a latent one, which has been made manifest by a recent PR: https://git.openjdk.org/jextract/pull/121 I believe the underlying cause is that there is some type involved in this declaration is not supported (meaning we can't generate a layout for it). This causes the layout to be dropped from the struct. But now we have a size mismatch, as clang is reporting that the size of the struct is 1 byte, but, since we end up with an empty struct layout, our size is zero. If I had to guess (given the headers involved), I'd say that the Atomic type kind is not supported by TypeMaker. Probably related to this old issue: https://mail.openjdk.org/pipermail/panama-dev/2019-May/005387.html Maurizio On 20/10/2023 00:42, Artem Ananev wrote: > Hi, > > I use jextract version "JDK version 21+35-LTS-2513? on a Ubuntu 22.04.3 box. It fails with the following error: > > ``` > java.lang.AssertionError: Unexpected size for layout []. Found 0 ; expected 1 > at org.openjdk.jextract at 21/org.openjdk.jextract.impl.RecordLayoutComputer.checkSize(RecordLayoutComputer.java:198) > at org.openjdk.jextract at 21/org.openjdk.jextract.impl.StructLayoutComputer.finishRecord(StructLayoutComputer.java:142) > at org.openjdk.jextract at 21/org.openjdk.jextract.impl.RecordLayoutComputer.compute(RecordLayoutComputer.java:114) > at org.openjdk.jextract at 21/org.openjdk.jextract.impl.RecordLayoutComputer.computeInternal(RecordLayoutComputer.java:89) > at org.openjdk.jextract at 21/org.openjdk.jextract.impl.RecordLayoutComputer.compute(RecordLayoutComputer.java:71) > at org.openjdk.jextract at 21/org.openjdk.jextract.impl.TreeMaker.createRecord(TreeMaker.java:205) > at org.openjdk.jextract at 21/org.openjdk.jextract.impl.TreeMaker.createTreeInternal(TreeMaker.java:104) > at org.openjdk.jextract at 21/org.openjdk.jextract.impl.TreeMaker.createTree(TreeMaker.java:93) > at org.openjdk.jextract at 21/org.openjdk.jextract.impl.Parser.lambda$parse$2(Parser.java:86) > at org.openjdk.jextract at 21/org.openjdk.jextract.clang.Cursor$CursorChildren$Context.visit(Cursor.java:223) > at org.openjdk.jextract at 21/org.openjdk.jextract.clang.Cursor$CursorChildren.lambda$static$0(Cursor.java:242) > at org.openjdk.jextract at 21/org.openjdk.jextract.clang.libclang.Index_h.clang_visitChildren(Index_h.java:5108) > at org.openjdk.jextract at 21/org.openjdk.jextract.clang.Cursor$CursorChildren.forEach(Cursor.java:254) > at org.openjdk.jextract at 21/org.openjdk.jextract.clang.Cursor.forEach(Cursor.java:194) > at org.openjdk.jextract at 21/org.openjdk.jextract.impl.Parser.parse(Parser.java:64) > at org.openjdk.jextract at 21/org.openjdk.jextract.JextractTool.parse(JextractTool.java:116) > at org.openjdk.jextract at 21/org.openjdk.jextract.JextractTool.run(JextractTool.java:466) > at org.openjdk.jextract at 21/org.openjdk.jextract.JextractTool.main(JextractTool.java:174) > Unrecoverable uncaught exception encountered. The VM will now exit > ``` > > There is no way to understand where exactly it fails, so I downloaded jextract sources, ran it in debug mode, and found the error happens when it?s parsing , in particular this line: > > ``` > typedef struct atomic_flag { atomic_bool _Value; } atomic_flag; > ``` > > If I comment out this line (and all other declarations in the same header that depend on atomic_flag), jextract no longer fails. Note that this header is a part of jextract distribution, it?s in /conf/jextract/stdatomic.h > > Steps to reproduce: > > ``` > echo '#include ' >/tmp/test.h && jextract --source /tmp/test.h > ``` > > Thanks, > Artem > From jvernee at openjdk.org Fri Oct 20 16:48:08 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Fri, 20 Oct 2023 16:48:08 GMT Subject: RFR: (jdk22 port) 7903435: TestDocComments fails on Windows Message-ID: Port of https://github.com/openjdk/jextract/pull/106 for jdk 22 branch ------------- Commit messages: - 7903435: TestDocComments fails on Windows Changes: https://git.openjdk.org/jextract/pull/133/files Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=133&range=00 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jextract/pull/133.diff Fetch: git fetch https://git.openjdk.org/jextract.git pull/133/head:pull/133 PR: https://git.openjdk.org/jextract/pull/133 From maurizio.cimadamore at oracle.com Fri Oct 20 17:06:58 2023 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 20 Oct 2023 17:06:58 +0000 Subject: jextract fails to parse stdatomic.h In-Reply-To: <93EBA824-6DB1-4D4C-A428-2CC7C1E2DDB8@swirldslabs.com> References: <93EBA824-6DB1-4D4C-A428-2CC7C1E2DDB8@swirldslabs.com> Message-ID: <02d6bcabd8a4471a4636d246a76245c2dd8ec42e.camel@oracle.com> Hi, A fix for this issue is being worked on here: https://github.com/openjdk/jextract/pull/132 This will be backported to the 21 branch (and we will respin new binaries for it). CheersMaurizio On Fri, 2023-10-20 at 09:51 -0700, Artem Ananev wrote: > Hi Maurizio, > > thank you for quick response. > > Is there a workaround to this issue? Will it be addressed in the > final version of FFI / jextract? > > From what I saw during debugging, your assumption about the > underlying problem looks right. In TypeImpl class there is a field > `layoutMaker`, which implements a type visitor. When this issue with > atomic_flag happens, this visitor throws an unsupported exception > from its visitType() method. > > Thanks, > Artem > > > On Oct 19, 2023, at 5:05 PM, Maurizio Cimadamore < > > maurizio.cimadamore at oracle.com> wrote: > > > > Hi Artem, > > thanks for the report. This issue is probably a latent one, which > > has been made manifest by a recent PR: > > > > https://git.openjdk.org/jextract/pull/121 > > > > I believe the underlying cause is that there is some type involved > > in this declaration is not supported (meaning we can't generate a > > layout for it). This causes the layout to be dropped from the > > struct. But now we have a size mismatch, as clang is reporting that > > the size of the struct is 1 byte, but, since we end up with an > > empty struct layout, our size is zero. > > > > If I had to guess (given the headers involved), I'd say that the > > Atomic type kind is not supported by TypeMaker. > > > > Probably related to this old issue: > > https://mail.openjdk.org/pipermail/panama-dev/2019-May/005387.html > > > > Maurizio > > > > On 20/10/2023 00:42, Artem Ananev wrote: > > > Hi, > > > > > > I use jextract version "JDK version 21+35-LTS-2513? on a Ubuntu > > > 22.04.3 box. It fails with the following error: > > > > > > ``` > > > java.lang.AssertionError: Unexpected size for layout []. Found 0 > > > ; expected 1 > > > at org.openjdk.jextract at 21/org.openjdk.jextract.impl.RecordLayo > > > utComputer.checkSize(RecordLayoutComputer.java:198) > > > at org.openjdk.jextract at 21/org.openjdk.jextract.impl.StructLayo > > > utComputer.finishRecord(StructLayoutComputer.java:142) > > > at org.openjdk.jextract at 21/org.openjdk.jextract.impl.RecordLayo > > > utComputer.compute(RecordLayoutComputer.java:114) > > > at org.openjdk.jextract at 21/org.openjdk.jextract.impl.RecordLayo > > > utComputer.computeInternal(RecordLayoutComputer.java:89) > > > at org.openjdk.jextract at 21/org.openjdk.jextract.impl.RecordLayo > > > utComputer.compute(RecordLayoutComputer.java:71) > > > at org.openjdk.jextract at 21/org.openjdk.jextract.impl.TreeMaker. > > > createRecord(TreeMaker.java:205) > > > at org.openjdk.jextract at 21/org.openjdk.jextract.impl.TreeMaker. > > > createTreeInternal(TreeMaker.java:104) > > > at org.openjdk.jextract at 21/org.openjdk.jextract.impl.TreeMaker. > > > createTree(TreeMaker.java:93) > > > at org.openjdk.jextract at 21/org.openjdk.jextract.impl.Parser.lam > > > bda$parse$2(Parser.java:86) > > > at org.openjdk.jextract at 21/org.openjdk.jextract.clang.Cursor$Cu > > > rsorChildren$Context.visit(Cursor.java:223) > > > at org.openjdk.jextract at 21/org.openjdk.jextract.clang.Cursor$Cu > > > rsorChildren.lambda$static$0(Cursor.java:242) > > > at org.openjdk.jextract at 21/org.openjdk.jextract.clang.libclang. > > > Index_h.clang_visitChildren(Index_h.java:5108) > > > at org.openjdk.jextract at 21/org.openjdk.jextract.clang.Cursor$Cu > > > rsorChildren.forEach(Cursor.java:254) > > > at org.openjdk.jextract at 21/org.openjdk.jextract.clang.Cursor.fo > > > rEach(Cursor.java:194) > > > at org.openjdk.jextract at 21/org.openjdk.jextract.impl.Parser.par > > > se(Parser.java:64) > > > at org.openjdk.jextract at 21/org.openjdk.jextract.JextractTool.pa > > > rse(JextractTool.java:116) > > > at org.openjdk.jextract at 21/org.openjdk.jextract.JextractTool.ru > > > n(JextractTool.java:466) > > > at org.openjdk.jextract at 21/org.openjdk.jextract.JextractTool.ma > > > in(JextractTool.java:174) > > > Unrecoverable uncaught exception encountered. The VM will now > > > exit > > > ``` > > > > > > There is no way to understand where exactly it fails, so I > > > downloaded jextract sources, ran it in debug mode, and found the > > > error happens when it?s parsing , in particular this > > > line: > > > > > > ``` > > > typedef struct atomic_flag { atomic_bool _Value; } atomic_flag; > > > ``` > > > > > > If I comment out this line (and all other declarations in the > > > same header that depend on atomic_flag), jextract no longer > > > fails. Note that this header is a part of jextract distribution, > > > it?s in /conf/jextract/stdatomic.h > > > > > > Steps to reproduce: > > > > > > ``` > > > echo '#include ' >/tmp/test.h && jextract --source > > > /tmp/test.h > > > ``` > > > > > > Thanks, > > > Artem > > > From mcimadamore at openjdk.org Fri Oct 20 17:24:09 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 20 Oct 2023 17:24:09 GMT Subject: RFR: 7903573: Jextract does not support atomic types Message-ID: <2tmmqZi0zQgfs1kp04wkmO7ndKstXJ11vk9Olwo2HQA=.84fa5d3c-09a2-4fc3-a3a5-520dea1cc1a4@github.com> This PR fixes a crash when jextract processes atomic types. These types are exposed in libclang in a weird way: their kind is set to `Atomic` but they do not reveal what the underlying type is (except for the type spelling). The underlying type has to be discovered using the `clang_Type_getValueType` function on the `Atomic` type. This PR does just that, and also adds a test for various atomic types. ------------- Commit messages: - Remove whitespaces - Add copyright - Initial push Changes: https://git.openjdk.org/jextract/pull/132/files Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=132&range=00 Issue: https://bugs.openjdk.org/browse/CODETOOLS-7903573 Stats: 158 lines in 6 files changed: 158 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jextract/pull/132.diff Fetch: git fetch https://git.openjdk.org/jextract.git pull/132/head:pull/132 PR: https://git.openjdk.org/jextract/pull/132 From jvernee at openjdk.org Fri Oct 20 17:24:09 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Fri, 20 Oct 2023 17:24:09 GMT Subject: RFR: 7903573: Jextract does not support atomic types In-Reply-To: <2tmmqZi0zQgfs1kp04wkmO7ndKstXJ11vk9Olwo2HQA=.84fa5d3c-09a2-4fc3-a3a5-520dea1cc1a4@github.com> References: <2tmmqZi0zQgfs1kp04wkmO7ndKstXJ11vk9Olwo2HQA=.84fa5d3c-09a2-4fc3-a3a5-520dea1cc1a4@github.com> Message-ID: <7Ysp5uP7Xidcz19oH1O9as5wH0FcucJnAujH_r11Fzc=.3533311a-499c-4b01-9f3f-7c8a6242a43f@github.com> On Fri, 20 Oct 2023 13:17:23 GMT, Maurizio Cimadamore wrote: > This PR fixes a crash when jextract processes atomic types. These types are exposed in libclang in a weird way: their kind is set to `Atomic` but they do not reveal what the underlying type is (except for the type spelling). The underlying type has to be discovered using the `clang_Type_getValueType` function on the `Atomic` type. > > This PR does just that, and also adds a test for various atomic types. Marked as reviewed by jvernee (Committer). test/testng/org/openjdk/jextract/test/api/TestAtomic.java line 2: > 1: /* > 2: * Copyright (c) 2020, Oracle and/or its affiliates. All rights reserved. Wrong year Suggestion: * Copyright (c) 2023, Oracle and/or its affiliates. All rights reserved. test/testng/org/openjdk/jextract/test/api/atomic.h line 1: > 1: #include Missing header ------------- PR Review: https://git.openjdk.org/jextract/pull/132#pullrequestreview-1690590993 PR Review Comment: https://git.openjdk.org/jextract/pull/132#discussion_r1366971456 PR Review Comment: https://git.openjdk.org/jextract/pull/132#discussion_r1366971269 From jvernee at openjdk.org Fri Oct 20 18:10:08 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Fri, 20 Oct 2023 18:10:08 GMT Subject: RFR: Update GHA for jdk22 Message-ID: Update GHA to run on jdk 22. Also switched the gradle runner JDK to 17, since that is LTS with Oracle (which is where we get it from). ------------- Commit messages: - Fix mac JAVA path - Update for jdk 22 Changes: https://git.openjdk.org/jextract/pull/134/files Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=134&range=00 Stats: 16 lines in 1 file changed: 0 ins; 0 del; 16 mod Patch: https://git.openjdk.org/jextract/pull/134.diff Fetch: git fetch https://git.openjdk.org/jextract.git pull/134/head:pull/134 PR: https://git.openjdk.org/jextract/pull/134 From mcimadamore at openjdk.org Fri Oct 20 20:48:54 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 20 Oct 2023 20:48:54 GMT Subject: RFR: Update GHA for jdk22 In-Reply-To: References: Message-ID: On Fri, 20 Oct 2023 18:04:35 GMT, Jorn Vernee wrote: > Update GHA to run on jdk 22. Also switched the gradle runner JDK to 17, since that is LTS with Oracle (which is where we get it from). Marked as reviewed by mcimadamore (Committer). It seems like GHA on this PR has failed? ------------- PR Review: https://git.openjdk.org/jextract/pull/134#pullrequestreview-1690878918 PR Comment: https://git.openjdk.org/jextract/pull/134#issuecomment-1773371873 From mcimadamore at openjdk.org Fri Oct 20 20:48:56 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 20 Oct 2023 20:48:56 GMT Subject: RFR: Update GHA for jdk22 In-Reply-To: References: Message-ID: On Fri, 20 Oct 2023 20:45:18 GMT, Maurizio Cimadamore wrote: > It seems like GHA on this PR has failed? Two tests fail - although they were passing locally... anyway - this PR is good to go. ------------- PR Comment: https://git.openjdk.org/jextract/pull/134#issuecomment-1773372745 From mcimadamore at openjdk.org Fri Oct 20 20:52:56 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 20 Oct 2023 20:52:56 GMT Subject: RFR: (jdk22 port) 7903435: TestDocComments fails on Windows In-Reply-To: References: Message-ID: On Fri, 20 Oct 2023 16:37:54 GMT, Jorn Vernee wrote: > Port of https://github.com/openjdk/jextract/pull/106 for jdk 22 branch Marked as reviewed by mcimadamore (Committer). ------------- PR Review: https://git.openjdk.org/jextract/pull/133#pullrequestreview-1690885956 From mcimadamore at openjdk.org Fri Oct 20 20:52:57 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 20 Oct 2023 20:52:57 GMT Subject: Integrated: 7903573: Jextract does not support atomic types In-Reply-To: <2tmmqZi0zQgfs1kp04wkmO7ndKstXJ11vk9Olwo2HQA=.84fa5d3c-09a2-4fc3-a3a5-520dea1cc1a4@github.com> References: <2tmmqZi0zQgfs1kp04wkmO7ndKstXJ11vk9Olwo2HQA=.84fa5d3c-09a2-4fc3-a3a5-520dea1cc1a4@github.com> Message-ID: <9ybtUVHHLFy-ZmEaq304QEPF9jkc7IAhz0xsy5YV42A=.a9906990-b21a-4cdd-8c9f-1006c8f77840@github.com> On Fri, 20 Oct 2023 13:17:23 GMT, Maurizio Cimadamore wrote: > This PR fixes a crash when jextract processes atomic types. These types are exposed in libclang in a weird way: their kind is set to `Atomic` but they do not reveal what the underlying type is (except for the type spelling). The underlying type has to be discovered using the `clang_Type_getValueType` function on the `Atomic` type. > > This PR does just that, and also adds a test for various atomic types. This pull request has now been integrated. Changeset: 466fd8ff Author: Maurizio Cimadamore URL: https://git.openjdk.org/jextract/commit/466fd8ff5647a834e48cd19fbfcd3740555a28b1 Stats: 158 lines in 6 files changed: 158 ins; 0 del; 0 mod 7903573: Jextract does not support atomic types Reviewed-by: jvernee ------------- PR: https://git.openjdk.org/jextract/pull/132 From jvernee at openjdk.org Sat Oct 21 07:01:55 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Sat, 21 Oct 2023 07:01:55 GMT Subject: RFR: Update GHA for jdk22 In-Reply-To: References: Message-ID: On Fri, 20 Oct 2023 20:46:15 GMT, Maurizio Cimadamore wrote: > Two tests fail - although they were passing locally... anyway - this PR is good to go. Yes, two tests fail on mac. They're also passing locally on my machine. This needs to be investigated further. Any way, this PR is just to get GHA online. ------------- PR Comment: https://git.openjdk.org/jextract/pull/134#issuecomment-1773698120 From jvernee at openjdk.org Sat Oct 21 07:01:55 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Sat, 21 Oct 2023 07:01:55 GMT Subject: Integrated: Update GHA for jdk22 In-Reply-To: References: Message-ID: On Fri, 20 Oct 2023 18:04:35 GMT, Jorn Vernee wrote: > Update GHA to run on jdk 22. Also switched the gradle runner JDK to 17, since that is LTS with Oracle (which is where we get it from). This pull request has now been integrated. Changeset: fd3c42a1 Author: Jorn Vernee URL: https://git.openjdk.org/jextract/commit/fd3c42a1e9ba7855cb234158dd3608dc50d65d72 Stats: 16 lines in 1 file changed: 0 ins; 0 del; 16 mod Update GHA for jdk22 Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.org/jextract/pull/134 From jvernee at openjdk.org Sat Oct 21 07:03:54 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Sat, 21 Oct 2023 07:03:54 GMT Subject: Integrated: (jdk22 port) 7903435: TestDocComments fails on Windows In-Reply-To: References: Message-ID: On Fri, 20 Oct 2023 16:37:54 GMT, Jorn Vernee wrote: > Port of https://github.com/openjdk/jextract/pull/106 for jdk 22 branch This pull request has now been integrated. Changeset: 0aaf75cd Author: Jorn Vernee URL: https://git.openjdk.org/jextract/commit/0aaf75cdfe14df6f3a3f4e3d80f5384414a78ade Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod (jdk22 port) 7903435: TestDocComments fails on Windows Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.org/jextract/pull/133 From weijun at openjdk.org Sun Oct 22 12:37:10 2023 From: weijun at openjdk.org (Weijun Wang) Date: Sun, 22 Oct 2023 12:37:10 GMT Subject: RFR: 7903574: jextract should add lang=c to snippets containing C sources Message-ID: add the tag when snippet is generated. ------------- Commit messages: - 7903574: jextract should add lang=c to snippets containing C sources Changes: https://git.openjdk.org/jextract/pull/137/files Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=137&range=00 Issue: https://bugs.openjdk.org/browse/CODETOOLS-7903574 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jextract/pull/137.diff Fetch: git fetch https://git.openjdk.org/jextract.git pull/137/head:pull/137 PR: https://git.openjdk.org/jextract/pull/137 From mcimadamore at openjdk.org Mon Oct 23 10:11:01 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 23 Oct 2023 10:11:01 GMT Subject: RFR: 7903574: jextract should add lang=c to snippets containing C sources In-Reply-To: References: Message-ID: On Sun, 22 Oct 2023 12:31:56 GMT, Weijun Wang wrote: > add the tag when snippet is generated. Thanks! ------------- Marked as reviewed by mcimadamore (Committer). PR Review: https://git.openjdk.org/jextract/pull/137#pullrequestreview-1692171919 From weijun at openjdk.org Mon Oct 23 13:07:04 2023 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 23 Oct 2023 13:07:04 GMT Subject: Integrated: 7903574: jextract should add lang=c to snippets containing C sources In-Reply-To: References: Message-ID: On Sun, 22 Oct 2023 12:31:56 GMT, Weijun Wang wrote: > add the tag when snippet is generated. This pull request has now been integrated. Changeset: 6aad7d9a Author: Weijun Wang Committer: Maurizio Cimadamore URL: https://git.openjdk.org/jextract/commit/6aad7d9a77b727567c345c3b2e741fa5b6f304e9 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 7903574: jextract should add lang=c to snippets containing C sources Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.org/jextract/pull/137 From enatai at proton.me Sun Oct 29 17:22:04 2023 From: enatai at proton.me (Rel) Date: Sun, 29 Oct 2023 17:22:04 +0000 Subject: [External] : Re: debug logging In-Reply-To: References: <7a305085-c11c-6f4d-015d-8bf72f3a2de1@oracle.com> <8e72f1e9-d427-5181-1328-6e3411b2448a@oracle.com> Message-ID: Congrats on finally merging https://github.com/openjdk/jdk/pull/15103 :) I could build head of panama branch now and sent a changes here https://github.com/openjdk/jextract/pull/138 Regards, ------- Original Message ------- On Tuesday, August 29th, 2023 at 10:42 AM, Sundararajan Athijegannathan wrote: > Hi, > > There is no nightly build of "foreign-memaccess+abi". If you don't want to build JDK, I think you may want to wait for a future JDK 22 early access build ? > > Thanks, > -Sundar > > --------------------------------------------------------------- > > From: Rel > Sent: 29 August 2023 12:08 > To: Sundararajan Athijegannathan > Cc: Maurizio Cimadamore ; jextract-dev at openjdk.org > Subject: [External] : Re: debug logging > > Hi Sundar, > > Thanks for reply. > I suppose this means that I need to use "panama" branch for the MR? > > If so, do we have any nightly builds of "foreign-memaccess+abi"? The reason why I ask is that, it may really help me to focus on contributing to jextract rather than building OpenJDK from scratch :) Some Dockerfile with all build setup could help as well (so I then can just build OpenJDK and avoid preparing environment for that) > > Otherwise I possibly wait until next Java 22 early access build? > > Thank you, > > ------- Original Message ------- > On Monday, August 28th, 2023 at 4:22 AM, Sundararajan Athijegannathan wrote: > >> Hi, >> >> The "panama" branch of "jextract" repo is the bleeding edge code. You need to build "foreign-memaccess+abi" branch of [https://github.com/openjdk/panama-foreign](https://urldefense.com/v3/__https://github.com/openjdk/panama-foreign__;!!ACWV5N9M2RV99hQ!Pkg08TiIardCrx68xmpyPFVsYr-IejWPXxQ_5GH8A2tXaqarcBUVSbvwyRefWAq26nG2VxWCSTYv_YRh27LsSPIVkS187g$) and pass the built JDK for "jdk22_home" parameter for jextract Gradle build script. >> >> Hope this helps, >> -Sundar >> >> https://urldefense.com/v3/__https://github.com/openjdk/panama-foreign__;!!ACWV5N9M2RV99hQ!Pkg08TiIardCrx68xmpyPFVsYr-IejWPXxQ_5GH8A2tXaqarcBUVSbvwyRefWAq26nG2VxWCSTYv_YRh27LsSPIVkS187g$ [GitHub - openjdk/panama-foreign: https://openjdk.org/projects/panama](https://urldefense.com/v3/__https://github.com/openjdk/panama-foreign__;!!ACWV5N9M2RV99hQ!Pkg08TiIardCrx68xmpyPFVsYr-IejWPXxQ_5GH8A2tXaqarcBUVSbvwyRefWAq26nG2VxWCSTYv_YRh27LsSPIVkS187g$) >> https://openjdk.org/projects/panama. Contribute to openjdk/panama-foreign development by creating an account on GitHub. >> github.com >> >> --------------------------------------------------------------- >> >> From: jextract-dev on behalf of Rel >> Sent: 27 August 2023 06:53 >> To: Maurizio Cimadamore >> Cc: jextract-dev at openjdk.org >> Subject: Re: debug logging >> >> Thanks for reply and sharing the setup. >> >> I will keep tracing separately in my branch and will not include it as part of logging Merge Request. >> >> About MR: which branch should I use? >> >> I tried "panama" branch with latest changes but since we switched to Java 22 in commit "ca8942c Update jextract/panama branch to track JDK 22" the build start failing for me: >> >> jextract/src/main/java/org/openjdk/jextract/clang/Index.java:74: error: cannot find symbol >> MemorySegment src = arena.allocateFrom(file); >> ^ >> symbol: method allocateFrom(String) >> location: variable arena of type Arena >> >> Java is: >> >> java -version >> openjdk version "22-ea" 2024-03-19 >> OpenJDK Runtime Environment (build 22-ea+12-877) >> OpenJDK 64-Bit Server VM (build 22-ea+12-877, mixed mode, sharing) >> >> This is the latest from [https://jdk.java.net/22/](https://urldefense.com/v3/__https://jdk.java.net/22/__;!!ACWV5N9M2RV99hQ!Pkg08TiIardCrx68xmpyPFVsYr-IejWPXxQ_5GH8A2tXaqarcBUVSbvwyRefWAq26nG2VxWCSTYv_YRh27LsSPLO0H-bhA$) >> >> ------- Original Message ------- >> On Wednesday, August 23rd, 2023 at 12:22 PM, Maurizio Cimadamore wrote: >> >>> On 23/08/2023 02:45, Rel wrote: >>> >>> > > That said, I think it's important we identify the categories of events >>> > > that we are interested in logging. Logging clang parameters might be a >>> > > good idea. As for parsing, I'm not too much of a fan of logging every >>> > > single parsing event - as that would lead to very very long outputs. >>> > >>> > What do you think of: >>> > >>> > INFO - default mode, for everything where we use System.out >>> > SEVERE - default mode, for everything where we use System.err >>> > FINE - debug mode (clang parameters and some other useful logs) >>> > FINER - tracing mode (parsing events, and basically "what jextract wanted to do before it >>> > crashed" :). I understand the importance of not giving it to the users, so it will be available only >>> > to developers and would require to be manually enabled in logging.properties file first and then would require to build a new binary) >>> > >>> > Do you think JUL would be a right candidate for logging in jextract? >>> >>> The classification you propose, as well as using JUL as a starting point >>> doesn't seem too unreasonable. >>> >>> > > If my hunch is correct, I'd say that using a logger to allow for better >>> > > debuggability when extending jextract is not the best way to do things. >>> > > We should probably instead invest in making exceptions/errors more >>> > > meaningful >>> > >>> > Curious to hear what others think here. The reasons why I found "tracing mode" is important are: >>> > 1. Please correct me if I am wrong: as I see, the spirit of panama branch is to use most recent Java available out there (in fact it may not be even GA yet, like right now Java 22?). Because of that, it is most likely not to be supported by IDEs (jextract requires Java 22, Eclipse last time I checked supported only Java 20) >>> > - because of no IDE support, debugging in IDE seems not possible and so "tracing mode" can help here >>> >>> >>> I can run jextract/panama fine using IntelliJ - I have not tried with >>> Eclipse. >>> >>> But your comment confirms my suspicion that, rather than logging things >>> that are "interesting", we're basically trying to debug by println >>> statements :-) >>> >>> I obviously understand where you are coming from (you are just trying to >>> get things done) - but I'm not sure whetever level of finer logging we >>> add would ever be able to replace a debugger - I'd suggest to try and >>> use an IDE which works for your use case :-) >>> >>> (separately, as we have a gradle build to build jextract, how important >>> it is that Eclipse understands Java N ? Maybe you'll miss some >>> highlighting for the new features, but the rest should work? Or will >>> Eclipse categorically refuse to debug a class with a version number it >>> doesn't understand?) >>> >>> > 2. It helps to find what is wrong when use jextract for big projects (very very long outputs can be addressed with grep) >>> > >>> > How you debug jextract issues in panama branch now? And what would be the setup in this case (possibly such information is a good candidate for "jextract developer guide" later) so I can follow it >>> >>> >>> See above - I use IntelliJ and its Gradle integration. I'm able to build >>> fine. I have also installed the jtreg plugin: >>> >>> [https://github.com/openjdk/jtreg/tree/master/plugins/idea](https://urldefense.com/v3/__https://github.com/openjdk/jtreg/tree/master/plugins/idea__;!!ACWV5N9M2RV99hQ!Pkg08TiIardCrx68xmpyPFVsYr-IejWPXxQ_5GH8A2tXaqarcBUVSbvwyRefWAq26nG2VxWCSTYv_YRh27LsSPLDR_AqbQ$) >>> >>> Which allows me to run tests and debug them. >>> >>> Finally, I have defined some execution targets to run jextract against >>> some header files I've defined locally, to allow me to debug what happens. >>> >>> I'm pretty happy with this setup, and I feel quite productive with it. >>> >>> Hope this helps >>> Maurizio >>> >>> > ------- Original Message ------- >>> > On Monday, August 21st, 2023 at 2:09 PM, Maurizio Cimadamore maurizio.cimadamore at oracle.com wrote: >>> > >>> > > Hi, >>> > > I think adding better debugging capabilities to jextract is definitively >>> > > helpful. I agree that right now jextract tends to be on the quiet side. >>> > > >>> > > That said, I think it's important we identify the categories of events >>> > > that we are interested in logging. Logging clang parameters might be a >>> > > good idea. As for parsing, I'm not too much of a fan of logging every >>> > > single parsing event - as that would lead to very very long outputs. >>> > > >>> > > It almost seems like what you are looking for is some way to let >>> > > jextract print some more info about what it wanted to do before it >>> > > crashed. And I'm sure that this use case is mostly driven by the fact >>> > > that you are working to extend jextract as opposed to use it. >>> > > >>> > > If my hunch is correct, I'd say that using a logger to allow for better >>> > > debuggability when extending jextract is not the best way to do things. >>> > > We should probably instead invest in making exceptions/errors more >>> > > meaningful (I often wished I had a way to print the specific piece of C >>> > > header we were about to parse when some exception occurred). >>> > > >>> > > And logging should instead be used for user-facing events (e.g. which >>> > > headers are being parsed, which symbols are being excluded, which >>> > > classes are being written, etc.). >>> > > >>> > > An example of that is this: >>> > > >>> > > > - Sometime you receive "Failed to parse >>> > > > /tmp/jextract$1721579888733730008.h:" message, when you try to see >>> > > > contents of /tmp/jextract$1721579888733730008.h to understand why it >>> > > > is failed the file is already deleted. >>> > > >>> > > This is something a user should never see. E.g. if the user sees it - it >>> > > is a bug - and you don't want better logging you (as a jextract user) >>> > > just want it to be fixed. >>> > > >>> > > Maurizio -------------- next part -------------- An HTML attachment was scrubbed... URL: