On Wed, 3 Apr 2024 02:38:21 GMT, Julian Waters wrote:
>> Bumping
>
>> @TheShermanTanker I tried to help you get this done. I added fixes to a copy
>> of your branch on my personal fork, but then it turned out I could not push
>> them to your branch. :-(
>>
>> It ended up with me creating a new
On Fri, 5 Apr 2024 05:48:40 GMT, Julian Waters wrote:
>> Magnus Ihse Bursie has updated the pull request with a new target base due
>> to a merge or a rebase. The incremental webrev excludes the unrelated
>> changes brought in by the merge/rebase. The pull request contains two
>> additional co
On Thu, 4 Apr 2024 22:47:18 GMT, Magnus Ihse Bursie wrote:
>> This is a retake on https://github.com/openjdk/jdk/pull/15096.
>>
>> I tried to fix the remaining issues in that PR, but could not push them. In
>> the end, it seemed easier to create a new branch in my own personal fork.
>>
>> The
> This is a retake on https://github.com/openjdk/jdk/pull/15096.
>
> I tried to fix the remaining issues in that PR, but could not push them. In
> the end, it seemed easier to create a new branch in my own personal fork.
>
> The majority of the work in this PR has been done by @TheShermanTanker.
On Tue, 2 Apr 2024 15:45:59 GMT, Magnus Ihse Bursie wrote:
> This is a retake on https://github.com/openjdk/jdk/pull/15096.
>
> I tried to fix the remaining issues in that PR, but could not push them. In
> the end, it seemed easier to create a new branch in my own personal fork.
>
> The majori
On Wed, 3 Apr 2024 02:38:21 GMT, Julian Waters wrote:
> I will keep this open until the other Pull Request has been integrated, in
> case this might still be needed
I don't think it is necessary. You can always re-open a PR if it should be
needed, and you can look at source code and comments (
On Tue, 2 Apr 2024 15:45:59 GMT, Magnus Ihse Bursie wrote:
> This is a retake on https://github.com/openjdk/jdk/pull/15096.
>
> I tried to fix the remaining issues in that PR, but could not push them. In
> the end, it seemed easier to create a new branch in my own personal fork.
>
> The majori
On Mon, 1 Apr 2024 10:33:41 GMT, Julian Waters wrote:
>> Julian Waters has updated the pull request incrementally with four
>> additional commits since the last revision:
>>
>> - Labels to empty line in awt_Window.cpp
>> - Labels to empty line in awt_Window.cpp
>> - Label to empty line in aw
This is a retake on https://github.com/openjdk/jdk/pull/15096.
I tried to fix the remaining issues in that PR, but could not push them. In the
end, it seemed easier to create a new branch in my own personal fork.
The majority of the work in this PR has been done by @TheShermanTanker. I have
ste
On Mon, 1 Apr 2024 10:33:41 GMT, Julian Waters wrote:
>> Julian Waters has updated the pull request incrementally with four
>> additional commits since the last revision:
>>
>> - Labels to empty line in awt_Window.cpp
>> - Labels to empty line in awt_Window.cpp
>> - Label to empty line in aw
On Fri, 22 Mar 2024 12:26:25 GMT, Magnus Ihse Bursie wrote:
>> Julian Waters has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Revert Formatting in awt_Component.cpp
>> - Revert Formatting in awt_Window.cpp
>
> src/java.desktop/windows/
On Sat, 20 Jan 2024 00:38:04 GMT, Phil Race wrote:
>> Julian Waters has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 79 commits:
>>
>> - Merge branch 'openjdk:master' into patch-10
>> - Merge branch 'openjdk:master' into patch-10
On Thu, 28 Mar 2024 07:36:04 GMT, Julian Waters wrote:
>> We should set the -permissive- flag for the Microsoft Visual C compiler, as
>> was requested by the now backed out
>> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes
>> the Visual C compiler much less acceptin
On Thu, 28 Mar 2024 07:36:04 GMT, Julian Waters wrote:
>> We should set the -permissive- flag for the Microsoft Visual C compiler, as
>> was requested by the now backed out
>> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes
>> the Visual C compiler much less acceptin
On Thu, 28 Mar 2024 07:36:04 GMT, Julian Waters wrote:
>> We should set the -permissive- flag for the Microsoft Visual C compiler, as
>> was requested by the now backed out
>> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes
>> the Visual C compiler much less acceptin
On Thu, 28 Mar 2024 07:36:04 GMT, Julian Waters wrote:
>> We should set the -permissive- flag for the Microsoft Visual C compiler, as
>> was requested by the now backed out
>> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes
>> the Visual C compiler much less acceptin
On Sun, 21 Jan 2024 19:50:16 GMT, Phil Race wrote:
>> Fixed the formatting (at least in the marked cases), but am unsure what you
>> mean by set directly?
>
>> Fixed the formatting (at least in the marked cases), but am unsure what you
>> mean by set directly?
>
> See my comment
> "like in my
> We should set the -permissive- flag for the Microsoft Visual C compiler, as
> was requested by the now backed out
> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes
> the Visual C compiler much less accepting of ill formed code, which will
> improve code quality on W
> We should set the -permissive- flag for the Microsoft Visual C compiler, as
> was requested by the now backed out
> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes
> the Visual C compiler much less accepting of ill formed code, which will
> improve code quality on W
> We should set the -permissive- flag for the Microsoft Visual C compiler, as
> was requested by the now backed out
> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes
> the Visual C compiler much less accepting of ill formed code, which will
> improve code quality on W
> We should set the -permissive- flag for the Microsoft Visual C compiler, as
> was requested by the now backed out
> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes
> the Visual C compiler much less accepting of ill formed code, which will
> improve code quality on W
> We should set the -permissive- flag for the Microsoft Visual C compiler, as
> was requested by the now backed out
> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes
> the Visual C compiler much less accepting of ill formed code, which will
> improve code quality on W
On Wed, 27 Mar 2024 07:13:11 GMT, Julian Waters wrote:
>> We should set the -permissive- flag for the Microsoft Visual C compiler, as
>> was requested by the now backed out
>> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes
>> the Visual C compiler much less acceptin
> We should set the -permissive- flag for the Microsoft Visual C compiler, as
> was requested by the now backed out
> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes
> the Visual C compiler much less accepting of ill formed code, which will
> improve code quality on W
> We should set the -permissive- flag for the Microsoft Visual C compiler, as
> was requested by the now backed out
> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes
> the Visual C compiler much less accepting of ill formed code, which will
> improve code quality on W
> We should set the -permissive- flag for the Microsoft Visual C compiler, as
> was requested by the now backed out
> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes
> the Visual C compiler much less accepting of ill formed code, which will
> improve code quality on W
On Tue, 26 Mar 2024 20:03:36 GMT, Magnus Ihse Bursie wrote:
>> I see the advantage of collapsing self and parent into the same check, but
>> it doesn't seem like getting rid of pData is of much benefit, the checks for
>> null seem to remain the same either way
>
>> Sorry, I don't see a BOOL err
On Tue, 26 Mar 2024 08:55:56 GMT, Julian Waters wrote:
>> We should set the -permissive- flag for the Microsoft Visual C compiler, as
>> was requested by the now backed out
>> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes
>> the Visual C compiler much less acceptin
> We should set the -permissive- flag for the Microsoft Visual C compiler, as
> was requested by the now backed out
> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes
> the Visual C compiler much less accepting of ill formed code, which will
> improve code quality on W
On Tue, 26 Mar 2024 08:44:31 GMT, Julian Waters wrote:
> Maybe as a further improvement, I can inline
> THROW_NULL_PDATA_IF_NOT_DESTROYED at its callsites and replace the bad
> NullPointerException error message with the proper null pointer name. Since
> Phil isn't here, what do you think?
Th
On Wed, 20 Mar 2024 06:44:02 GMT, Julian Waters wrote:
>> Sorry, I don't see a BOOL error anywhere?
>
> I see the advantage of collapsing self and parent into the same check, but it
> doesn't seem like getting rid of pData is of much benefit, the checks for
> null seem to remain the same either
On Tue, 26 Mar 2024 08:55:56 GMT, Julian Waters wrote:
>> We should set the -permissive- flag for the Microsoft Visual C compiler, as
>> was requested by the now backed out
>> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes
>> the Visual C compiler much less acceptin
> We should set the -permissive- flag for the Microsoft Visual C compiler, as
> was requested by the now backed out
> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes
> the Visual C compiler much less accepting of ill formed code, which will
> improve code quality on W
> We should set the -permissive- flag for the Microsoft Visual C compiler, as
> was requested by the now backed out
> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes
> the Visual C compiler much less accepting of ill formed code, which will
> improve code quality on W
On Tue, 26 Mar 2024 07:44:22 GMT, Magnus Ihse Bursie wrote:
> > I have a concern since the null check bailout involves
> > THROW_NULL_PDATA_IF_NOT_DESTROYED, which is no longer accurate if we remove
> > the pData local.
>
> The name of the macro is not great, but it does not involve pData (the
> We should set the -permissive- flag for the Microsoft Visual C compiler, as
> was requested by the now backed out
> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes
> the Visual C compiler much less accepting of ill formed code, which will
> improve code quality on W
> We should set the -permissive- flag for the Microsoft Visual C compiler, as
> was requested by the now backed out
> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes
> the Visual C compiler much less accepting of ill formed code, which will
> improve code quality on W
On Tue, 26 Mar 2024 00:13:09 GMT, Julian Waters wrote:
> I have a concern since the null check bailout involves
> THROW_NULL_PDATA_IF_NOT_DESTROYED, which is no longer accurate if we remove
> the pData local.
The name of the macro is not great, but it does not involve pData (the bad NPE
error
On Tue, 26 Mar 2024 00:17:56 GMT, Julian Waters wrote:
>> We should set the -permissive- flag for the Microsoft Visual C compiler, as
>> was requested by the now backed out
>> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes
>> the Visual C compiler much less acceptin
> We should set the -permissive- flag for the Microsoft Visual C compiler, as
> was requested by the now backed out
> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes
> the Visual C compiler much less accepting of ill formed code, which will
> improve code quality on W
On Mon, 25 Mar 2024 09:02:22 GMT, Magnus Ihse Bursie wrote:
> > The only thing I'm uncertain about is the pData local, which I don't see
> > much benefit in removing since the null check associated with it still has
> > to remain for code semantics to be correct
>
> The point is that you can d
> We should set the -permissive- flag for the Microsoft Visual C compiler, as
> was requested by the now backed out
> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes
> the Visual C compiler much less accepting of ill formed code, which will
> improve code quality on W
> We should set the -permissive- flag for the Microsoft Visual C compiler, as
> was requested by the now backed out
> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes
> the Visual C compiler much less accepting of ill formed code, which will
> improve code quality on W
> We should set the -permissive- flag for the Microsoft Visual C compiler, as
> was requested by the now backed out
> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes
> the Visual C compiler much less accepting of ill formed code, which will
> improve code quality on W
On Mon, 25 Mar 2024 08:59:08 GMT, Magnus Ihse Bursie wrote:
>> I don't think I can commit this as there are 3 backticks at the end there :P
>
> Apologies. The point was that this was formatting changes that were not
> needed and should be reverted.
I know, I did want to commit your change direc
On Mon, 25 Mar 2024 05:56:52 GMT, Julian Waters wrote:
> The only thing I'm uncertain about is the pData local, which I don't see much
> benefit in removing since the null check associated with it still has to
> remain for code semantics to be correct
The point is that you can do the null chec
On Mon, 25 Mar 2024 05:58:41 GMT, Julian Waters wrote:
>> src/java.desktop/windows/native/libawt/windows/awt_PrintJob.cpp line 1230:
>>
>>> 1228: jdouble imgY = (jdouble) ((yPixelOrg * 72)/(jdouble) yPixelRes);
>>> 1229: jdouble imgWid = (jdouble) ((imgPixelWid * 72)/(jdouble)
>>> xPixe
On Fri, 22 Mar 2024 12:27:31 GMT, Magnus Ihse Bursie wrote:
>> Julian Waters has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Revert Formatting in awt_Component.cpp
>> - Revert Formatting in awt_Window.cpp
>
> src/java.desktop/windows/
On Wed, 20 Mar 2024 06:38:59 GMT, Julian Waters wrote:
>> We should set the -permissive- flag for the Microsoft Visual C compiler, as
>> was requested by the now backed out
>> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes
>> the Visual C compiler much less acceptin
> We should set the -permissive- flag for the Microsoft Visual C compiler, as
> was requested by the now backed out
> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes
> the Visual C compiler much less accepting of ill formed code, which will
> improve code quality on W
On Fri, 22 Mar 2024 10:49:13 GMT, Julian Waters wrote:
>> bot-keep-alive
>>
>> @TheShermanTanker Did you understand the remaining changes that Phil has
>> requested? Do you think you'll be able to fix this?
>
> @magicus Phil doesn't seem to be responding to my queries, I'm not too sure
> what
On Sat, 20 Jan 2024 00:40:40 GMT, Phil Race wrote:
>> Julian Waters has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 79 commits:
>>
>> - Merge branch 'openjdk:master' into patch-10
>> - Merge branch 'openjdk:master' into patch-10
On Fri, 3 Nov 2023 02:39:26 GMT, Julian Waters wrote:
>> src/java.desktop/windows/native/libawt/windows/awt_PrintJob.cpp line 61:
>>
>>> 59:
>>> 60: jfieldID AwtPrintDialog::pageID;
>>> 61:
>>
>> where and why did this come from ?
>
> This came from below, all I did was move it up and out of
On Sat, 20 Jan 2024 00:32:19 GMT, Phil Race wrote:
>> Julian Waters has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 79 commits:
>>
>> - Merge branch 'openjdk:master' into patch-10
>> - Merge branch 'openjdk:master' into patch-10
On Sun, 3 Dec 2023 15:37:47 GMT, Julian Waters wrote:
>> src/java.desktop/windows/native/libawt/windows/awt_Frame.cpp line 1641:
>>
>>> 1639: }
>>> 1640: }
>>> 1641:
>>
>> A possible improvement later (and for a future RFE) would be to use RAII for
>> deletion and then get rid of
On Wed, 20 Mar 2024 06:38:59 GMT, Julian Waters wrote:
>> We should set the -permissive- flag for the Microsoft Visual C compiler, as
>> was requested by the now backed out
>> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes
>> the Visual C compiler much less acceptin
On Mon, 18 Mar 2024 15:55:15 GMT, Magnus Ihse Bursie wrote:
>> Julian Waters has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 84 commits:
>>
>> - Merge branch 'openjdk:master' into patch-10
>> - awt_Window.cpp
>> - awt_Frame.cpp
On Sun, 21 Jan 2024 19:50:16 GMT, Phil Race wrote:
>> Fixed the formatting (at least in the marked cases), but am unsure what you
>> mean by set directly?
>
>> Fixed the formatting (at least in the marked cases), but am unsure what you
>> mean by set directly?
>
> See my comment
> "like in my
On Mon, 18 Mar 2024 15:55:15 GMT, Magnus Ihse Bursie wrote:
> bot-keep-alive
>
> @TheShermanTanker Did you understand the remaining changes that Phil has
> requested? Do you think you'll be able to fix this?
Hi Magnus, yes I do plan on fixing this. I've just been a bit busy and tired is
all,
On Wed, 20 Mar 2024 06:22:50 GMT, Julian Waters wrote:
>> src/java.desktop/windows/native/libawt/windows/awt_Component.cpp line 6366:
>>
>>> 6364: jobject parent = data->parentComp;
>>> 6365:
>>> 6366: AwtComponent *awtComponent = nullptr;
>>
>> Looking at it (not tested) here
> We should set the -permissive- flag for the Microsoft Visual C compiler, as
> was requested by the now backed out
> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes
> the Visual C compiler much less accepting of ill formed code, which will
> improve code quality on W
> We should set the -permissive- flag for the Microsoft Visual C compiler, as
> was requested by the now backed out
> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes
> the Visual C compiler much less accepting of ill formed code, which will
> improve code quality on W
On Sat, 20 Jan 2024 00:17:02 GMT, Phil Race wrote:
>> Julian Waters has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 79 commits:
>>
>> - Merge branch 'openjdk:master' into patch-10
>> - Merge branch 'openjdk:master' into patch-10
On Sun, 21 Jan 2024 07:58:11 GMT, Julian Waters wrote:
>> We should set the -permissive- flag for the Microsoft Visual C compiler, as
>> was requested by the now backed out
>> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes
>> the Visual C compiler much less acceptin
On Sun, 21 Jan 2024 07:58:11 GMT, Julian Waters wrote:
>> We should set the -permissive- flag for the Microsoft Visual C compiler, as
>> was requested by the now backed out
>> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes
>> the Visual C compiler much less acceptin
On Sun, 21 Jan 2024 07:55:16 GMT, Julian Waters wrote:
> Fixed the formatting (at least in the marked cases), but am unsure what you
> mean by set directly?
See my comment
"like in my recoded case above, we no longer need the "pData" var which was
there only because that name
is magically kno
> We should set the -permissive- flag for the Microsoft Visual C compiler, as
> was requested by the now backed out
> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes
> the Visual C compiler much less accepting of ill formed code, which will
> improve code quality on W
> We should set the -permissive- flag for the Microsoft Visual C compiler, as
> was requested by the now backed out
> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes
> the Visual C compiler much less accepting of ill formed code, which will
> improve code quality on W
On Sun, 21 Jan 2024 07:55:13 GMT, Julian Waters wrote:
>> We should set the -permissive- flag for the Microsoft Visual C compiler, as
>> was requested by the now backed out
>> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes
>> the Visual C compiler much less acceptin
> We should set the -permissive- flag for the Microsoft Visual C compiler, as
> was requested by the now backed out
> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes
> the Visual C compiler much less accepting of ill formed code, which will
> improve code quality on W
> We should set the -permissive- flag for the Microsoft Visual C compiler, as
> was requested by the now backed out
> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes
> the Visual C compiler much less accepting of ill formed code, which will
> improve code quality on W
On Thu, 11 Jan 2024 08:24:42 GMT, Julian Waters wrote:
>> We should set the -permissive- flag for the Microsoft Visual C compiler, as
>> was requested by the now backed out
>> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes
>> the Visual C compiler much less acceptin
On Thu, 16 Nov 2023 03:44:53 GMT, Phil Race wrote:
>> I happened to ask around on the build-dev mailing lists about whether we
>> include msvcp.dll with the JDK, here is Erik's response:
>>
>>> Back in JDK 8 when we used Visual Studio 2010, we used to not ship
>>> msvcp*.dll. This changed when
On Thu, 11 Jan 2024 12:11:17 GMT, Magnus Ihse Bursie wrote:
> What is remaining to get this PR committable? It has such a long history that
> it is hard to get a grasp on the remaining issues.
>
> @TheShermanTanker Could you perhaps summarize the remaining hurdles?
It's largely complete by now
On Thu, 11 Jan 2024 08:24:42 GMT, Julian Waters wrote:
>> We should set the -permissive- flag for the Microsoft Visual C compiler, as
>> was requested by the now backed out
>> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes
>> the Visual C compiler much less acceptin
On Mon, 4 Dec 2023 09:39:09 GMT, Julian Waters wrote:
>> We should set the -permissive- flag for the Microsoft Visual C compiler, as
>> was requested by the now backed out
>> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes
>> the Visual C compiler much less accepting
> We should set the -permissive- flag for the Microsoft Visual C compiler, as
> was requested by the now backed out
> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes
> the Visual C compiler much less accepting of ill formed code, which will
> improve code quality on W
On Mon, 4 Dec 2023 09:39:09 GMT, Julian Waters wrote:
>> We should set the -permissive- flag for the Microsoft Visual C compiler, as
>> was requested by the now backed out
>> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes
>> the Visual C compiler much less accepting
On Mon, 4 Dec 2023 11:33:09 GMT, Julian Waters wrote:
>> make/autoconf/flags-cflags.m4 line 565:
>>
>>> 563: # The -utf-8 option sets source and execution character sets to
>>> UTF-8 to enable correct
>>> 564: # compilation of all source files regardless of the active code
>>> page on
On Mon, 4 Dec 2023 11:29:07 GMT, Magnus Ihse Bursie wrote:
>> Julian Waters has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 78 commits:
>>
>> - Merge branch 'openjdk:master' into patch-10
>> - Fix awt_Window.cpp
>> - Fix awt_Pr
On Mon, 4 Dec 2023 09:39:09 GMT, Julian Waters wrote:
>> We should set the -permissive- flag for the Microsoft Visual C compiler, as
>> was requested by the now backed out
>> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes
>> the Visual C compiler much less accepting
On Mon, 4 Dec 2023 09:39:09 GMT, Julian Waters wrote:
>> We should set the -permissive- flag for the Microsoft Visual C compiler, as
>> was requested by the now backed out
>> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes
>> the Visual C compiler much less accepting
> We should set the -permissive- flag for the Microsoft Visual C compiler, as
> was requested by the now backed out
> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes
> the Visual C compiler much less accepting of ill formed code, which will
> improve code quality on W
On Tue, 10 Oct 2023 03:44:27 GMT, Julian Waters wrote:
>> We should set the -permissive- flag for the Microsoft Visual C compiler, as
>> was requested by the now backed out
>> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes
>> the Visual C compiler much less acceptin
On Tue, 10 Oct 2023 03:44:27 GMT, Julian Waters wrote:
>> We should set the -permissive- flag for the Microsoft Visual C compiler, as
>> was requested by the now backed out
>> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes
>> the Visual C compiler much less acceptin
85 matches
Mail list logo
