[llvm-bugs] [Bug 44579] New: Swift Framework returns 'ambiguous use of' method extension in lldb

via llvm-bugs llvm-bugs at lists.llvm.org
Fri Jan 17 06:05:28 PST 2020


            Bug ID: 44579
           Summary: Swift Framework returns 'ambiguous use of' method
                    extension in lldb
           Product: lldb
           Version: unspecified
          Hardware: PC
                OS: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: All Bugs
          Assignee: lldb-dev at lists.llvm.org
          Reporter: alexis.lefevre at yahoo.com
                CC: jdevlieghere at apple.com, llvm-bugs at lists.llvm.org

Apple Swift version 5.1 (swiftlang-1100.0.270.13 clang-1100.0.33.7)

I've upgraded to Xcode 11 & swift 5, and hit an an issue with method extensions
when they are made available through a framework. More specifically, in a
project structured like this:

-> Main Project
-> Framework created from sources in 'Main Project'
-> Subproject using the above Framework (Sources packaged in the framework are
not visible to the sub-project)
Everything compiles and runs fine, but when running debug sessions on the
subproject, all extensions in 'Framework' return error: ambiguous use of when
invoked from the lldb command line. Here is a code sample to give an idea:

Create a macOs command line project, and add a new target, 'MagicFramework',
and in a file Spells.swift (make sure the file is visible to Main &

import Foundation

extension String {
    public func castSpell() -> String {
        return "✨ " + self
Then create a subproject 'Wizard', and in a file wizard.swift (visible to
Wizard only):

import Foundation
import MagicFramework

public class Tadaa {

    public func magic(spell:String) -> String {
        return spell.castSpell()

in Wizard's main.swift file, add:

import Foundation

let aa = Tadaa().magic(spell: "this is magic")

You should have the following structure:

-> Main project
----> MagicFramework
----> Wizard subproject
then build&run 'Wizard' sub, with a break point on spell.castSpell() in Tadaa.
At the lldb prompt, type:

(lldb)po spell.castSpell()
error: <EXPR>:3:1: error: ambiguous use of 'castSpell()'

(lldb) image lookup -vn castSpell
1 match found in
        Address: MagicFramework[0x0000000000000ab0]
(MagicFramework.__TEXT.__text + 0)
        Summary: MagicFramework`(extension in
MagicFramework):Swift.String.castSpell() -> Swift.String at Spells.swift:12
         Module: file =
arch = "x86_64"
    CompileUnit: id = {0x00000000}, file =
"/Users/lameyl01/tmp/Main/MagicFramework/Spells.swift", language = "swift"
       Function: id = {0x100000038}, name = "(extension in
MagicFramework):Swift.String.castSpell() -> Swift.String", mangled =
"$sSS14MagicFrameworkE9castSpellSSyF", range =
       FuncType: id = {0x100000038}, byte-size = 8, decl = Spells.swift:12,
compiler_type = "() -> ()"
         Blocks: id = {0x100000038}, range = [0x10033fab0-0x10033fb21)
      LineEntry: [0x000000010033fab0-0x000000010033fabf):
         Symbol: id = {0x00000005}, range =
[0x000000010033fab0-0x000000010033fb21), name="(extension in
MagicFramework):Swift.String.castSpell() -> Swift.String",
       Variable: id = {0x100000055}, name = "self", type = "Swift.String",
location = DW_OP_fbreg(-16), decl = Spells.swift:12

So that means that lldb has found exactly one match: The extension in the
MagicFramework library. So there is no reason why this should be ambiguous.

For the sake of completeness I also checked the type of the variable spell as
llbd sees it:

(lldb) frame variable spell
(String) spell = "this is magic"
So to summarize: lldb knows the type is String. It knows that there is a
function castSpell defined in the extension and it knows of exactly one
implementation of said function. But still it shows the error message.

So unless I'm missing something essential here, this must be a lldb bug.

from source:

You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20200117/01c6c2cd/attachment.html>

More information about the llvm-bugs mailing list