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

Index data incomplete when referencing an ambiguous type name #64598

Closed
keith opened this issue Mar 24, 2023 · 1 comment · Fixed by #65729
Closed

Index data incomplete when referencing an ambiguous type name #64598

keith opened this issue Mar 24, 2023 · 1 comment · Fixed by #65729
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. declarations Feature: declarations expressions Feature: expressions indexing Area → source tooling: AST indexing multiple modules Flag: An issue whose reproduction requires multiple modules source tooling Area: IDE support, SourceKit, and other source tooling swift 5.9 type declarations Feature → declarations: Type declarations unexpected behavior Bug: Unexpected behavior or incorrect output

Comments

@keith
Copy link
Member

keith commented Mar 24, 2023

Description

With this code:

// Module0
public struct Thing {
    public init(string: String) {}
}
// Module1
public struct Thing {}
// Module2
import Module0
import Module1

func foo() {
    _ = Thing(string: "lol")
}

The index data for Module3 includes no references at all to Thing or the initializer being called. This is easiest to visualize with indexutil-annotate:

// Module2
/*
       module=Module0=usr is c:@M@Module0
       v  */
import Module0
/*
       module=Module1=usr is c:@M@Module1
       v  */
import Module1

/*
     function=foo()=usr is s:7Module23fooyyF
     v  */
func foo() {
    _ = Thing(string: "lol")
}

If I add the explicit module name to the call like this: _ = Module0.Thing(string: "lol") we get what appears to be the right data:

// Module2
/*
       module=Module0=usr is c:@M@Module0
       v  */
import Module0
/*
       module=Module1=usr is c:@M@Module1
       v  */
import Module1

/*
     function=foo()=usr is s:7Module23fooyyF
     v  */
func foo() {
    /*
        module=Module0=usr is c:@M@Module0
        |       struct=Thing=usr is s:7Module05ThingV
        |       constructor=init(string:)=usr is s:7Module05ThingV6stringACSS_tcfc
        v       v  */
    _ = Module0.Thing(string: "lol")
}

Also removing the import to Module1 also gives us the right info:

// Module2
/*
       module=Module0=usr is c:@M@Module0
       v  */
import Module0

/*
     function=foo()=usr is s:7Module23fooyyF
     v  */
func foo() {
    /*
        struct=Thing=usr is s:7Module05ThingV
        constructor=init(string:)=usr is s:7Module05ThingV6stringACSS_tcfc
        v  */
    _ = Thing(string: "lol")
}

Steps to reproduce

Using this project initextension.zip and indexutil-annotate:

  1. swift build
  2. indexutil-annotate .build/debug/index/store/ Sources/Module2/Module2.swift

You can also inspect the record naively with strings to see there are no other string references to Module2:

% strings $(find .build/debug/index/store/v5/records -name "Module2.swift*")
IDXR
Module0c:@M@Module0
Module1c:@M@Module1
foo()s:7Module23fooyyF

Expected behavior

The specific type should be known because the initializer disambiguates it, and that should be present in the index data.

Environment

  • Swift compiler version info 5.7.2
  • Xcode version info 14.2.14C18

I also tested with Swift @ 1b13b59

@keith keith added bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. triage needed This issue needs more specific labels labels Mar 24, 2023
@AnthonyLatsis AnthonyLatsis added source tooling Area: IDE support, SourceKit, and other source tooling swift 5.7 indexing Area → source tooling: AST indexing unexpected behavior Bug: Unexpected behavior or incorrect output multiple modules Flag: An issue whose reproduction requires multiple modules expressions Feature: expressions and removed triage needed This issue needs more specific labels labels Apr 3, 2023
keith added a commit to keith/swift that referenced this issue May 6, 2023
When you have a type that's ambiguous because it's defined in 2 imported
modules, but you don't have to disambiguate by using the module name,
previously no index references were produced. Now most are for the
common case, but notably nested type constructors and generics still
aren't emitted, partially because of swiftlang#65726

Fixes: swiftlang#64598
@keith
Copy link
Member Author

keith commented May 6, 2023

#65729

keith added a commit to keith/swift that referenced this issue May 6, 2023
When you have a type that's ambiguous because it's defined in 2 imported
modules, but you don't have to disambiguate by using the module name,
previously no index references were produced. Now most are for the
common case, but notably nested type constructors and generics still
aren't emitted, partially because of swiftlang#65726

Fixes: swiftlang#64598
@AnthonyLatsis AnthonyLatsis added overloading Feature: Overloading symbol names declarations Feature: declarations swift 5.9 type declarations Feature → declarations: Type declarations and removed swift 5.7 labels May 6, 2023
keith added a commit that referenced this issue Jun 23, 2023
When you have a type that's ambiguous because it's defined in 2 imported
modules, but you don't have to disambiguate by using the module name,
previously no index references were produced. Now most are for the
common case, but notably nested type constructors and generics still
aren't emitted, partially because of #65726

Fixes: #64598
@AnthonyLatsis AnthonyLatsis added ambiguity handling and removed overloading Feature: Overloading symbol names labels Jul 26, 2023
DougGregor pushed a commit that referenced this issue Aug 19, 2023
When you have a type that's ambiguous because it's defined in 2 imported
modules, but you don't have to disambiguate by using the module name,
previously no index references were produced. Now most are for the
common case, but notably nested type constructors and generics still
aren't emitted, partially because of #65726

Fixes: #64598

(cherry picked from commit e9ff334 / #65729)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. declarations Feature: declarations expressions Feature: expressions indexing Area → source tooling: AST indexing multiple modules Flag: An issue whose reproduction requires multiple modules source tooling Area: IDE support, SourceKit, and other source tooling swift 5.9 type declarations Feature → declarations: Type declarations unexpected behavior Bug: Unexpected behavior or incorrect output
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants