[go: up one dir, main page]
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.

Sign up for GitHub

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

Default argument values aren't language agnostic #156

Open
kastiglione opened this issue May 7, 2016 · 1 comment
Open

Default argument values aren't language agnostic #156

kastiglione opened this issue May 7, 2016 · 1 comment

Comments

@kastiglione
Copy link
Contributor
kastiglione commented May 7, 2016 •
edited
Loading

Using an example to demonstrate the issue:

If paltrace is called while stopped in some swift code, the user would expect to be able to run paltrace someValidSwiftExpression. As such, paltrace should interpret input based on the active language at a breakpoint. However, the paltrace command has a default view of (id)[[UIApplication sharedApplication] keyWindow], but this expression would have to be evaluated as objc.

The solution that seems to strike the right balance to me is:

Remove the ability for commands to declare defaults in fb.FBCommandArgument, which would force commands to knowingly handle a default.

Other possibilities are:

  1. Allow commands a way to check if an argument was provided by a default
  2. Use a heuristic to recognize when a value is swift or objc
  3. Use a known "keyword" for the default

The second option would be nice to have in general, and could be desirable in addition to whatever solution chosen for handling defaults.
@DerekSelander
Copy link

Another (partial) possibility to add to the table:

SBFunction has the GetLanguage() method. You can figure out which context you are from there.
Easy way to test: Break in a swift method:

(lldb) script lldb.frame.function.GetLanguage() == lldb.eLanguageTypeSwift
True

Breaking out of the blue gives you lldb.eLanguageTypeUnknown and of course there is lldb.eLanguageTypeObjC

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@kastiglione @DerekSelander