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.
Patterns that originate from the language runtime will add
`Pattern.UNICODE_CHARACTER_CLASS | Pattern.UNICODE_CASE` as implicit
regex flags, so we need to do the same on the binary decoding side.
* Compute a derived regex expression with `\z` anchor
* Ensure derived regex can't be messed up with comments (in extended mode) or quote start
Follow up to #1880
This adds logic to UnresolvedTypeNode to create a `UnionOfStringLiterals`
type node if a member is a typealias who is a string or a string literal union.
Also, this fixes an issue where marking a duplicate string literal with the
default marker throws an index out of bounds exception.
This makes various improvements to help truffle do partial
evaluation of code related to typechecking.
* Split `UnionTypeNode` into `UnionTypeNodeExploded` and
`UnionTypeNodeLooped` to avoid gigantic graphs. This especially helps
in the case of typealiases, because they are inlined into their usage
sites.
* Move constraint-failure exception construction in
`TypeConstraintNode` behind `@TruffleBoundary` helper methods
instead of `transferToInterpreterAndInvalidate`, since building the
exception is a rare, off-hot-path operation.
* Move `ClassNode`'s one-time class-initialization logic behind a
`@TruffleBoundary` method (`initClass`), store `VmLanguage` as a
field instead of recomputing it via `VmLanguage.get(this)`, and use
`transferToInterpreterAndInvalidate` since class init never needs to
re-run on the compiled path.
* Pass `VmLanguage` explicitly into `TypeTestNode` and `ClassNode`
(via `AstBuilder`) rather than resolving it with
`VmLanguage.get(this)` on a hot path.
* Fix various issues where the partial evaluator determines that a frame
should have been materialized but was not.
* Pre-initialize call targets in `ObjectMember.setMemberNode()` and
`FunctionLiteralNode` so the first invocation doesn't trigger a
compilation invalidation.
* Fix truffle node tree issues (don't mark `@RootNode` as child,
deepCopy instead of passing an already adopted node).
* Remove unnecessary interpreter transfers when throwing type mismatch exceptions
This changes the `join` method in `List`/`Set`/`Listing` to
call the overridden `toString()` method.
This is a breaking change, but is considered a bugfix.
Fix this printed warning during java compilation:
"Note: Some input files use unchecked or unsafe operations. Recompile with -Xlint:unchecked for details"
* Add `-Xlint:unchecked` as a javac flag
* Fix the various warnings
This changes the logic for inferring `new {}` expressions in method
arguments to using regular frame slots, instead of auxiliary slots.
Overall, this is a performance improvement: no looking up auxiliary slot
numbers, which makes this code much more PE friendly.
* At parse time, get or create a frame slot that holds the method
* Introduce `ArgInfo` record (preserve primitive int) over using `Pair`
* Remove unneeded `isImplicitNewExpr` method; this is not needed because
we can just keep track of the method slot on the frame descriptor
builder.
This changes code so that the in-language `toString()` doesn't use
Java's `Object.toString()`.
Additionally, the existing `toString()` implementation is switched over
to using `VmValueRenderer`, which does not force (leaves `?` in place of
unforced values).
This helps improve ergonomics when working on the language (can enable
automatically calling `toString()` on debug values).
Additionally, external tools might call toString(); for example,
Truffle's compiler sometimes will stringify node fields (e.g.
when -Dengine.CompilationFailureAction=Throw) is set.
Fix invalid prefix when generating spring boot config
In Spring Boot, the prefix passed to `@ConfigurationProperties` must
be in "canonical form".
The presence of this annotation allows spring boot to directly inject
properties into a class, but is not actually needed.
The correct behavior here is to omit this annotation if the property
name does not match Spring Boot's canonical form.
* In GeneratorWhenNode, need to move individual iterations into their
own methods so that the @ExplodeLoop sees a constant number of
iterations whenever that method is called.
* In the other nodes, the lambda passed to
`forceAndIterateMemberValues` needs to capture the materialized frame,
not the virtual frame.
YamlEmitter only routed a string into YamlEscaper when it held a
character below 0x20, so 0x7F, the C1 block, U+2028 and U+2029 went out
as plain scalars. They are not `c-printable` (YAML 1.2 spec 5.1), and
NEL, LS and PS are line breaks in YAML 1.1, so the rendered document is
either rejected or silently split by a reader.
The escapes added in #1165 for 0x85, 0xA0, U+2028, and U+2029 could only
fire when some other character happened to open that gate. Share one
predicate between the two sites that decide, and give 0x7F-0x9F the
8-bit escape they lack.
This skips some unnecessary steps when evaluating annotations that
have no attached object bodies by returning an EmptyObjectLiteralNode
instead of a PropertiesLiteralNode
GraalVM's partial evaulator can't handle recursive calls into the same
node.
The current implementation around evaluating `VmNull` as a parent causes
the partial evaluator to bail out, leaving Pkl stuck in interpreter
mode.
This rewrites the various object literals to add individual
specializations for each type of default value we can see from a VmNull
parent.
Also:
* Fix `isTypeObjectClass` impl
* Fix bug when amending with generator object literal node with object params
The truffle compiler currently _always_ bails out of compilation for
`VmUtils.getFrame()` calls, because it determines that some branch
of this code can possibly return a materialized frame.
This adjusts the code so that the hot path (levelsUp == 0)
does not touch `VmUtils.getFrame()`, and avoids unnecessarily
materializing the frame.
This rewrites the listing/mapping typecast nodes to be more friendly
to partial-evaluation.
This is because the compiler bails out of deeply recursive calls.
This moves the protobuf module from experimental to deprecated
Rationale:
* This is very seldom used, if used at all
* Not fully fleshed out (this really should be paired with a protoc-gen-pkl, which doesn't exist)
* There is a ProtoJSON wire format that we can already render to