This introduces a rule that const properties cannot use the `this` type if that referenced type exceeds the scope.
This code is an error:
```pkl
const foo: this
```
This is not:
```pkl
const foo = new {
local myself: this
}
```
Additionally, this fixes:
* const depth logic to account for eager scopes
* behavior of `this` type inside custom this scopes
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>
Dan Chao
Jen Basch
Aashish Mahato
Goutam Adwant
Sam Gammon
Aagam Shah
Carpe-WangandJen Basch
Maycon Campos