Create an account

Very important

  • To access the important data of the forums, you must be active in each forum and especially in the leaks and database leaks section, send data and after sending the data and activity, data and important content will be opened and visible for you.
  • You will only see chat messages from people who are at or below your level.
  • More than 500,000 database leaks and millions of account leaks are waiting for you, so access and view with more activity.
  • Many important data are inactive and inaccessible for you, so open them with activity. (This will be done automatically)


Thread Rating:
  • 341 Vote(s) - 3.54 Average
  • 1
  • 2
  • 3
  • 4
  • 5
`po` gives `error: <EXPR>:1:1: error: use of unresolved identifier`

#1
I have this problem with `po` in the console where trying to output a function works in itself, but outputting a variable or constant doesn't.

![first result is for `po bar.boy()`, second says `unresolved`][1]


[1]:

As you can see here, although you'd think the var/let holds the content of `bar.boy()`, Swift somehow can't find it...
Reply

#2
For those who are using Swift framework in an Objective-c project, and wanna debug the Swift source files in that project: (In my case, I have a mixed-language module which managed by Cocoapods, I need to debug the swift module in my Objective-c Example project)

It works for me after I **added an Empty Swift file in my Objective-c project.**


Otherwise, those swift compiler options won't show up in the Build Settings.

[![enter image description here][1]][1]


[1]:
Reply

#3
I encountered a similar issue but I already had the correct configuration, all optimisations set to `None`. However I still didn't get any values.

After some further digging I found out that the issue originated from Xcode being unable to the resolve the types:

(lldb) frame variable self
<could not resolve type>

That led me to this question:

[To see links please register here]

where the issue is described and the bridging header seems to cause issues.

With my project not having any bridging headers I studied the build settings once more and found this setting

![setting[1]][1]

This was initally set to `YES`. After changing the it to `NO` symbols are working again.

`SWIFT_INSTALL_OBJC_HEADER = NO`




[1]:
Reply

#4
If your project is using Swift, there are two separate "Optimization Level" settings in the project/target configuration. Its not only "SWIFT_OPTIMIZATION_LEVEL". Check this link:

[To see links please register here]


I'll leave it here in case it's useful to someone.
Reply

#5
Fixed after setting:

```Optimization Level = None[-Onone]``` under **Swift Compiler - Code Generation**

Note that setting `Optimization Level` under **Apple LLVM 8.0 - Code Generation** has no effect
Reply

#6
I set **Swift Complier** to "-O"

SWIFT_OPTIMIZATION_LEVEL = "-O";
and set it back to "-Onone".

SWIFT_OPTIMIZATION_LEVEL = "-Onone";

Then it works.
Reply

#7
So it turns out there was probably a bug in the past that when you were adding a Swift file it would add/ask a Bridging header, but it wouldn't add that line to your project

SWIFT_OPTIMIZATION_LEVEL = "-Onone";

which means you'd stay in this state

![SWIFT_OPTIMIZATION_LEVEL fastest][1]

resulting in `error: <EXPR>:1:1: error: use of unresolved identifier`!

I could only find that out because I moved around files in my project and when I added ObjC files to the project, it asked me about a Bridging header (although I had one already!) and luckily added that `SWIFT_OPTIMIZATION_LEVEL`. One could consider this is a bug to consider the default value is `fastest`, but then again I guess this was only a bug in the past and got fixed now.

Still, I fixed now it might be a bug the other way around, if it add `none` in the release build. I can't test this right now because for testing this I only had a `Debug` build. I'll leave that as an exercise :) for Apple's Engineers.

[1]:
Reply

#8
I bet that bug is due to the fact that `foo` has been optimized out during compilation and it's symbol does not exist anymore in the compiled code (even if it shouldn't have in debug and it's still an LLDB bug)

Probably if you add some usage of `foo` in the next lines (even a println) its symbol will hopefully be kept in the IR and you'll be able to `po foo`

(I agree that that's still a bug but at least if it works you'll have a workaround and some sense of explanation)
Reply



Forum Jump:


Users browsing this thread:
1 Guest(s)

©0Day  2016 - 2023 | All Rights Reserved.  Made with    for the community. Connected through