The body of a typealias gets inlined into wherever the typealias is used. This fixes a bug where the name resolution would resolve an additional type constraint on the next scope of this.
Lack of a frame scope
typealias doesn't currently have a frame scope, which is why we have to assign the owner and the receiver here. If it did, we could read both of these at the point where we're trying to resolve the typealias in question.
🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.
## 📋 Pull Request Information
**Original PR:** https://github.com/apple/pkl/pull/144
**Author:** [@KushalP](https://github.com/KushalP)
**Created:** 2/13/2024
**Status:** ✅ Merged
**Merged:** 2/15/2024
**Merged by:** [@bioball](https://github.com/bioball)
**Base:** `main` ← **Head:** `fix-name-resolution-typealias-with-constraint`
---
### 📝 Commits (1)
- [`bbcb5cf`](https://github.com/apple/pkl/commit/bbcb5cf00ceaf70969a696d2af1298db76c939c3) Fix name resolution in `typealias` with constraint
### 📊 Changes
**11 files changed** (+76 additions, -7 deletions)
<details>
<summary>View changed files</summary>
📝 `pkl-core/src/main/java/org/pkl/core/ast/member/TypeAliasNode.java` (+2 -1)
📝 `pkl-core/src/main/java/org/pkl/core/ast/type/TypeNode.java` (+23 -0)
📝 `pkl-core/src/main/java/org/pkl/core/runtime/VmTypeAlias.java` (+10 -1)
📝 `pkl-core/src/main/java/org/pkl/core/runtime/VmUtils.java` (+8 -0)
➕ `pkl-core/src/test/files/LanguageSnippetTests/input-helper/types/typeAliasConstraint2.pkl` (+3 -0)
➕ `pkl-core/src/test/files/LanguageSnippetTests/input/types/typeAliasConstraint1.pkl` (+12 -0)
➕ `pkl-core/src/test/files/LanguageSnippetTests/input/types/typeAliasConstraint2.pkl` (+8 -0)
📝 `pkl-core/src/test/files/LanguageSnippetTests/output/api/string.pcf` (+4 -4)
➕ `pkl-core/src/test/files/LanguageSnippetTests/output/types/typeAliasConstraint1.pcf` (+2 -0)
➕ `pkl-core/src/test/files/LanguageSnippetTests/output/types/typeAliasConstraint2.pcf` (+3 -0)
📝 `stdlib/base.pkl` (+1 -1)
</details>
### 📄 Description
The body of a `typealias` gets inlined into wherever the `typealias` is used. This fixes a bug where the name resolution would resolve an additional type constraint on the next scope of `this`.
Lack of a frame scope
---------------------
`typealias` doesn't currently have a frame scope, which is why we have to assign the `owner` and the `receiver` here. If it did, we could read both of these at the point where we're trying to resolve the `typealias` in question.
---
<sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
📋 Pull Request Information
Original PR: https://github.com/apple/pkl/pull/144
Author: @KushalP
Created: 2/13/2024
Status: ✅ Merged
Merged: 2/15/2024
Merged by: @bioball
Base:
main← Head:fix-name-resolution-typealias-with-constraint📝 Commits (1)
bbcb5cfFix name resolution intypealiaswith constraint📊 Changes
11 files changed (+76 additions, -7 deletions)
View changed files
📝
pkl-core/src/main/java/org/pkl/core/ast/member/TypeAliasNode.java(+2 -1)📝
pkl-core/src/main/java/org/pkl/core/ast/type/TypeNode.java(+23 -0)📝
pkl-core/src/main/java/org/pkl/core/runtime/VmTypeAlias.java(+10 -1)📝
pkl-core/src/main/java/org/pkl/core/runtime/VmUtils.java(+8 -0)➕
pkl-core/src/test/files/LanguageSnippetTests/input-helper/types/typeAliasConstraint2.pkl(+3 -0)➕
pkl-core/src/test/files/LanguageSnippetTests/input/types/typeAliasConstraint1.pkl(+12 -0)➕
pkl-core/src/test/files/LanguageSnippetTests/input/types/typeAliasConstraint2.pkl(+8 -0)📝
pkl-core/src/test/files/LanguageSnippetTests/output/api/string.pcf(+4 -4)➕
pkl-core/src/test/files/LanguageSnippetTests/output/types/typeAliasConstraint1.pcf(+2 -0)➕
pkl-core/src/test/files/LanguageSnippetTests/output/types/typeAliasConstraint2.pcf(+3 -0)📝
stdlib/base.pkl(+1 -1)📄 Description
The body of a
typealiasgets inlined into wherever thetypealiasis used. This fixes a bug where the name resolution would resolve an additional type constraint on the next scope ofthis.Lack of a frame scope
typealiasdoesn't currently have a frame scope, which is why we have to assign theownerand thereceiverhere. If it did, we could read both of these at the point where we're trying to resolve thetypealiasin question.🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.