Consider the following class, and pretend for the moment that text blocks were still a preview feature (which we'll effect using `-XDforcePreview`):

    class Block1 {
        String s = """
                   """;
        blah // parse error here
    }

In JDK 25, the compiler outputs this:

    $ javac -XDforcePreview --enable-preview -Xlint:preview --release 25 Block1.java
    Block1.java:2: warning: [preview] text blocks are a preview feature and may be removed in a future release.
        String s = """
                   ^
    Block1.java:4: error: <identifier> expected
        blah // parse error here
            ^
    1 error
    1 warning

In JDK 26 (current version), the compiler outputs this instead:

    $ javac -XDforcePreview --enable-preview -Xlint:preview --release 26 Block1.java
    Block1.java:4: error: <identifier> expected
        blah // parse error here
            ^
    1 error

Notice there is no preview warning emitted.

This only occurs when there is a _parse_ error; if there is a _semantic_ error, JDK 26 behaves correctly:

    $ cat Block2.java
    class Block2 {
        String s = """
                   """;
        void d(); // semantic error here
    }
    $ javac -XDforcePreview --enable-preview -Xlint:preview --release 26 Block2.java
    Block2.java:4: error: missing method body, or declare abstract
        void d(); // semantic error here
             ^
    Block2.java:2: warning: [preview] text blocks are a preview feature and may be removed in a future release.
        String s = """
                   ^
    1 error
    1 warning

(If you remove the `-Xlint:preview`, the same thing happens, but taking the form of the aggregated "recompile" note.)

This results from fixing JDK-8224228, which added support for `@SuppressWarnings("preview")` (previously it was ignored). The compiler can't interpret annotations until attribution, and if there is a parse error, attribution never happens, so the compiler never gets to the point of deciding whether a preview warning should occur at the text block.

More generally, this will happen any time:
* Some warning W is generated during the parsing phase
* Warning W's lint category is subject to @SuppressWarnings
* Some error E occurs during the parsing phase

Since the compiler doesn't know whether a @SuppressWarnings applies to W, it has two non-optimal choices:
1. Emit W anyway, at the risk of emitting a warning that should really be suppressed
2. Don't emit W, at the risk of not emitting a warning that is supposed to be emitted

Currently choice #2 is being made, under the theory that if your compilation is failing with an error, you probably want to focus on that anyway and warnings, even ones you don't want to suppress, are less important to see at this point.

On the other hand, another theory says choice #1 might provide a better IDE experience because warnings will appear more promptly as you work on getting your code to compile.

Obviously this is a fairly minor problem that may need nothing done. This issue is here simply to document it.