fix(compiler): cannot bring modules more than once

[Chriscbr]

Refactors how the Wing compiler handles bring for local Wing files in order to support more complex bring use cases, like allowing multiple files to bring the same module.

The high level implementation approach is instead of generating a single, monolithic AST, we augment the parser so that after a Wing source file is parsed, an isolated AST and a list of dependent Wing files is produced. Using this, we can write a function that parses an entire Wing program given an entrypoint, and use the petgraph crate to produce topological ordering of the files for type checking, and each AST is independently type checked.

While this unblocks several use cases, there are still some limitations. For example, consider how it's possible for classes to recursively reference each other in TypeScript:

// foo.ts
import * as bar from "./bar";

export class Foo {
  constructor(public bar: bar.Bar | undefined) {}
}

new Foo(new bar.Bar(new Foo(undefined)));


// bar.ts
import * as foo from "./foo";

export class Bar {
  constructor(public foo: foo.Foo | undefined) {}
}

This doesn't work in Wing currently because each file is still type checked independently. To relax this constraint, we would need to perform symbol resolution on all files first (to identify all available types and members) before performing type checking. This kind of refactoring would be pretty large and is out of scope for this PR.

Fixes #3511
Fixes #3578
Fixes #3509

Checklist

• Title matches Winglang's style guide
• Description explains motivation and solution
• Tests added (always)
• Docs updated (only required for features)
• Added pr/e2e-full label if this feature requires end-to-end testing

By submitting this pull request, I confirm that my contribution is made under the terms of the Wing Cloud Contribution License.

[yoav-steinberg]

Amazing!

[Chriscbr]

I was wondering if maybe entrypoint files should have the .main.w suffix (and also main.w).

Thoughts?

+1 from me. I think a convention based on the file name seems pretty good as far as options go. Since most source files in larger Wing projects will be non-entrypoint files, I think any extra rules or annotations required from the user should be added to the entrypoint files, not the non-entrypoint files - if that makes any sense.

[mergify]

Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).

[monadabot]

Congrats! 🚀 This was released in Wing 0.24.53.

[skyrpex]

Hey, this PR caused an issue in the LSP. We had to revert Learn and Play to a previous version.

See the Slack convo https://winglang.slack.com/archives/C04QQD2SDM2/p1690534520811589.

We'll have to revert this PR or fix whatever problem there is.

[ShaiBer]

Let's revert for now so newer releases will not break the playground again

[skyrpex]

Here's the revert PR #3641