Fixes an issue where the executable is not built.
Haven't dug into why this broke; this was working just a little bit ago
(see
https://github.com/apple/pkl/actions/runs/19911073549/job/57079605641?pr=1342).
Nevertheless, the lifecycle job dependencies were a little wonky (test
should assemble first).
[native-pkl-doc]
This fixes an issue where URLs with schemes that contain `+`, `-`, and
`.` would not be parsed correctly.
For example, `foo+bar:///?baz.pkl` would turn into
`foo+bar:///%3Fbaz.pkl`. The query param is lost, and turned into the
path.
In order to preserve the folder hierarchy in our uploaded artifact,
we need to insert a wildcard in the root path.
Also, fix fan-in of tasks that lead to the publish test result task.
This switches our builds over to GitHub Actions!
TODO:
* Add macOS/amd64 native-image builds; this isn't working right now
* Patch musl with security patches
* Add benchmark jobs over time
As part of this build, PRBs will now only run `./gradlew check` on Linux,
but other jobs can be run using slash commands, e.g. `[windows]`
to run `./gradle check` on Windows.
This causes spotless to _always_ format Pkl files, instead of only
formatting them if there's a diff between the file and what's in main.
This means that formatting changes in pkl-formatter will be propagated
to the standard library.
This fixes several issues:
1. Leading/trailing line comments surrounding a lambda should make that
lambda not "trailing", because the formatting otherwise looks bad and
also isn't stable
2. Fix incorrect algorithm for detecting trailing lambda (currently,
any number of lambdas makes the alg return `true`)
If an operator chain or method call is multiline, keep those newlines
in the formatted output.
Help preserve code like:
```
foo
|> (it) -> it + 2
|> (it) -> it / 2
```
Also, fixes an issue where forced single-line formatting would break for if/else
and let expressions
---------
Co-authored-by: Islon Scherer <islonscherer@gmail.com>
This changes code so that multiple lambda arguments makes the whole
argument list wrap.
Improves the readability of code like:
```
foo
.toMap(
(it) -> makeSomeKey(it),
(it) -> makeSomeValue(it)
)
```
This adds a spotless formatting step using the new pkl formatter.
This only formats Pkl sources in the stdlib, because other sources
are possibly test input and not meant to be formatted.
This forces iterpolated expressions to be single-line, so that newline
literals within the bounds of two string delimiters can be seen as
verbatime newlines in the resulting string.
Edge case: in the case of a line comment, it's not possible to keep
this as a single line expression.
These are kept as multi-line expressions.
Also:
* Remove `ForceWrap`, this node is not used.
* Rename `StringConstant` -> `StringChars`
This introduces an IntelliJ plugin that's meant to assist with development of the Pkl codebase itself.
The plugin adds a file editor that opens snippet tests in a split editor pane, showing the input on the left side and output on the right side.
This changes the formatter to only force line on call chains
with multiple lambdas
With this change, this is kept as a single line:
```
foo.bar.map((it) -> it + 1)
```
The current version of the kotlin-gradle plugin is not compatible with
Gradle 9.1, causing error `java.lang.NoSuchMethodError:
'org.gradle.api.Project org.gradle.api.artifacts.ProjectDependency.getDependencyProject()'`
Also, the Kotlin 2.0 language target is deprecated as of Kotlin 2.2.
* Bump Gradle to 9.1.0
* Bump foojay resolver to 1.0.0
* Fix build logic on windows
Also, remove support for kotlin gradle plugin less than 1.8.x, because:
* Class `org.gradle.api.plugins.Convention` is no longer available in the classpath in Gradle
* Continued support for legacy plugin would require heavy reflection, which is brittle and hard to verify
* Kotlin 1.7 is 3 years old and no longer updated
Currently, in order to update a pkl-doc documentation site,
almost the entire existing site is read in order to update metadata
like known versions, known subtypes, and more.
For example, adding a new version of a package requires that the
existing runtime data of all existing versions be updated.
Eventually, this causes the required storage size to balloon
exponentially to the number of versions.
This addresses these limitations by:
1. Updating the runtime data structure to move "known versions" metadata
to the package level (the same JSON file is used for all versions).
2. Eliminating known subtype and known usage information at a
cross-package level.
3. Generating the search index by consuming the previously generated
search index.
4. Generating the main page by consuming the search index.
Because this changes how runtime data is stored, an existing docsite
needs to be migrated.
This also introduces a new migration command, `pkl-doc --migrate`,
which transforms an older version of the website into a newer version.
This fixes two issues:
1. Test mode is enabled in pkldoc without the ability to turn it off
2. Native pkldoc is missing required resources
This also adds tests for both `jpkldoc` and `pkldoc`.
The backslash needs to be escaped when rendering double-quoted YAML strings.
In addition, this escapes the following characters:
* next line (0x85)
* nbsp (0xa0)
* Snapshot repo has changed
* Fix a bug where pkl-codegen-java download link points to Sonatype instead of GitHub
Not in the PR: we also need to fix the snapshot download location;
but haven't figured out yet what the correct link is.
This is a bugfix, where the `rewrites` option is currently ignored.
Also: return any illegal argument errors from creating the evaluator as
an error in the CreateEvaluatorResponse
This makes changes to avoid a needless breaking change.
It preserves code like `new Resource { base64 = someValue }.sha256`,
and also code that renders `Resource` into static formats.
Co-authored-by: Islon Scherer <islonscherer@gmail.com>
* Polish rewrite docs
* Add documentation comments, add missing evaluator options
* Add ability to set HTTP builder in ConfigEvaluatorBuilder
* Add ability to set rewrites in executor API
This adds logic so that the Kotlin code generator also supports the
"addGeneratedAnnotation" flag.
Also:
* Add Antora documentation
* Adjust names (generated-annotation -> add-generated-annotation)
* Adjust doc comments
This introduces a new `Bytes` standard library class, for working with
binary data.
* Add Bytes class to the standard library
* Change CLI to eval `output.bytes`
* Change code generators to map Bytes to respective underlying type
* Add subscript and concat operator support
* Add binary encoding for Bytes
* Add PCF and Plist rendering for Bytes
Co-authored-by: Kushal Pisavadia <kushi.p@gmail.com>
The preconfigured evaluator currently adds module key factories from
service providers, but not resource readers.
This means that users of pkl-spring, for example, cannot add custom
resource readers.
This is also inconsistent (in the preconfigured evaluator, `import` can
use custom schemes, but not `read`).
* Update dependencies
1. Remove */gradle.lockfile files
2. Run `gradle updateDependencyLocks` and commit
* Update multi-JDK testing to use simple Test task, add junit-platform-launcher to dependencies
- Don't use JvmTestSuite (we don't use another test runner, we use the same classpath)
* Add junit-platform-launcher to libs (prevent an issue where junit-engine and junit-launcher can fall out of sync)
Opaque file URIs are URIs whose scheme-specific part does not start with `/`.
For example, `file:foo/bar.txt` is an opaque URI.
Currently, this has the unintentional behavior of: look for file `foo/bar.txt` from the process working directory.
These are effectively dynamics imports; from a single import, we can't statically analyze what it resolves as.
According to RFC-8089, File URIs must have paths that start with `/`. So, these are actually _not valid URIs_.
See the grammar defined in https://datatracker.ietf.org/doc/html/rfc8089#section-2
This changes Pkl's behavior so that these URIs are treated as errors.
This changes the Gradle build to always create multi-jdk tasks,
and instead use the `enabled` property to determine whether the task
is actually ran or not.
The has the following benefits:
* IntelliJ and other tools understand the task execution graph (e.g. testJdk20 shows up as a task)
* JDK-specific Gradle configurations always exist, so `updateDependencyLocks` is consistent.
This adds logic to build and publish the other executables related to Pkl.
These are:
* pkl-doc
* pkl-codegen-kotlin
* pkl-codegen-java
pkl-codegen-kotlin and pkl-codegen-java are published as executable JARs, whereas pkldoc is published both as an executable JAR, and also native executables (matching the set of os/arch supported by Pkl).
The reason this only publishes executable JARs for pkl-codegen-kotlin and pkl-codegen-java is because we expect that the Java requirement is not a problem for these users, and that the native executable provides negligible added value.
As part of this, the following changes are made:
* Introduce `pklJavaExecutable` plugin, which sets up building and publishing of executable JAR.
* Introduce `pklNativeExecutable` plugin, which sets up building and publishing of native executables.
* Introduce `NativeImageBuild` Gradle task, which knows how to build native-image executables.
* Introduce `ExecutableSpec` extension, for projects that publish executables to configure how those executables should be published.
* `./griddles buildNative`, by default, will only build the executable of the host OS/Arch, and will no longer cross-build.
* The target arch of `./gradlew buildNative` can be changed using `-Dpkl.targetArch=<aarch64|amd64>`.
* On linux/amd64 only, with `./gradlew buildNative`, a statically linked executable can be built using `-Dpkl.musl=true`
* Make `javaExecutable` a dependency of `assemble`
* Make `testStartJavaExecutable` a dependency of `check`
* Change name `pklNativeBuild` to `pklNativeLifecycle` to better match the plugin's purpose
* Remove Truffle SVM classes from main source set (don't publish these classes as part of the pkl-cli JAR)
* Change CircleCI definition to publish new executables
* Change CircleCI definition to call `buildNative` instead of individual task names
If a generator object literal doesn't add any object members, we
can simply use the parent in its place.
Co-authored-by: Kushal Pisavadia <kushi.p@gmail.com>
Using native libraries in Gradle plugins is problematic; this adds some flags that causes Truffle to use a fallback runtime that avoids loading native libraries.
This changes the language to check all types eagerly when within a type constraint.
This addresses two regressions in the language:
1. Type constraints are too relaxed (listing/mapping parameters may not be checked)
2. Failing type constraints hide members that were forced during execution of the constraint
When we updated spotless's Java and Kotlin formatter, we changed the underlying
formatting rules.
However, due to spotless ratcheting, these formatting changes don't get applied unless a file
gets touched in a commit.
To avoid future PRs introducing lines of change that aren't related to the intention of the PR,
this is a one-time format of all files.
Daniel Chao