Fix all IntelliJ warnings in Java production code except for
bogus spelling warnings and warnings about unused public methods.
Also fix some warnings emitted by Code->Inspect Code.
Changes made:
- use text block instead of string concatenation
- extract method to avoid code duplication
- use switch expression
- fix Javadoc syntax and spelling
- fix spelling in comment
- increase class visibility to match visibility of use site
- delete overriding method with same implementation
- use String.isEmpty() and StringBuilder.isEmpty()
- add @Serial annotation
- make field final
- remove unused field
- remove unused private method
- remove exceptions that aren't thrown from throws clause
- insert non-null assertion
- annotate overriding method with @Nonnull
- suppress warning
- delete unused class (WriteAuxiliarySlotNode)
- add final modifier
- remove unused error message
- repeat @Nullable modifier in overriding method
- remove never thrown exception from throws clause
- remove redundant suppression
- Refactor code to use the following basic Java 17 features:
- pattern matching for instanceof
- @Serial annotation
- switch expressions
- enhanced switch statements
- StringBuilder.isEmpty()
- Replace two switch statements with simpler if statements.
- Rename a few local variables.
* Remove unnecessary strictfp modifier
* Add annotations to address Truffle DSL warnings (@Idempotent, @Exclusive)
* Adjust build logic to allow building cross-arch on macOS
* Add warning suppression for specialization limit (left this one as a TODO)
- Check `method.isConst()` every time a method is resolved
instead of once per node instance (`isConstChecked`).
Given that `needsConst` only happens in very specific circumstances,
I'm not entirely sure if every resolved method needs to be checked.
However, it's a cleaner solution in any case, and `method.isConst()`
is a fast check that also never happens on the `evalCached` fast path.
- Do not check for const-ness of `FunctionN.apply` methods.
This check seems unnecessary and would always fail if triggered.
(According to `base.pkl`, none of the `FunctionN.apply` methods is const.)
- Remove unnecessary Truffle boundaries for modifier checks,
which are just bitwise operations.
- Improve const/import docs.
`class System` gets initialized at build time through `native-image`
and added to the heap. We initialize everything at build time via the
`--initialize-at-build-time=` flag.
Changes include:
1. Spelling correction addressing #401
2. Grammer and punctuation corrections.
3. Rephrasing of some harder-to-read sentences. Most are simple one or two-word additions to make reading less jarring.
4. Changed hyphenation occurrences that included – rather than a regular hyphen-dash.
When using spread syntax with typed object, properties that are fixed
or const cannot be assigned or amended.
This should be checked in the checkTypedProperty() function.
* Class-based converters are covariant, not invariant.
* The most specific class-based converter wins
* The first declared path-based converter that matches wins
- Update google-java-format to a version compatible with JDK 21 and run "gw spotlessApply".
- Fix wrong test assumption
JavaCodeGenerator writes a properties file using java.util.Properties,
which doesn't guarantee order of entries.
- Fix most deprecation warnings
- Add CI job for JDK 21
The initialSize in EconomicsMaps.create() is not the actual stored size,
hence the accurate size is not determined until ObjectMembers are added
after addMembers() called.
Since the size set during the creation of VmListing cannot be changed
afterwards, the size of node.getValue() is used instead of members'
size.
Rationale: "Output file names are known only after execution"
isn't a legitimate reason to make this task untracked
because the output directory is known in this case.
This is no different from (say) the `JavaCompile` task,
where only the class file output directory is known upfront.
Forum discussion didn't reveal another reason why this task
should be untracked.
Motivation:
The standard library docs are some of the most important docs
but currently very hard to find. I've noticed that even advanced
users have never heard of them and complain about "zero docs".
Use `Files.newInputStream(path)` instead of `new FileInputStream(path.toFile())`
and `Files.newOutputStream(path)` instead of `new FileOutputStream(path.toFile())`.
