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

Infinity loop/block when a MemberName is used with isExtension=true and isExtension=false #1907

Closed
hfhbd opened this issue May 14, 2024 · 0 comments · Fixed by #1909
Closed
Labels

Comments

@hfhbd
Copy link
Contributor

hfhbd commented May 14, 2024

Describe the bug
Calling toString/CodeWriter.withCollectedImports and wrong MemberName causes some internal infinity loop without any hints what's wrong and why the execution blocks.

To Reproduce

@Test
fun infinityLoop() {
  val file = FileSpec.builder("foo.bar", "Foo")
  val function = FunSpec.builder("Bar")

  function.addCode(
    "%M%M",
    MemberName("foo.bar.baz", "a"),
    MemberName("foo.bar.baz", "a", isExtension = true),
  )

  file.addFunction(function.build())
  val fileSpec = file.build()
  assertEquals("", fileSpec.toString())
}

Expected behavior
A exception instead stopping the execution.

Additional context

@hfhbd hfhbd added the bug label May 14, 2024
Egorand added a commit that referenced this issue May 19, 2024
MemberName imports were modeled after TypeName imports, where an
import can only represent a single fully-qualified name. However
with MemberNames, a single import can represent multiple
overloaded members that share a fully-qualified name. While
overloaded members can be represented with a single MemberName, we
distinguish between extension and non-extension members, and their
MemberNames are not equal. We'll currently try to generate import
aliases in this case, which is incorrect, and actually impossible,
since they have the exact same fully-qualified name (see #1907).
This change handles this scenario and adds support for having a
single import generated for multiple MemberNames.
Egorand added a commit that referenced this issue May 20, 2024
* Support generating a single import for overloaded MemberNames

MemberName imports were modeled after TypeName imports, where an
import can only represent a single fully-qualified name. However
with MemberNames, a single import can represent multiple
overloaded members that share a fully-qualified name. While
overloaded members can be represented with a single MemberName, we
distinguish between extension and non-extension members, and their
MemberNames are not equal. We'll currently try to generate import
aliases in this case, which is incorrect, and actually impossible,
since they have the exact same fully-qualified name (see #1907).
This change handles this scenario and adds support for having a
single import generated for multiple MemberNames.

* Update changelog
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant