You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
funinfinityLoop() {
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
The text was updated successfully, but these errors were encountered:
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.
* 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
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
Expected behavior
A exception instead stopping the execution.
Additional context
The text was updated successfully, but these errors were encountered: