RFR: 8303755: Clean up around JavacElements.getAllMembers [v2]
Pavel Rappo
prappo at openjdk.org
Tue Mar 7 16:41:14 UTC 2023
On Tue, 7 Mar 2023 15:44:28 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:
>> Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
>>
>> - Merge branch 'master' into 8303755
>>
>> # Conflicts:
>> # src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java
>> - Improve CompoundIterator
>>
>> - it could be improved even further, but kept as is to retain its
>> laziness
>> - `remove` is deleted as it now is a default Iterator method
>> - Improve Iterators.createFilterIterator
>>
>> Assert that the mechanics relies on iterator being filtered never
>> to return null.
>> - Fix typos and improve consistency
>> - Avoid unnecessary recomputation
>> - Fix typos and {@inheritDoc} that stands out
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/util/Iterators.java line 89:
>
>> 87: while (input.hasNext()) {
>> 88: E sym = input.next();
>> 89: assert sym != null; // otherwise, false positive EOF
>
> javac coding style is to use the `Assert` class, not `assert` statement
If you are considering an unconditional null check here, then you might want to consider a dedicated EOF flag instead. Alternatively, I can remove the `assert`, but leave the comment; for the next reader.
It's probably the case that iteration elements are never `null`. If they were `null`, we would either notice false positive EOF or see NPEs thrown from predicates.
-------------
PR: https://git.openjdk.org/jdk/pull/12904
More information about the compiler-dev
mailing list