Skip to content

Parse text format for compact import sections#8925

Merged
tlively merged 7 commits into
mainfrom
compact-imports-text
Jul 24, 2026
Merged

Parse text format for compact import sections#8925
tlively merged 7 commits into
mainfrom
compact-imports-text

Conversation

@tlively

@tlively tlively commented Jul 22, 2026

Copy link
Copy Markdown
Member

Update the parser for imports to support both forms of compact imports. Because imports are no longer 1:1 with import statements, the locations of imported items the parser collects and re-parses in various phases must now be the locations of importdesc productions rather than import productions.

Update the parser for imports to support both forms of compact imports. Because imports are no longer 1:1 with import statements, the locations of imported items the parser collects and re-parses in various phases must now be the locations of importdesc productions rather than import productions. Since e.g. a function importdesc cannot be differentiated from a function definition with an empty body without context, we must add a mechanism for the parser context to tell the parser whether or not it is parsing an import.
@tlively
tlively requested a review from a team as a code owner July 22, 2026 01:41
@tlively
tlively requested review from aheejin and removed request for a team July 22, 2026 01:41
@tlively
tlively marked this pull request as draft July 22, 2026 17:16
@tlively

tlively commented Jul 22, 2026

Copy link
Copy Markdown
Member Author

Converting to draft for now; I think we need a cleaner way for the parser to know whether it's looking at an importdesc or an inline import in the "parse module types" phase.

tlively added 2 commits July 22, 2026 17:09
When e.g. a function is declared in the text format, it can either be with a normal `func` production (which may or may not have an inline import declaration) or it can be an `import` production. Previously the parser would just store the location of the declaration but not the kind of production it used. In later parser phases where the declaration has to be parsed again, we would just try both productions to see which one worked. This is rather hacky and brittle and will not play nicely with the text format for compact imports, so refactor to explicitly track how the declaration should be parsed.
@tlively
tlively changed the base branch from main to prefactor-compact-imports-text July 23, 2026 01:50
@tlively
tlively marked this pull request as ready for review July 23, 2026 01:50
@tlively

tlively commented Jul 23, 2026

Copy link
Copy Markdown
Member Author

Initial refactoring done in #8931. This is ready for review.

Base automatically changed from prefactor-compact-imports-text to main July 23, 2026 17:50
@@ -0,0 +1,77 @@
;; NOTE: Assertions have been generated by update_lit_checks.py --all-items and should not be edited.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

  • How about adding a case that doesn't have an ID, because the code covers it?
  • When do we print the items in the compact way?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Good idea, will add a case with no ID. So far we never print compact imports.

@tlively
tlively enabled auto-merge (squash) July 24, 2026 17:58
@tlively
tlively merged commit 2e03566 into main Jul 24, 2026
16 checks passed
@tlively
tlively deleted the compact-imports-text branch July 24, 2026 18:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants