Motivation:
- Java serialization makes as much sense for module classes as it does for regular classes.
- Offer same Java serialization support as codegen-java.
Changes:
- Move generation of `appendProperty` method and serialization code
into new method `generateCompanionRelatedCode`.
- Improve/fix generation of serialization code.
Result:
Java serialization is also supported for module classes.
Write annotations to project metadata, and provide them to pkl-doc\
The following annotations have meaning for pkl-doc:
* `@Unlisted`: hide package from documentation site
* `@Deprecated`: add deprecated information
Fix a bug where overwriting `output` causes a PklBugException.
This now produces a more helpful message pointing to the actual problem.
Co-authored-by: translatenix <119817707+translatenix@users.noreply.github.com>
Motivation:
Currently, the condition for making a generated Java class instantiable is "class is neither abstract nor stateless".
(An instantiable class receives a public constructor and equals/hashCode/toString/with methods.)
This is inconsistent with Pkl and codegen-kotlin, both of which support instantiation of stateless classes.
Changes:
Widen condition for making a class instantiable to "class is neither abstract nor a stateless final module class".
This is consistent with codegen-kotlin, which generates object declarations (only) for stateless final module classes.
Result:
Stateless classes are instantiable in Pkl, codegen-java, and codegen-kotlin.
Motivation:
- Currently, the condition for generating equals/hashCode/toString methods is "generated class declares properties".
As a result, classes that don't declare properties inherit these methods from their generated superclasses.
However, generated `equals` and `toString` methods aren't designed to be inherited
and will either fail or produce wrong results when called for a subclass.
- Currently, the condition for generating `with` methods is "class is not abstract".
However, it isn't useful to generate `with` methods for non-instantiable non-abstract classes.
- Currently, the condition for making classes serializable is "class is not a module class".
However, it isn't useful to make non-instantiable non-module classes serializable,
and it is useful to make instantiable module classes serializable.
Changes:
- Change condition for generating equals/hashCode/toString/with/Serializable to "class is instantiable".
This is a breaking change.
(A generated class is instantiable, i.e., declares a public constructor,
if it is neither abstract nor stateless. This behavior remains unchanged for now.)
- Overhaul JavaCodeGeneratorTest
- introduce classes JavaSourceCode and JavaSourceCodeAssert
- change assertions to use JavaSourceCodeAssert via `assertThat(javaCode)`
- use parameterized test instead of loop
- use explicit trimIndent() and trimMargin() for multiline string literals
- IntelliJ editor desperately wants to insert trimIndent()
- can potentially be exploited by kotlinc and ktfmt
Result:
- Fixes all motivating issues.
- Fixes#706.
* codegen-kotlin: Don't generate equals/hashCode/toString/copy/:Serializable for abstract classes
* Polish KotlinCodeGeneratorTest
- use `assertContains()` instead of `assertThat().contains()`
- remove redundant `trimIndent()` and `trimMargin()` calls
- rename `javaCode` to `kotlinCode`
* Overhaul KotlinCodeGeneratorTest
- introduce classes KotlinSourceCode and KotlinSourceCodeAssert
- change assertions to use KotlinSourceCodeAssert via `assertThat(kotlinCode)`
- use explicit trimIndent() and trimMargin() for multiline string literals
- IntelliJ editor desperately wants to insert trimIndent()
- can be used by kotlinc and ktfmt
- format code in the exact way it falls out of the IntelliJ editor
(successfully destroyed by ktfmt)
The addresses the following case:
local l1: Listing<String> = new { 1 }
l2: Listing<Int> = (l1) { 2 }
The member in `l1` should be checked against its owner; to check against `Listing<String>`.
This adds a new feature to build a dependency graph of Pkl programs, following the SPICE outlined in https://github.com/apple/pkl-evolution/pull/2.
It adds:
* CLI command `pkl analyze imports`
* Java API `org.pkl.core.Analyzer`
* Pkl stdlib module `pkl:analyze`
* pkl-gradle extension `analyze`
In addition, it also changes the Gradle plugin such that `transitiveModules` is by default computed from the import graph.
* Add version of resolved Pkl distribution to `ExecutorException`
* Review comments
Co-authored-by: Daniel Chao <daniel.h.chao@gmail.com>
---------
Co-authored-by: Daniel Chao <daniel.h.chao@gmail.com>
This adds support for adding the `const` modifier to object members.
Such object members are also required to have the `local` modifier applied.
This follows SPICE-0011.
- Update dependencies by deleting lock files and regenerating them with `gw updateDependencyLocks`.
Deleting lock files avoids strange `some.library:some.older.version=default` entries.
Most updated dependencies are test dependencies.
- Handle breaking changes in library commonmark.
- Fix test to close PackageServer exactly once.
This problem surfaced because JUnit 5.11 changed override rules for lifecycle methods,
resulting in too many instead of too few close() calls.
- Bump msgpack version
- Bump clikt version
- Bump Gradle plugin versions
Because I did not understand what a `Let Expression` should be and the example code was more confusing as explanatory, I changed the format of the examples a little bit and changed the result.
- It should be clear that the example is just one code-line
- I tried out the example (`pkl eval...`) and get a little bit different result
Co-authored-by: ManuW <ManuW@users.noreply.github.com>
Motivation:
Speed up the test that verifies enforcement of the limit for glob pattern resolution (invalidGlobImport6.pkl).
Changes:
- Set a lower limit if test mode is enabled.
- Change static field to static method to prevent compile-time evaluation by native-image.
In messages "Read Resource Response" and "Read Module Response", if `contents` and `error` are both null, default to an empty byte array/string.
This resolves one of the issues reported in #656
This changes how the language performs typechecks for mappings and
listings.
Currently, Pkl will shallow-force any Mapping and Listing to check it
the type parameter (e.g. Listing<Person> means each element is checked
to be an instance of Person).
This changes the language to check each member's type when the member
is accessed.
This also adjust test runner to handle thrown errors from within tests.
With the change to make mapping/listing typechecks lazy, we can now
correctly handle thrown errors from within a single test case.
This adjusts the test runner to consider any thrown errors as a failure
for that specific test case.
