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

Spurious [?] circularity error in getter with spread #48178

Closed
RyanCavanaugh opened this issue Mar 8, 2022 · 4 comments
Closed

Spurious [?] circularity error in getter with spread #48178

RyanCavanaugh opened this issue Mar 8, 2022 · 4 comments
Labels
Needs Investigation This issue needs a team member to investigate its status.
Milestone

Comments

@RyanCavanaugh
Copy link
Member

Bug Report

πŸ”Ž Search Terms

circularity getter

πŸ•— Version & Regression Information

  • This is the behavior in every version I tried

⏯ Playground Link

Playground link with relevant code

πŸ’» Code

type Box = {
  content?: Foo | Box
};
declare const b: Box;
class Foo {
  get foo() {
    return {
      content: this as Foo | Box,
      ...b
    };
  }
}

πŸ™ Actual behavior

Circularity error on 'foo' when this is probably deferrable

πŸ™‚ Expected behavior

No circularity error

Ref. #46981

@RyanCavanaugh RyanCavanaugh added the Needs Investigation This issue needs a team member to investigate its status. label Mar 8, 2022
@RyanCavanaugh RyanCavanaugh added this to the Backlog milestone Mar 8, 2022
@Andarist
Copy link
Contributor

Andarist commented Feb 20, 2023

The problem comes from within the checkAccessorDeclaration and the getTypeOfAccessors call in it.

This starts a type resolution that ends up with a cycle because getSpreadType tries to create a union of the left type and the right type here. The problem is that this is a subject of subtype union reduction and this find(getPropertiesOfType(source), p => isUnitType(getTypeOfSymbol(p))) leads to requesting the get foo's type while we are still resolving it.

Probably there is a way to defer this but it's not that easy at the moment. Usually, unannotated getters should participate in this find.

@RyanCavanaugh
Copy link
Member Author

Not an error anymore

@Andarist
Copy link
Contributor

Andarist commented Mar 4, 2024

Bisected to f218a56...1df5717 and confirmed that it was fixed by #53413

@jakebailey
Copy link
Member

Oh what, that PR should have only been a perf optimization, not a behavior change...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Needs Investigation This issue needs a team member to investigate its status.
Projects
None yet
Development

No branches or pull requests

3 participants