Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Introduce a new symbol resolving pass #5809

Merged
merged 9 commits into from
Aug 6, 2024

Conversation

tritao
Copy link
Contributor

@tritao tritao commented Apr 1, 2024

Description

This PR implements a new AST resolution approach that resolves symbols using the information from the collection context.

To achieve this, we introduce a new ResolveSymbols trait and SymbolResolveContext context type.

Parsed nodes now contain a resolved_call_path_binding: Option<TypeBinding<ResolvedCallPath<ParsedDeclId<...>>>>, which contain the resolved call path binding that references the ParsedDeclId relative to the resolved name. This field is resolved by the new resolve_symbols pass, which mutates the resolved_call_path_binding as it walks through the nodes.

Most of the name lookups are implemented in the new SymbolResolveTypeBinding which is equivalent to the existing TypeCheckTypeBinding (to be removed once everything is migrated in the type checker).

The only exception right now are DelineatedPath and AmbiguousPathExpression which are not being fully resolved yet (though there is a draft PR right now with some of this ongoing work).

Also to note there are a handful of unused functions in the context that will be used in the next PRs.

These are the main commits:

Implement Declaration::TraitFn.

Implement decl_engine_parsed_decl and get_parsed_decl.

Fix lexical scope id calculation on creation.

Add symbol resolve context.

Collect nodes inside each function body and keep a reference to their lexical scope

Resolve alias declarations when resolving struct symbols.

Partially closes #5379.

Checklist

  • I have linked to any relevant issues.
  • I have commented my code, particularly in hard-to-understand areas.
  • I have updated the documentation where relevant (API docs, the reference, and the Sway book).
  • I have added tests that prove my fix is effective or that my feature works.
  • I have added (or requested a maintainer to add) the necessary Breaking* or New Feature labels where relevant.
  • I have done my best to ensure that my PR adheres to the Fuel Labs Code Review Standards.
  • I have requested a review from the relevant team or maintainers.

@tritao tritao self-assigned this Apr 1, 2024
@tritao tritao added compiler General compiler. Should eventually become more specific as the issue is triaged compiler: frontend Everything to do with type checking, control flow analysis, and everything between parsing and IRgen compiler: collection Everything to do with graph collection, type collection, and the collection context. labels Apr 1, 2024
@tritao tritao force-pushed the symbol-resolve-ctx branch 6 times, most recently from dc45030 to c9679b2 Compare May 9, 2024 11:04
@tritao tritao force-pushed the symbol-resolve-ctx branch 5 times, most recently from a85e6de to 35c79b9 Compare May 16, 2024 01:50
@tritao tritao force-pushed the symbol-resolve-ctx branch 3 times, most recently from c11ad6b to e2578a1 Compare May 20, 2024 15:30
@tritao tritao force-pushed the symbol-resolve-ctx branch 5 times, most recently from ac277ac to 9f763b9 Compare July 29, 2024 13:31
@tritao tritao force-pushed the symbol-resolve-ctx branch 4 times, most recently from dfb469f to e9ca308 Compare August 2, 2024 18:04
@tritao tritao force-pushed the symbol-resolve-ctx branch 3 times, most recently from f1416ed to 2c8dc64 Compare August 4, 2024 22:18
@tritao tritao marked this pull request as ready for review August 4, 2024 22:46
@tritao tritao requested review from a team as code owners August 4, 2024 22:46
jjcnn
jjcnn previously approved these changes Aug 5, 2024
Copy link
Contributor

@jjcnn jjcnn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks fine except for a few things about the order of the recursive traversal.

There will be some merge conflicts when I merge this with my current work, but

sway-core/src/semantic_analysis/symbol_resolve.rs Outdated Show resolved Hide resolved
sway-core/src/semantic_analysis/symbol_resolve.rs Outdated Show resolved Hide resolved
sway-core/src/semantic_analysis/symbol_resolve.rs Outdated Show resolved Hide resolved
@tritao tritao requested review from jjcnn and a team August 5, 2024 15:17
@tritao tritao enabled auto-merge (squash) August 5, 2024 15:19
@tritao
Copy link
Contributor Author

tritao commented Aug 5, 2024

Pushed a new commit addressing the review feedback.

@tritao tritao merged commit 159f049 into FuelLabs:master Aug 6, 2024
39 checks passed
esdrubal pushed a commit that referenced this pull request Aug 13, 2024
## Description

This PR implements a new AST resolution approach that resolves symbols
using the information from the collection context.

To achieve this, we introduce a new `ResolveSymbols` trait and
`SymbolResolveContext` context type.

Parsed nodes now contain a `resolved_call_path_binding:
Option<TypeBinding<ResolvedCallPath<ParsedDeclId<...>>>>`, which contain
the resolved call path binding that references the `ParsedDeclId`
relative to the resolved name. This field is resolved by the new
`resolve_symbols` pass, which mutates the `resolved_call_path_binding`
as it walks through the nodes.

Most of the name lookups are implemented in the new
`SymbolResolveTypeBinding` which is equivalent to the existing
`TypeCheckTypeBinding` (to be removed once everything is migrated in the
type checker).

The only exception right now are `DelineatedPath` and
`AmbiguousPathExpression` which are not being fully resolved yet (though
there is a draft PR right now with some of this ongoing work).

Also to note there are a handful of unused functions in the context that
will be used in the next PRs.

These are the main commits:

[Implement
Declaration::TraitFn.](8da3223)

[Implement decl_engine_parsed_decl and
get_parsed_decl.](dd6f5e6)

[Fix lexical scope id calculation on
creation.](e16d996)

[Add symbol resolve
context.](e9356cc)

[Collect nodes inside each function body and keep a reference to their
lexical
scope](e327345)

[Resolve alias declarations when resolving struct
symbols.](2c8dc64)

Partially closes #5379.

## Checklist

- [x] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [x] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [x] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [x] I have added tests that prove my fix is effective or that my
feature works.
- [x] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compiler: collection Everything to do with graph collection, type collection, and the collection context. compiler: frontend Everything to do with type checking, control flow analysis, and everything between parsing and IRgen compiler General compiler. Should eventually become more specific as the issue is triaged
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Build a symbol resolution step
4 participants