Skip to content

Conversation

sauclovian-g
Copy link
Contributor

Closes #2605.

Note that it now accepts import submodule and stuffs the existence of the word submodule into the Import record, but doesn't do anything with it; @mtullsen I expect you have places to hook that up to in your code.


%token
'import' { TReserved _ "import" }
'submodule' { TReserved _ "submodule" }
Copy link
Contributor

Choose a reason for hiding this comment

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

Surely we should have a test case that exercises this new bit of the parser?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We should, but I left it off for now because it's going to interact with Mark's branches. There's basically three options:

  1. Merge this now, rebase all of Mark's code on it, add code there to recognize the submodule tag when processing the import, add a test there.

  2. Merge Mark's code first, rebase this on it, add code here to recognize the submodule tag when processing the import, add a test here.

  3. Merge both independently, then do another branch that adds the code to recognize the submodule tag when processing the import along with a test.

For various reasons (3) seems preferable...

Copy link
Contributor Author

Choose a reason for hiding this comment

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

(Contributing factor: nothing new should be needed on Mark's side to be able to handle the qualified names; that was purely a parser limitation)

Copy link
Contributor

Choose a reason for hiding this comment

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

Ah, I see. Should I understand that this just makes the parser recognize the submodule syntax, but doesn't actually do anything semantically meaningful with it?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes.

@sauclovian-g
Copy link
Contributor Author

(rebased on master since we merged #2562)

@mtullsen do you want to attend to making the import submodule syntax DTRT or do you want me to? (in the latter case you'll have to tell me what to do though)

- allow the word "submodule" (it is currently ignored, but that will
  likely change soon)

- allow the import name to be qualified (as in "...as M::N")

Add a test for the latter part.
The build failure seen earlier today is almost certainly cache
corruption.

Note that the 1.4 branch is using cache version 11; it's probably best
to not try to share.
@sauclovian-g
Copy link
Contributor Author

(this force-push to fix test_sawscript_builtins)

@sauclovian-g sauclovian-g merged commit 83dd3c8 into master Sep 18, 2025
37 checks passed
@sauclovian-g sauclovian-g deleted the 2605-import-syntax branch September 18, 2025 14:50
sauclovian-g added a commit that referenced this pull request Sep 22, 2025
The backend for this is apparently already hooked up and works.
Mostly resolves #2632, apart from some lingering questions about weird
pathname search failures.

Include a changelog entry and also add the missing changelog entry
for #2607 (the previous import syntax changes).
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.

Change import as to allow a qualified module name (e.g., "Q::R")
2 participants