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

Jump to bottom

[SR-3886] error: use of undeclared type '$__lldb_context' in NSAttributedString extension #4395

Closed
ZevEisenberg opened this issue Feb 7, 2017 · 9 comments
Closed

[SR-3886] error: use of undeclared type '$__lldb_context' in NSAttributedString extension #4395

ZevEisenberg opened this issue Feb 7, 2017 · 9 comments
Assignees
@dcci
Labels
bug Something isn't working LLDB for Swift

Comments

@ZevEisenberg
Copy link

Previous ID SR-3886
Radar rdar://problem/35003001
Original Reporter @ZevEisenberg
Type Bug
Status Resolved
Resolution Done
Additional Detail from JIRA
Votes 10
Component/s LLDB for Swift
Labels Bug
Assignee @dcci
Priority Medium

md5: a81c62211da4f94aa7a4e278d511c5af

Issue Description:

Given the following Swift code, saved in bug.swift, and using Xcode 8.2.1 or Xcode 8.3 beta 2:

import Foundation

protocol MyProtocol {
    func foo() -> String
}

extension MyProtocol {
    func foo() -> String {
        return "\(self)"
    }
}

extension String: MyProtocol {}
extension NSAttributedString: MyProtocol {}

let normal = "normal".foo()
let attributed = NSAttributedString(string: "attributed", attributes: [:]).foo()

Run the following commands:

swiftc -g bug.swift
lldb bug

LLDB launches. Now, run these commands, and observe the output. Where I pass 9, pass the line in your bug.swift that contains return "\(self)":

(lldb) target create "bug"
Current executable set to 'bug' (x86_64).
(lldb) b 9
Breakpoint 1: where = bug`(extension in bug):bug.MyProtocol.foo () -> Swift.String + 19 at bug.swift:9, address = 0x0000000100001e53
(lldb) run
Process 16370 launched: '/Users/zev/Desktop/bug' (x86_64)
Process 16370 stopped
* thread #​1: tid = 0x31730e, 0x0000000100001e53 bug`MyProtocol.foo(self="normal") -> String + 19 at bug.swift:9, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
    frame #​0: 0x0000000100001e53 bug`MyProtocol.foo(self="normal") -> String + 19 at bug.swift:9
   6    
   7    extension MyProtocol {
   8        func foo() -> String {
-> 9            return "\(self)"
   10       }
   11   }
   12   
(lldb) po self
"normal"


(lldb) c
Process 16370 resuming
Process 16370 stopped
* thread #​1: tid = 0x31730e, 0x0000000100001e53 bug`MyProtocol.foo(self=0x00007fff5fbff480) -> String + 19 at bug.swift:9, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
    frame #​0: 0x0000000100001e53 bug`MyProtocol.foo(self=0x00007fff5fbff480) -> String + 19 at bug.swift:9
   6    
   7    extension MyProtocol {
   8        func foo() -> String {
-> 9            return "\(self)"
   10       }
   11   }
   12   
(lldb) po self
error: <EXPR>:1:11: error: use of undeclared type '$__lldb_context'
extension $__lldb_context {                            
          ^~~~~~~~~~~~~~~

error: <EXPR>:18:5: error: use of unresolved identifier '$__lldb_injected_self'
    $__lldb_injected_self.$__lldb_wrapped_expr_2(     
    ^~~~~~~~~~~~~~~~~~~~~

The first time we hit the breakpoint, we're in String's conformance to MyProtocol, and we can successfully po self.

However, the second time we hit the breakpoint, we're in NSAttributedString's conformance to MyProtocol, and LLDB prints gibberish instead of the expected output from po self.

This is a contrived example, but I run into this all the time in my day-to-day use of Swift and LLDB.
@belkadan
Copy link

belkadan commented Feb 7, 2017

cc jingham@apple.com (JIRA User), nicely-reduced test case here.

@ZevEisenberg
Copy link
Author

I just tested this in Xcode 9 beta 2, and the bug is still there, but there is slightly different output now. It mentions that mutating isn't valid on methods or in classes or class-bound protocols, but I'm not using mutating in my sample code:

(lldb) po self
error: <EXPR>:3:3: error: 'mutating' isn't valid on methods in classes or class-bound protocols
  mutating func $__lldb_wrapped_expr_2(_ $__lldb_arg : UnsafeMutablePointer<Any>) {
  ^~~~~~~~~
  

warning: <EXPR>:12:9: warning: initialization of variable '$__lldb_error_result' was never used; consider replacing with assignment to '_' or removing it
    var $__lldb_error_result = __lldb_tmp_error
    ~~~~^~~~~~~~~~~~~~~~~~~~
    _

@keith
Copy link

keith commented Jul 24, 2017

I came here to file this with the exact same test case. I assume this wouldn't be a beginner bug, but if there's a place I could start looking at this I'd be up for it!

@keith
Copy link

keith commented Oct 16, 2017

Filed a super similar bug here: https://bugs.swift.org/browse/SR-6156

@slavapestov
Copy link
Member

@swift-ci create

@keith
Copy link

keith commented Dec 23, 2017

I dug into this a bit, so unlike SR-6156, this specific error seems to only affect when the protocol extension is conformed to by an Objective-C class. In this case the `self_type` here is `Self`, so after that I think everything is pretty much borked. Similar to SR-6156, you can see this same problem show up when just running `fr v`

(lldb) fr v
(Self) self = 0x00007fff5fbfed70

I'm not exactly sure where to solve this part, if anyone else has any guidance that would be greatly appreciated!

@adellibovi
Copy link

Same thing happening for me, also with the latest beta 10b3. Anything we could do? It's bit of a pain when debugging project with both Obj-c and Swift. Maybe there is a way to force the type of `self` of lldb?

@dcci
Copy link
Mannequin

dcci mannequin commented Oct 15, 2018

Looking at this. So, the first bug here is that lldb doesn't resolve the dynamic type correctly in the second case.
This is because lldb doesn't really know about `MetadataKind::ObjCClassWrapper` in the dynamic type resolution code, and needs to be taught about it.

I have a local patch were I taught swift-lldb about it, but now we fail in the compiler trying to create the ObjC type for the class (in ClangImporter). I need to look at that, but it might take some time.

@slavapestov
Copy link
Member

This was fixed at some point. I added a test case - apple/swift-lldb#1346

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
@shahmishal shahmishal transferred this issue from apple/swift May 5, 2022
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@dcci dcci

Labels
bug Something isn't working LLDB for Swift
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@slavapestov @adellibovi @keith @ZevEisenberg @belkadan