`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())`.
Fixes an issue where source links are incorrectly URI encoded; i.e. `https%3A//github.com` instead of `https://github.com`.
This was causing the browser to resolve these as relative to the enclosing page.
- Change HttpClient to follow all redirects except HTTPS to HTTP.
- Run language snippet tests with --no-cache and real PackageServer
instead of pre-seeded cache.
This increases HTTP test coverage and enables testing of package redirects.
- Change PackageServer to return 301 for request paths starting with /HTTP301/
and 307 for request paths starting with /HTTP307/.
- Update some outdated test package checksums that apparently weren't verified.
The maven publish plugin isn't setting up dependencies correctly,
and we are getting errors like:
"Task ':pkl-config-java:publishFatJarPublicationToMavenLocal' uses
this output of task ':pkl-config-java:signLibraryPublication' without
declaring an explicit or implicit dependency."
This adds a workaround for this type of error.
Changes the packager to exclude any empty directories.
This change means that pkl project package for an already published packages will fail. The packager checks for an existing package at this version, and compares checksums. It will then error if the checksum has changed.
This is technically a breaking change, albeit a minor one. The workaround is to publish new versions of packages.
Published packages should still be compatible with Pkl 0.25.
Make sure that declaring a dependency on project `pkl-commons-test`
suffices to have its test fixtures generated.
This fix should work reliably.
However, there may be a more idiomatic way to achieve the same result.
- Fix and clean up the pkl-commons-test build script.
- Change tests to read test packages/certs directly from
the file system instead of packaging and reading them
from the class path.
- Update expected checksums of some test packages.
- Fix a conflict between Pkl's and Gradle's
Kotlin libraries in the pkl-gradle project.
- Fix build deprecation warnings.
- Ensure Gradle distribution integrity with `distributionSha256Sum`.
- Manually verify integrity of Gradle wrapper added by this commit.
This fixes an assertion error that gets thrown if:
1. A module declares a class as abstract
2. An amending module does not use that abstract class as a type
Underneath the hood, the modifiers of the class/typelias object member
is considered different from the modifiers on the VmClass/VmTypeAlias
values.
The object model skips forcing any explicitly members that are explicitly
declared hidden, abstract, or local.
However, it _should_ evaluate any abstract classes found in a module.
So, it's incorrect to apply the same modifiers on the class to the object member.
