On Tue, 10 Jan 2023 22:44:21 GMT, Sergey Bylokhov wrote:
> Hi all,
> This pull request contains a backport of commit
> [c8a8388a](https://github.com/openjdk/jdk/commit/c8a8388aba3dc121bad04aaa123f6cd7525c3d38)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> The commit being
On Fri, 13 Jan 2023 00:57:14 GMT, Archie L. Cobbs wrote:
>> Ok - I thought false negative was the thing to absolutely avoid - and that
>> was the no. 1 concern. I think a possible approach to keep both the
>> filtering and the code more or less similar to what you have, is to save the
>> type
> This PR adds a new lint warning category `this-escape`.
>
> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to
> allow the JDK to continue to compile with `-Xlint:all`.
>
> A 'this' escape warning is generated for a constructor `A()` in a class `A`
> when the
On Fri, 13 Jan 2023 13:34:08 GMT, David wrote:
>> This patch adds the `-headerpad_max_install_names` linker argument to the
>> build of the `jpackageapplauncher` binary (osx only)
>>
>> Adding this argument allows the user to use the `install_name_tool` to add
>> search paths for the dynamic
On Fri, 13 Jan 2023 21:33:02 GMT, Archie L. Cobbs wrote:
>> Sounds good - thanks.
>
> Ah. I just realized that we need to do it your way because of the following
> bug:
>
> Suppose you have a constructor and a field with initializer that both leak,
> but you have
On Fri, 13 Jan 2023 00:32:36 GMT, Magnus Ihse Bursie wrote:
> Hm. I fully agree on the problem description, but not entirely sure about
> this solution. In contrast with Erik, I was more thinking along the lines
> that the decision to be more quiet could be made by SetupNativeCompilation
>
On Tue, 10 Jan 2023 09:57:19 GMT, David wrote:
> This patch adds the `-headerpad_max_install_names` linker argument to the
> build of the `jpackageapplauncher` binary (osx only)
>
> Adding this argument allows the user to use the `install_name_tool` to add
> search paths for the dynamic
On Fri, 13 Jan 2023 16:20:41 GMT, Archie L. Cobbs wrote:
>> I'm OK either way we can revisit this later either as part of this PR or in
>> a future one. I let it to your consideration
>
> Sounds good - thanks.
Ah. I just realized that we need to do it your way because of the following bug:
On Fri, 13 Jan 2023 20:21:24 GMT, Vicente Romero wrote:
>> Archie L. Cobbs has updated the pull request incrementally with three
>> additional commits since the last revision:
>>
>> - Use more idiomatic test for java.lang.Object.
>> - Revert 27cb30129; the error was actually fixed in
On Fri, 13 Jan 2023 20:16:25 GMT, Vicente Romero wrote:
>> Archie L. Cobbs has updated the pull request incrementally with three
>> additional commits since the last revision:
>>
>> - Use more idiomatic test for java.lang.Object.
>> - Revert 27cb30129; the error was actually fixed in
On Fri, 13 Jan 2023 19:09:54 GMT, Archie L. Cobbs wrote:
>> This PR adds a new lint warning category `this-escape`.
>>
>> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to
>> allow the JDK to continue to compile with `-Xlint:all`.
>>
>> A 'this' escape warning is
On Fri, 13 Jan 2023 19:09:54 GMT, Archie L. Cobbs wrote:
>> This PR adds a new lint warning category `this-escape`.
>>
>> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to
>> allow the JDK to continue to compile with `-Xlint:all`.
>>
>> A 'this' escape warning is
On Fri, 13 Jan 2023 17:49:05 GMT, Archie L. Cobbs wrote:
>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java
>> line 685:
>>
>>> 683:
>>> 684: @Override
>>> 685: public void visitDoLoop(JCDoWhileLoop tree) {
>>
>> I was thinking, code can also loop
> This PR adds a new lint warning category `this-escape`.
>
> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to
> allow the JDK to continue to compile with `-Xlint:all`.
>
> A 'this' escape warning is generated for a constructor `A()` in a class `A`
> when the
On Tue, 10 Jan 2023 09:57:19 GMT, David wrote:
> This patch adds the `-headerpad_max_install_names` linker argument to the
> build of the `jpackageapplauncher` binary (osx only)
>
> Adding this argument allows the user to use the `install_name_tool` to add
> search paths for the dynamic
On Fri, 13 Jan 2023 17:35:08 GMT, Vicente Romero wrote:
>> Archie L. Cobbs has updated the pull request incrementally with 16
>> additional commits since the last revision:
>>
>> - Fix bug where all but the last yeild statement were being ignored.
>> - Add method RefSet.mapInto() and use to
On Fri, 13 Jan 2023 04:04:36 GMT, Archie L. Cobbs wrote:
>> This PR adds a new lint warning category `this-escape`.
>>
>> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to
>> allow the JDK to continue to compile with `-Xlint:all`.
>>
>> A 'this' escape warning is
> This is an enhancement of the test case in
> [JDK-8296754](https://bugs.openjdk.org/browse/JDK-8296754), which tests
> against an archive created by the "boot JDK", which is usually set as the
> previous official JDK release when building the JDK repo.
>
> If it's able to acquire previous
On Fri, 13 Jan 2023 16:12:50 GMT, Vicente Romero wrote:
>> Yes... I did it that way is so that it doesn't require any adaptation
>> if/when JDK-8194743 ever gets implemented. And it keeps the code a little
>> simpler in exchange for a little redundancy.
>>
>> I'm happy to fix this if you
On Fri, 13 Jan 2023 16:06:04 GMT, Maurizio Cimadamore
wrote:
>>> Something seems to be up with the lint description for this-escape -
>>> compare this:
>>
>> Oops, will fix - thanks.
>
>> The decision was to go with drawing the "warning boundary" at the
>> compilation unit. The reasoning is
On Fri, 13 Jan 2023 15:14:05 GMT, Archie L. Cobbs wrote:
>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java
>> line 516:
>>
>>> 514: Name name = TreeInfo.name(invoke.meth);
>>> 515: if (name == names._super) {
>>> 516:
On Fri, 13 Jan 2023 15:08:59 GMT, Archie L. Cobbs wrote:
>>> I guess I was confused because, while subclasses are a particularly sneaky
>>> case where uninitialized values can show up, the above leak seems
>>> potentially dangerous as well...
>>
>> Yes - and this very question did come up in
There are several configure settings that should have different default values
depending on if configure is run as part of a CI build, or a local developer.
We should have a `--with-build-env=ci/dev` argument that lets you chose such
build environment. Furthermore, configure should look for the
On Fri, 13 Jan 2023 12:42:24 GMT, Vicente Romero wrote:
>> Archie L. Cobbs has updated the pull request incrementally with 16
>> additional commits since the last revision:
>>
>> - Fix bug where all but the last yeild statement were being ignored.
>> - Add method RefSet.mapInto() and use to
On Thu, 12 Jan 2023 18:01:50 GMT, Coleen Phillimore wrote:
>> This change makes native output files be only printed when building with
>> LOG=info, to make the build not have so many pages of output.
>> Tested with GHA and locally (tbd)
>
> Coleen Phillimore has updated the pull request
On Fri, 13 Jan 2023 15:08:43 GMT, Archie L. Cobbs wrote:
>> Something seems to be up with the lint description for this-escape - compare
>> this:
>>
>>
>> serial Warn about Serializable classes that do not have a
>> serialVersionUID field.
>> Also
On Fri, 13 Jan 2023 11:08:33 GMT, Maurizio Cimadamore
wrote:
>> Perhaps my confusion might come from the name `this-escape` of the lint
>> warning - which seems overpromising in this respect. But I looked at the
>> description of the lint warning using `javac --help-lint` and I got this:
>>
On Fri, 13 Jan 2023 04:04:36 GMT, Archie L. Cobbs wrote:
>> This PR adds a new lint warning category `this-escape`.
>>
>> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to
>> allow the JDK to continue to compile with `-Xlint:all`.
>>
>> A 'this' escape warning is
On Thu, 12 Jan 2023 18:57:41 GMT, Justin King wrote:
>> make/autoconf/jdk-options.m4 line 480:
>>
>>> 478: LDFLAGS_JDKEXE="$LDFLAGS_JDKEXE $UBSAN_LDFLAGS"
>>> 479: ])
>>> 480: if test "x$UBSAN_ENABLED" = xfalse; then
>>
>> You don't have to explicitly declare variables empty; I
On Fri, 13 Jan 2023 04:10:16 GMT, Jie Fu wrote:
> Hi all,
>
> Configuration is broken in dockers after JDK-8296478.
> This is because `$USER` is not defined in dockers [1].
>
> The fix will check `whoami` if we get an empty `$USERNAME`.
>
> Thanks.
> Best regards,
> Jie
>
> [1]
>
On Fri, 13 Jan 2023 04:10:16 GMT, Jie Fu wrote:
> Hi all,
>
> Configuration is broken in dockers after JDK-8296478.
> This is because `$USER` is not defined in dockers [1].
>
> The fix will check `whoami` if we get an empty `$USERNAME`.
>
> Thanks.
> Best regards,
> Jie
>
> [1]
>
On Fri, 13 Jan 2023 04:10:16 GMT, Jie Fu wrote:
> Hi all,
>
> Configuration is broken in dockers after JDK-8296478.
> This is because `$USER` is not defined in dockers [1].
>
> The fix will check `whoami` if we get an empty `$USERNAME`.
>
> Thanks.
> Best regards,
> Jie
>
> [1]
>
On Fri, 13 Jan 2023 13:22:12 GMT, Magnus Ihse Bursie wrote:
> To be clear: If you are missing both $USER and `whoami`, and are not
> explicitly setting a user name, configure should fail. But if you are missing
> this and are using `--with-build-user`, then it succeeds.
Yes, it behaves like
On Tue, 10 Jan 2023 09:57:19 GMT, David wrote:
> This patch adds the `-headerpad_max_install_names` linker argument to the
> build of the `jpackageapplauncher` binary (osx only)
>
> Adding this argument allows the user to use the `install_name_tool` to add
> search paths for the dynamic
On Tue, 10 Jan 2023 09:57:19 GMT, David wrote:
> This patch adds the `-headerpad_max_install_names` linker argument to the
> build of the `jpackageapplauncher` binary (osx only)
>
> Adding this argument allows the user to use the `install_name_tool` to add
> search paths for the dynamic
On Tue, 10 Jan 2023 09:57:19 GMT, David wrote:
> This patch adds the `-headerpad_max_install_names` linker argument to the
> build of the `jpackageapplauncher` binary (osx only)
>
> Adding this argument allows the user to use the `install_name_tool` to add
> search paths for the dynamic
On Fri, 13 Jan 2023 04:10:16 GMT, Jie Fu wrote:
> Hi all,
>
> Configuration is broken in dockers after JDK-8296478.
> This is because `$USER` is not defined in dockers [1].
>
> The fix will check `whoami` if we get an empty `$USERNAME`.
>
> Thanks.
> Best regards,
> Jie
>
> [1]
>
On Tue, 10 Jan 2023 22:59:20 GMT, Alexander Matveev
wrote:
> What additional paths except "@executable_path/../Frameworks/" your
> application requires? If you just need @executable_path/../Frameworks/, then
> I think we should just add this to rpath permanently, instead of using
>
This patch adds the `-headerpad_max_install_names` linker argument to the build
of the `jpackageapplauncher` binary (osx only)
Adding this argument allows the user to use the `install_name_tool` to add
search paths for the dynamic linker to the launcher binary. This is required
for certain use
On Fri, 13 Jan 2023 11:05:51 GMT, Maurizio Cimadamore
wrote:
>> So, to clarify, in this case:
>>
>>
>> import java.util.*;
>>
>> class B {
>> final Object ref;
>>
>> private B(Object ref) {
>> Foo.consume(this);
>> this.ref = ref;
>> }
>> }
>>
>>
>>
On Fri, 13 Jan 2023 10:58:33 GMT, Maurizio Cimadamore
wrote:
>> Caring about the proper initialization of any class in the _current_
>> compilation unit is an explicit non-goal.
>>
>> We only care about bugs where a superclass and subclass are in separate
>> compilation units.
>
> So, to
On Thu, 12 Jan 2023 21:04:09 GMT, Archie L. Cobbs wrote:
>> but what if `m` is a static method in a separate compilation unit? Should it
>> be able to observe a partially initialized Foo?
>
> Caring about the proper initialization of any class in the _current_
> compilation unit is an explicit
On Fri, 13 Jan 2023 04:10:16 GMT, Jie Fu wrote:
> Hi all,
>
> Configuration is broken in dockers after JDK-8296478.
> This is because `$USER` is not defined in dockers [1].
>
> The fix will check `whoami` if we get an empty `$USERNAME`.
>
> Thanks.
> Best regards,
> Jie
>
> [1]
>
On Thu, 12 Jan 2023 20:36:31 GMT, Justin King wrote:
>> The implementation of `offset_of` for GCC/Clang only deals with types are
>> aligned to 16 bytes or less, if they are more, such as `zCollectedHeap` the
>> behavior is undefined. UBSan also suggests that `offset_of` is not always a
>>
On Fri, 13 Jan 2023 08:14:20 GMT, Christoph Langer wrote:
>> Julian Waters has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Move shell env call to build-windows.yml
>
> Regarding the tar issue: It happens in the post steps, when GHA does
On Thu, 12 Jan 2023 20:28:50 GMT, Justin King wrote:
> The implementation of `offset_of` for GCC/Clang only deals with types are
> aligned to 16 bytes or less, if they are more, such as `zCollectedHeap` the
> behavior is undefined. UBSan also suggests that `offset_of` is not always a
>
On Thu, 12 Jan 2023 20:28:50 GMT, Justin King wrote:
> The implementation of `offset_of` for GCC/Clang only deals with types are
> aligned to 16 bytes or less, if they are more, such as `zCollectedHeap` the
> behavior is undefined. UBSan also suggests that `offset_of` is not always a
>
On Thu, 12 Jan 2023 14:28:54 GMT, Julian Waters wrote:
>> MSYS2 should be more appropriately installed into the runner's temporary
>> directory rather than inside the newly checked out repository containing all
>> the JDK's source code, as doing so may interfere with the build process and
>>
48 matches
Mail list logo
