You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After the comptime interpreter inlines macro code at its callsite, the code will need to undergo name resolution and type checking. Yet the interpreter itself also needs access to type checking and thus must be after that pass.
Our current plan to resolve this is to have a loop in the compiler where after a macro is inlined, we loop back to name resolution and redo that pass and type checking for any relevant parts of the program which changed. This turned out to be non-trivial however. Most notably in converting back from the high-level IR (HIR) to the Ast since information is lost in the initial Ast -> Hir conversion done by name resolution.
Happy Case
One possible alternative is to interleave these passes together instead so that they operate in lock-step. This would be as if each pass were merged together into one larger pass which traversed the Ast only once. This way, when a macro is inserted the name resolver is still available to re-resolve the code immediately. Most importantly, the shape of the call stack is still intact so the new result can be checked against recursive call results.
This last point is important for type checking. Think of the example 3 + foo!() where foo!() inserts some macro code. When type checking this for the first time we'd see only ? for the result of foo!(). If the passes were not in lock-step, then we'd pop off the call stack and check the validity of Field + ? immediately and error. Since the passes do operate in lock-step however, the comptime interpreter will be available to immediately expand the code to e.g. 2 and update the type checker in place to return Field for that expression instead. Then, the call stack is popped and the type checker will now see Field + Field.
Project Impact
None
Impact Context
No response
Workaround
None
Workaround Description
No response
Additional Context
No response
Would you like to submit a PR for this Issue?
None
Support Needs
No response
The text was updated successfully, but these errors were encountered:
# Description
## Problem\*
Resolves#4953
## Summary\*
Adds an elaborator - a concept borrowed from dependently typed languages
- which performs name resolution and type checking simultaneously. The
new elaborator is currently disabled (inaccessible from user code) since
it is not hooked up to the `dc_crate` module.
This PR is extremely large (sorry!) but is 99% a pseudo copy-paste of
existing code from the name resolver and type checker, only slightly
adapted to be able to work in tandem. Unfortunately, this also means
that we'll need to duplicate any changes made to the name resolver &
type checker in the elaborator as well until we can remove the old name
resolution and type checking passes. For example,
#4958 will need to be integrated
into the elaborator as well.
## Additional Context
After this PR the plan is to
1. Connect the elaborator to `dc_crate`, enabling it with a command-line
option.
2. Insert logic for the comptime scanning pass in the elaborator as
well.
3. Test the elaborator against all existing tests.
4. Once it passes, we can use the elaborator by default and delete the
name resolution, type checking, and comptime scanning passes.
## Documentation\*
Check one:
- [x] No documentation needed.
- [ ] Documentation included in this PR.
- [ ] **[For Experimental Features]** Documentation to be submitted in a
separate PR.
# PR Checklist\*
- [x] I have tested the changes locally.
- [ ] I have formatted the changes with [Prettier](https://prettier.io/)
and/or `cargo fmt` on default settings.
Problem
After the comptime interpreter inlines macro code at its callsite, the code will need to undergo name resolution and type checking. Yet the interpreter itself also needs access to type checking and thus must be after that pass.
Our current plan to resolve this is to have a loop in the compiler where after a macro is inlined, we loop back to name resolution and redo that pass and type checking for any relevant parts of the program which changed. This turned out to be non-trivial however. Most notably in converting back from the high-level IR (HIR) to the Ast since information is lost in the initial Ast -> Hir conversion done by name resolution.
Happy Case
One possible alternative is to interleave these passes together instead so that they operate in lock-step. This would be as if each pass were merged together into one larger pass which traversed the Ast only once. This way, when a macro is inserted the name resolver is still available to re-resolve the code immediately. Most importantly, the shape of the call stack is still intact so the new result can be checked against recursive call results.
This last point is important for type checking. Think of the example
3 + foo!()
wherefoo!()
inserts some macro code. When type checking this for the first time we'd see only?
for the result offoo!()
. If the passes were not in lock-step, then we'd pop off the call stack and check the validity ofField + ?
immediately and error. Since the passes do operate in lock-step however, the comptime interpreter will be available to immediately expand the code to e.g.2
and update the type checker in place to returnField
for that expression instead. Then, the call stack is popped and the type checker will now seeField + Field
.Project Impact
None
Impact Context
No response
Workaround
None
Workaround Description
No response
Additional Context
No response
Would you like to submit a PR for this Issue?
None
Support Needs
No response
The text was updated successfully, but these errors were encountered: