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

Load other shapes when a mixin can't be resolved #2214

Conversation

milesziemer
Copy link
Contributor

Found this when working on the language server - if you have a model like:

$version: "2"

namespace com.foo

string Foo

@mixin
structure Bar {}

structure Baz with [Unknown] {}

loading it will result in Foo and Bar also not being loaded. It seems like the reason for this was that if TopologicalShapeSort failed, we wouldn't build any shapes into the model, despite TopologicalShapeSort being able to resolve some shapes.

Practically speaking I'm not sure if this means much in general, but for the language server its big because without it, you can't have mixin completions unless you either don't reload the model on changes (which means you can't type a mixin, then get completions to use it), or don't update the server's version of the model if the new version is broken (which reduces the quality of diagnostics, and has the same issue as the other way).


By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Found this when working on the language server - if you have a model
like:
```
$version: "2"

namespace com.foo

string Foo

@mixin
structure Bar {}

structure Baz with [Unknown] {}
```
loading it will result in `Foo` and `Bar` also not being loaded.
It seems like the reason for this was that if TopologicalShapeSort
failed, we wouldn't build _any_ shapes into the model, despite
TopologicalShapeSort being able to resolve some shapes.

Practically speaking I'm not sure if this means much in general,
but for the language server its big because without it, you
can't have mixin completions unless you either don't reload the
model on changes (which means you can't type a mixin, then get
completions to use it), or don't update the server's version
of the model if the new version is broken (which reduces the
quality of diagnostics, and has the same issue as the other way).
@kstich kstich merged commit fda4e62 into smithy-lang:main Mar 27, 2024
13 checks passed
This pull request was closed.
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.

3 participants