This fixes issues when a mapping/listing delegates to another mapping/listing.
The core issue is that `cachedValues` is not guaranteed to be the complete set
of the object's members; they may be stored on the delegate instead.
Therefore, it's not correct compute hash code and equality based on `cachedValues`.
Instead, it's better to use the `getCachedValue()` method, which has the correct
logic for looking up the existing cached value.
- change line numbers from blue to faint to improve legibility on dark backgrounds
- use EnumSet throughout
- move all ANSI classes into package core.util (no need to split them over util and runtime)
- rename AnsiCodingStringBuilder to AnsiStringBuilder
Any thrown Pkl Errors are colored in the simple test report!
Also:
* Refactor `TextFormatter` to be more generic; rename to `TextFormattingStringBuilder`
* Adjust test report slightly (no emojis, add more spacing).
* Introduce `ColorTheme` class.
* Make stack frame descriptors colored as "faint"
Also: this changes the summary so it summarizes _all_ modules, rather than a summary per module.
---------
Co-authored-by: Islon Scherer <islonscherer@gmail.com>
Co-authored-by: Philip K.F. Hölzenspies <holzensp@gmail.com>
GraalVM for JDK 17.0.12 is the final Critical Patch Update
made available under the GraalVM Free Terms and Conditions license.
Subsequent Critical Patch Updates require a commercial license.
* Encapsulate message transport by removing `ExternalReaderProcess.getTransport` and adding `getModuleResolver` and `getResourceResolver` methods
* Reuse `Random` instances within `ExternalReaderProcessImpl` and module/resource resolvers
* Externalize all `ExternalReaderProcessException` messages
* Add some missing doc comments to `ModuleKeyFactories` and `ResourceReaders` methods for external readers
* Move org.pkl.core.util.Readers to org.pkl.core.Readers
There is currently a bug around resolving variables within the iterable of a for
generator or spread syntax (https://github.com/apple/pkl/issues/741)
Normally, mappings/listings are type-checked lazily. However, this results in the said
bug getting widened, for any object members declared in the iterable.
As a workaround for now, prevent the bug from being any worse by ensuring that these
object members are eagerly typechecked.
- keep implementation classes internal to their packages
- make classes final if possible
- make namespace classes non-instantiable
- throw IllegalStateException instead of ExternalReaderProcessException for use after close
- common convention already used by HttpClient etc.
- programming errors should be signaled with unchecked exceptions
- use private instead of public lock object
- polish Javadoc
- delete commented out code
- don't use star import for a single class
* Add `values` to `Mapping`
* Add `entries` to `Mapping`
* Add `containsValue` to `Mapping`
* Add `every` to `Mapping`
* Add `any` to `Mapping`
* Add `toDynamic` to `Mapping`
* Add `lastIndex` to `Listing`
* Add `getOrNull` to `Listing`
* Add `first` to `Listing`
* Add `firstOrNull` to `Listing`
* Add `last` to `Listing`
* Add `lastOrNull` to `Listing`
* Add `single` to `Listing`
* Add `singleOrNull` to `Listing`
* Add `contains` to `Listing`
* Add `any` to `Listing`
* Add `every` to `Listing`
* Fixup `any` to `Listing`
* Revert "Add `toDynamic` to `Mapping`"
This reverts commit 5551974ecd8110aa2eb8f546e992c32d3181df9b.
* Revert "Add `values` to `Mapping`"
This reverts commit 6fc78796
* Revert "Add `entries` to `Mapping`"
This reverts commit a7e8dfc4
* Annotate new members with `Since` 0.27
* Fix documentation in `base.pkl`
* Add location information to empty/single checks in `Listing` operations
* Remove additional variable for laziness preservation
* Apply spotless
* Apply suggestions from code review
Co-authored-by: Daniel Chao <daniel.h.chao@gmail.com>
---------
Co-authored-by: Daniel Chao <daniel.h.chao@gmail.com>
* Load `PklProject` using the same security settings and env vars passed provided via ExecutorSPIOptions
* Handle thrown `PklException` from loading `PklProject` and throw `ExecutorSPIException`
* Handle thrown `PklException` of older Pkl distributions, converting them into `ExecutorSpiException`
Changes:
* Move class `TestResults` to package `org.pkl.core`, because it is a public class (it's the result of `Evaluator#evaluateTest`)
* Change examples to treat individual examples as assertions in the same test. Previously, they were considered different tests with an incrementing number. This better aligns with how facts are treated.
* Change `TestResults` to be a record, and introduce builders.
* Remove "module" test result section (it is not really a section).
* Add javadoc to `TestResults`
* Formatting fix: prefix ✍️ emoji just like we do the ❌ and ✅ emojis
* Consider writing examples as failures, not successes. `pkl test` will exit with code 10 if the only failing tests are due to writing examples.
This adds a new feature, which allows Pkl to read resources and modules from external processes.
Follows the design laid out in SPICE-0009.
Also, this moves most of the messaging API into pkl-core
Motivation:
In Spring Boot 3.0, the annotation type `org.springframework.boot.context.properties.ConstructorBinding`
was deprecated in favor of `org.springframework.boot.context.properties.bind.ConstructorBinding`.
In 3.2, the old annotation type was removed.
As of 3.0, a `@ConstructorBinding` annotation is no longer required/recommended for configuration classes with a single public constructor.
Changes:
Remove generation of `@ConstructorBinding` annotations in codegen-java and codegen-kotlin.
Result:
- Generated code is compatible with Spring Boot 3.x.
(Verified with locally updated pkl-spring.)
- Generated code is no longer compatible with Spring Boot 2.x.
To use Pkl 0.27 and later with Spring Boot 2.x, use Pkl 0.26's code generator.
- Fixes#139.
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
