We reject any filepath that contains a `\` character;
all Pkl code must use `/` as the path separator.
So, we don't need to normalize `%5c` as a path sep on Windows.
This changes type argument syntax to "standard" style, and away from turbofish.
The motivation here is that turbofish-style type arguments are hard to read, and developers who are not already deeply knowledgeable about Pkl might struggle to understand such code.
In most languages, the grammar for "method call with type args" don't introduce any additional symbols between the identifier and the type argument list (e.g. C++, TypeScript, C#, Scala, Go).
This adds changes such that URIs like `file:///path/to/%2E%2E/bar.txt`
are considered path traversal sequences.
These URIs are treated as dot segments, and normalized prior to calling
into security checks.
For package URIs, the same treatment is applied to the
URI fragment.
jar-file URIs are special-cased and normalized as well.
Additionally, `%2f` is treated as `/` for file, jar-file and asset path segments.
However, these are left alone for other URIs (RFC-3986 treats `%2e` as identical to `.`, but `%2f` as distinct from `/`)..
* VmObject.getRootFirstObject() is a recursive call, which sometimes
fails with "too deep inlining"
* Incorrect loop condition profile usage in some places
* Need to mark `checkedReturnTypeNode` final so that GraalVM knows
that it is PE constant
Sometimes we see a thrown IllegalStateException when CPU profiling,
where the underlying cause is a ConcurrentModificationException in
the underlying GraalVM internals.
This attempts to minimize the chances of this exception being thrown
by starting proiling after the evaluator and its context have been
created.
Motivation:
- VmObjectLike.iterateMemberValues() is an internal iterator whose loop body is a Java lambda.
It suffers from the following limitations:
- `continue` and `break` cannot be used.
- `return` becomes an (awkward) replacement for `continue` and `break`.
It cannot be used to return from the enclosing method.
- Mutating variables requires hoisting them (MutableBoolean, etc.).
- Node.execute() calls are very slow because they are behind a Truffle boundary.
- Callers of iterateMemberValues() do not specify what and how they want to iterate.
This obscures the iteration code and makes it difficult (often impossible) to optimize.
Changes:
- Add interface VmObjectCursor, an external iterator that iterates over VmObject members.
Its design is inspired by org.graalvm.collections.MapCursor.
- Add VmObjectCursor implementations specialized for different members, VmObject subclasses, and cursor options.
- Replace VmObjectLike.iterateMemberValues() with the following methods that return VmObjectCursor:
- properties()
- properties(CursorOption)
- elements()
- elements(CursorOption)
- entries()
- entries(CursorOption)
- members
- members(CursorOption)
- Replace all usages of iterateMemberValues() with one of the above methods.
Before: object.iterateMembersValues((key, member, value) -> { if (member.isProp()) {...} });
After : for (var cursor = object.properties(); cursor.advance(); ) {...}
Result:
- Iteration code is much simpler and clearer.
- Iteration code that calls Node.execute() is much faster because it is no longer behind a Truffle boundary.
- Other iteration code is potentially faster and can be better optimized in the future.
Co-authored-by: translatenix <119817707+translatenix@users.noreply.github.com>
Co-authored-by: Jen Basch <jbasch94@gmail.com>
This introduces a way to run CPU profiling.
The profiler produces output in pprof format.
CLI users can enable CPU profiling via command line flags.
Profiling is otherwise not offered as an API.
Co-authored-by: Jen Basch <jbasch94@gmail.com>
Co-authored-by: Islon Scherer <islonscherer@gmail.com>
* Add tasks to generate source jars for java executables
* native source bundles
* source bundles in separate plugin
* Wire up sourceBundle task
* Produce bundles on a per-variant basis (Java fat jar, each native variant)
* Introduce `pklNativeSourceBundle` and `pklJvmSourceBundle` plugins for handling fat jar vs. GraalVM bits
* Download compiled classes list, and exclude Java sources for executable stuff specifically
* Include native sources when appropriate (GraalVM, JDK, zlib, musl, libpkl)
---------
Co-authored-by: Jen Basch <jbasch@apple.com>
This adds an option which allows users to control exactly how
`@ConfigurationProperties` annotations are attached to classes.
This helps when:
* Spring Boot users don't have a single root class, but multiple
classes that are injected in disparate places
* Pkl's module structure doesn't match the resulting `.properties`
layout
This changes it to render the qualified name instead of the simple name.
* Module classes render the module name
* Classes within module render the module name and the class name joined by `#`
* Rendering of members of `pkl:base` does not change
For example:
* `new k8s.core.v1.Service {}` instead of `new ModuleClass {}`.
* `new k8s.core.v1.Service#ServiceSpec {}` instead of `new ServiceSpec {}`
* `new pkl.Project {}` instead of `new ModuleClass {}`
This affects the following:
* `toString()`
* `trace()`
* Error messages
* REPL
Currently the module cache directory in CLI commands (and thus in Gradle tasks, since they use CLI commands under the hood) is only used for the "primary" task. For example, for an eval command, the module cache directory will be used for the evaluation of the target module.
However, most commands also work with projects, and for projects the `PklProject` file must be evaluated. This is done via `Project.loadFromPath`, which internally builds an evaluator with the default module cache path. Therefore, all evaluations of project manifests always use default cache path instead of whatever is configured through the CLI option/Gradle task property. This, in turn, may result in unexpected behavior: in general, the user would expect that if they specify the cache directory, it will be used for all evaluations (e.g. when they pre-populate the cache and expect evaluations to work offline).
The same is true for settings evaluation, although for settings it is significantly less important since settings scripts can't have remote dependencies.
This PR propagates cache path into the project evaluator (as well as the settings evaluator, for consistency). This will result in the user-specified cache directory being used for `PklProject` evaluations as well.
Daniel Chao
Jen Basch
Aashish Mahato
Jen Basch
Islon Scherer
Goutam Adwant
Sam Gammon
Aagam Shah
Carpe-WangandJen Basch
Maycon Campos
Alexandre Kohler
Vladimir Matveev