Please review several fixes and improvements to the `this-escape` lint warning
analyzer.
The goal here is to apply some relatively simple logical fixes that improve the
precision and accuracy of the analyzer, and capture the remaining low-hanging
fruit so we can consider the analyzer relatively
On Wed, 20 Dec 2023 09:03:34 GMT, Daniel Fuchs wrote:
> I assume these were the reason why this-escape analysis had been disabled on
> java.net.http, and I expect the reason why the analysis can be reenabled by
> default is because of point 3 above?
No, the goal here is simply to remove unnece
nce.
>
> In other words, we should be treating "via an outer instance" as just another
> flavor of indirection along with "direct" and "indirect".
>
> As a result, with this patch the `OuterRef` class goes away and a new
> `Indirection` enum has been
nce.
>
> In other words, we should be treating "via an outer instance" as just another
> flavor of indirection along with "direct" and "indirect".
>
> As a result, with this patch the `OuterRef` class goes away and a new
> `Indirection` enum has been
nce.
>
> In other words, we should be treating "via an outer instance" as just another
> flavor of indirection along with "direct" and "indirect".
>
> As a result, with this patch the `OuterRef` class goes away and a new
> `Indirection` enum has been
nce.
>
> In other words, we should be treating "via an outer instance" as just another
> flavor of indirection along with "direct" and "indirect".
>
> As a result, with this patch the `OuterRef` class goes away and a new
> `Indirection` enum has been
On Tue, 16 Apr 2024 18:00:50 GMT, Vicente Romero wrote:
>> Archie Cobbs has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains eight commits:
>>
>> - Merge branch 'master' into JDK-8317376
>>
On Mon, 16 Oct 2023 22:08:53 GMT, Archie Cobbs wrote:
> Please review several fixes and improvements to the `this-escape` lint
> warning analyzer.
>
> The goal here is to apply some relatively simple logical fixes that improve
> the precision and accuracy of the analyzer,
On Sun, 3 Nov 2024 03:17:14 GMT, Archie Cobbs wrote:
>> Please review this patch which removes unnecessary `@SuppressWarnings`
>> annotations and `-Xlint:-foo` options.
>
> Archie Cobbs has updated the pull request with a new target base due to a
> merge or a rebase. T
On Sat, 2 Nov 2024 16:23:34 GMT, Archie Cobbs wrote:
> Please review this patch which removes unnecessary `@SuppressWarnings`
> annotations and `-Xlint:-foo` options.
This pull request has now been integrated.
Changeset: c799cad1
Author:Archie Cobbs
URL:
https://git.openj
On Tue, 5 Nov 2024 16:42:17 GMT, Magnus Ihse Bursie wrote:
> Eh... I tried to say that I had only reviewed part of this PR. Maybe I should
> have made that clearer by bumping the number of required reviewers as well; I
> usually do that but I forgot it this time.
Argh, sorry... I was just blin
Please review this patch which removes unnecessary `@SuppressWarnings`
annotations and `-Xlint:-foo` options.
-
Commit messages:
- Remove unnecessary @SuppressWarnings annotations and -Xlint:-key flags.
Changes: https://git.openjdk.org/jdk/pull/21859/files
Webrev: https://webrevs
Please review this patch which removes unnecessary `@SuppressWarnings`
annotations.
-
Commit messages:
- Merge branch 'master' into SuppressWarningsCleanup-compiler
- Apply change that was missed somehow.
- Undo change that will be moved to the core-libs branch.
- Remove unnecess
Please review this patch which removes unnecessary `@SuppressWarnings`
annotations.
-
Commit messages:
- Remove unnecessary @SuppressWarnings annotations.
Changes: https://git.openjdk.org/jdk/pull/21852/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21852&range=00
Issue
> Please review this patch which removes unnecessary `@SuppressWarnings`
> annotations.
Archie Cobbs 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 co
> Please review this patch which removes unnecessary `@SuppressWarnings`
> annotations.
Archie Cobbs 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 co
> Please review this patch which removes unnecessary `@SuppressWarnings`
> annotations and `-Xlint:-foo` options.
Archie Cobbs 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/
On Thu, 5 Dec 2024 14:34:29 GMT, Jan Lahoda wrote:
> we probably need something that will avoid running the lint's code completely
> in a (semi-)automatic way. That could be part of a more generic 22088.
Agreed.
Slight comment hijack follows...
The [unnecessary suppression warning
proposal](
On Wed, 4 Dec 2024 17:11:26 GMT, Maurizio Cimadamore
wrote:
> This PR tightens up the logic by which javac reports lint warnings.
> Currently, lint warnings are typically emitted using the following idiom:
>
>
> if (lint.isEnabled(LintCategory.DIVZERO) {
> log.warning(LintCategory.DIVZERO
On Thu, 5 Dec 2024 22:08:48 GMT, Vicente Romero wrote:
>> Maurizio Cimadamore has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Add missing lint categories in compiler.properties
>> Simplify some lambda expressions
>> Simplify Lint::lo
On Mon, 16 Dec 2024 19:21:54 GMT, Archie Cobbs wrote:
>> Please review this fix for an incorrect `lint:` tag in
>> `compiler.properties`, plus an adjustment to the build process to
>> automatically detect and fail the build in case of any similar typos in the
>> futu
Please review this fix for an incorrect `lint:` tag in `compiler.properties`,
plus an adjustment to the build process to automatically detect and fail the
build in case of any similar typos in the future.
-
Commit messages:
- Fix invalid "lint" tag and update build to automatically
On Mon, 16 Dec 2024 18:35:44 GMT, Maurizio Cimadamore
wrote:
>> Archie Cobbs has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Cleanups & refactoring based on review suggestions.
>
> src/jdk.compiler
> Please review this fix for an incorrect `lint:` tag in `compiler.properties`,
> plus an adjustment to the build process to automatically detect and fail the
> build in case of any similar typos in the future.
Archie Cobbs has updated the pull request incrementally with one additiona
On Mon, 16 Dec 2024 16:54:46 GMT, Archie Cobbs wrote:
> Please review this fix for an incorrect `lint:` tag in `compiler.properties`,
> plus an adjustment to the build process to automatically detect and fail the
> build in case of any similar typos in the future.
This pull reques
On Tue, 25 Mar 2025 00:39:17 GMT, Chen Liang wrote:
> Migrates the CreateSymbols tool to use the ClassFile API, away from
> com.sun.tools.classfile.
>
> Need the boot jdk `--with-boot-jdk=` to be 24; thus a draft for now; but this
> is open to reviews.
>
> Together with #24206, the old com.su
On Thu, 20 Feb 2025 20:57:47 GMT, Archie Cobbs wrote:
> This PR is a prototype to stimulate discussion of
> [JDK-8261669](https://bugs.openjdk.org/browse/JDK-8261669), which seeks to
> add more warnings when an implicit cast of a primitive value might lose
> information. This
gt; As usual, warnings can be suppressed via `@SuppressWarnings` or by adding an
> explicit cast:
>
>
> float a = (float)0x1001; // no warning here
Archie Cobbs has updated the pull request incrementally with one additional
commit since the last revision:
Check exactness of c
On Fri, 21 Feb 2025 11:31:34 GMT, Raffaello Giulietti
wrote:
> You may want to take a look at `java.lang.runtime.ExactConversionsSupport`.
Thanks! That's exactly what I needed. Fixed in 92b479a94ff.
> There are several reasons that it would be ideal to hold this PR off, for
> now. There is an
This PR is a prototype to stimulate discussion of
[JDK-8261669](https://bugs.openjdk.org/browse/JDK-8261669), which seeks to add
more warnings when an implicit cast of a primitive value might lose
information. This can possibly happen when converting an `int` to `float`, or
when converting a `l
On Thu, 20 Feb 2025 20:57:47 GMT, Archie Cobbs wrote:
> This PR is a prototype to stimulate discussion of
> [JDK-8261669](https://bugs.openjdk.org/browse/JDK-8261669), which seeks to
> add more warnings when an implicit cast of a primitive value might lose
> information. This
31 matches
Mail list logo
