Skip to content

[lldb] Create "task" alias for "language swift task"#10275

Closed
kastiglione wants to merge 4 commits intostable/20240723from
dl/lldb-Create-task-alias-for-language-swift-task
Closed

[lldb] Create "task" alias for "language swift task"#10275
kastiglione wants to merge 4 commits intostable/20240723from
dl/lldb-Create-task-alias-for-language-swift-task

Conversation

@kastiglione
Copy link
Copy Markdown

@kastiglione kastiglione commented Mar 17, 2025

Make the task subcommands to be convenient by adding an alias for language swift task.

@kastiglione kastiglione requested a review from a team as a code owner March 17, 2025 20:24
@kastiglione
Copy link
Copy Markdown
Author

@swift-ci test

@kastiglione
Copy link
Copy Markdown
Author

@swift-ci test

@kastiglione
Copy link
Copy Markdown
Author

@swift-ci test

@kastiglione
Copy link
Copy Markdown
Author

@swift-ci test

@kastiglione
Copy link
Copy Markdown
Author

@swift-ci test macOS

@adrian-prantl
Copy link
Copy Markdown

The alternative would be and alias swift = language swift, then you'd type swift task.
@JDevlieghere Do you have any strong opinions against this patch as is?

@JDevlieghere
Copy link
Copy Markdown

I like Adrian's suggestion. Can we implement this generically so it can go upstream and work for any language plugin?

@kastiglione
Copy link
Copy Markdown
Author

I thought about it, and wondered whether there are people would there who have a swift alias of their own, which would conflict with a builtin swift alias. Other than that, I'm neutral.

@kastiglione
Copy link
Copy Markdown
Author

kastiglione commented Mar 18, 2025

Is there room for both? Would having all the task commands be 3 levels deep (ex swift task backtrace <addr>) instead of 2 (task backtrace <addr>) lead to people using it less?

@kastiglione
Copy link
Copy Markdown
Author

On one hand, for people work with swift, swift task is redundant. This is relevant now.

However if/when lldb supports a task that's different from swift, then task alone becomes ambiguous. Unclear when this concern becomes relevant.

@adrian-prantl
Copy link
Copy Markdown

I like Adrian's suggestion. Can we implement this generically so it can go upstream and work for any language plugin?

Given that we only got ~3 plugins I'm not sure that is a good trade-off?

@adrian-prantl
Copy link
Copy Markdown

An even wilder suggestion would be to change the name lookup rules such that all the subcommands of language $frame.GetLanguage() automatically are made available as top-level commands.

for reference:

(lldb) help language
...
      cplusplus -- Commands for operating on the C++ language runtime.
      objc      -- Commands for operating on the Objective-C language runtime.
      swift     -- A set of commands for operating on the Swift Language
                   Runtime.
(lldb) help language cplusplus
...
      demangle -- Demangle a C++ mangled name.
(lldb) help language objc
...
      class-table    -- Commands for operating on the Objective-C class table.
      tagged-pointer -- Commands for operating on Objective-C tagged pointers.
(lldb) help language swift
...
      demangle -- Demangle a Swift mangled name
      refcount -- Inspect the reference count data for a Swift object  Expects
                  'raw' input (see 'help raw-input'.)

@kastiglione
Copy link
Copy Markdown
Author

An even wilder suggestion would be to change the name lookup rules such that all the subcommands of language $frame.GetLanguage() automatically are made available as top-level commands.

llvm#136766

@kastiglione
Copy link
Copy Markdown
Author

closing in favor of #10755

@kastiglione kastiglione deleted the dl/lldb-Create-task-alias-for-language-swift-task branch May 28, 2025 18:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants