Add partiql-types and literals typing
#389
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
6c0c65e to
4dd0c77
Compare
Conformance comparison report
Number passing in both: 379 Number failing in both: 13 Number passing in Base (67777c2) but now fail: 0 Number failing in Base (67777c2) but now pass: 0 |
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## main #389 +/- ##
==========================================
- Coverage 81.97% 81.57% -0.41%
==========================================
Files 55 56 +1
Lines 14370 14640 +270
Branches 14370 14640 +270
==========================================
+ Hits 11780 11942 +162
- Misses 2108 2198 +90
- Partials 482 500 +18
☔ View full report in Codecov by Sentry. |
148a11b to
698b8bc
Compare
This is the first commit to introduce types to `partiql-lang-rust`. With the changes in this commit, we're introducing `partiql-types` create which includes the initial model for our built-in types. We also introduce an `AstTyper` in `partiql-ast-passes` which provides an API for receiving `partiql-ast` and outputting a mapping from AST Node Ids to their corresponding types. In the first version, we're loosely typing the literal with the expection that this goes through multiple iterations. Here is the high-level plan: [ ] Type literals [ ] Type variable references in SFW [ ] Type operators [ ] Type using schemas in typing environment [ ] Add type coercions (using a Type Lattice?) [ ] Update CHANGELOG.md and adh documentation
partiql-types and literals typingpartiql-types and literals typing
jpschorr
approved these changes
Jun 14, 2023
am357
added a commit
that referenced
this pull request
Jun 14, 2023
Addressing the comment in PR #389, this PR re-uses the `AstTypeMap` for `LocationMap` which removes a dependency to `HashMap` as `AstTypeMap` uses `IndexMap`.
am357
added a commit
that referenced
this pull request
Jun 14, 2023
Addressing the comment in PR #389, this PR re-uses the `AstTypeMap` for `LocationMap` which removes a dependency to `HashMap` as `AstTypeMap` uses `IndexMap`.
am357
added a commit
that referenced
this pull request
Aug 16, 2023
During the work for adding a steel thread for PartiQL Typing (Recent PR #389) and after merging #410 to `feat-type-plan-poc` it is realized that we need to refactor the code to remove `DynamicLocalup` `VarExpr` with the assumption that we work based off of Typing and Value Environment from the Catalog. We have a Typing Environment in the Catalog at the moment and we are going to add the Variable Environment as well. In preparation for such task, we need to make the `NameResolver` Catalog aware. In that regard this commit adds the `Catalog` to `NameResolver` Expecting subsequent PR(s) for the name resolving using the Catalog.
am357
added a commit
that referenced
this pull request
Aug 16, 2023
During the work for adding a steel thread for PartiQL Typing (Recent PR #389) and after merging #410 to `feat-type-plan-poc` it is realized that we need to refactor the code to remove `DynamicLocalup` `VarExpr` with the assumption that we work based off of Typing and Value Environment from the Catalog. We have a Typing Environment in the Catalog at the moment and we are going to add the Variable Environment as well. In preparation for such task, we need to make the `NameResolver` Catalog aware. In that regard this commit adds the `Catalog` to `NameResolver` Expecting subsequent PR(s) for the name resolving using the Catalog.
am357
added a commit
that referenced
this pull request
Aug 16, 2023
During the work for adding a steel thread for PartiQL Typing (Recent PR #389) and after merging #410 to `feat-type-plan-poc` it is realized that we need to refactor the code to remove `DynamicLocalup` `VarExpr` with the assumption that we work based off of Typing and Value Environment from the Catalog. We have a Typing Environment in the Catalog at the moment and we are going to add the Variable Environment as well. In preparation for such task, we need to make the `NameResolver` Catalog aware. In that regard this commit adds the `Catalog` to `NameResolver` Expecting subsequent PR(s) for the name resolving using the Catalog.
am357
added a commit
that referenced
this pull request
Aug 16, 2023
During the work for adding a steel thread for PartiQL Typing (Recent PR #389) and after merging #410 to `feat-type-plan-poc` it is realized that we need to refactor the code to remove `DynamicLocalup` `VarExpr` with the assumption that we work based off of Typing and Value Environment from the Catalog. We have a Typing Environment in the Catalog at the moment and we are going to add the Variable Environment as well. In preparation for such task, we need to make the `NameResolver` Catalog aware. In that regard this commit adds the `Catalog` to `NameResolver` Expecting subsequent PR(s) for the name resolving using the Catalog.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description of changes:
This is the first PR to introduce types to
partiql-lang-rust. With the changes in this PR, we're introducingpartiql-typeswhich includes the initial model for our built-in types. We also introduce anAstStaticTyperinpartiql-ast-passeswhich provides an API for receiving anast::AstNodeand outputting a mapping from AST Node Ids to their corresponding types.In the first version, we're loosely typing the literals with the expectation that this goes through multiple iterations.
We're moving the custom type support out of the scope at this stage.
Here is the high-level plan:
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.