Hi lld developers,
As a GSoC student I wrote static ld.lld auto-completion scripts for zsh and bash shell because it doesn’t have much options and flags for dynamic completion. Whether I send pr to zsh-completion/bash-completion package or open phabricator review for them? Also gnu ld has already autocompletion for bash shell but l am not merging ld and lld completion scripts to one file because lld lacks some options compare to ld and bash completion scripts only parse --help argument. Scripts are attached to the mail!
Regards
Shivam
_ld.lld (13.2 KB)
ld.lld (2.23 KB)
Hi Shivam,
As to the process of how to add a new feature to lld, it is recommended to start a new discussion thread at the llvm-dev mailing list, so thank you for starting this new thread. It is fine to create a proof-of-concept implementation, but I don’t think you’d want to spend too much time on it before you get an agreement that a proposed new feature looks like a good one.
Speaking of the proposed feature, I have a couple of comments and questions as follows:
-
Compilers have an extremely large number of command line options, and the number is growing. Many features accessible via the command line can be enabled/disabled at ./configure-time. Because of these facts, a static command-line completion setting doesn’t work well for compilers. But I don’t think that neither conditions are true to linkers; linkers don’t have large number of options, and new options are not added very frequently. Most commands, like tar or ls, doesn’t have a feature to support command-line auto-comletion. What makes linkers special from other commands?
-
Can’t the auto-completion script for GNU ld work for lld? As you said, that may lack a few command options, but it should work in most cases, and I’m not personally worried too much if an auto-completion is not very precise.
-
Somewhat related to the previous point, but on some systems, lld is installed as /usr/bin/ld. How do you distinguish it from GNU ld, or do we really need to distinguish them?
-
Users are not expected to use a linker directly. Instead, they are expected to invoke a linker using a compiler driver (i.e. clang or clang++). Does your auto-completion work to autocomplete -Wl,-foo options given to a compiler driver?
Hi Rui,
Hi Shivam,
As to the process of how to add a new feature to lld, it is recommended to start a new discussion thread at the llvm-dev mailing list, so thank you for starting this new thread. It is fine to create a proof-of-concept implementation, but I don’t think you’d want to spend too much time on it before you get an agreement that a proposed new feature looks like a good one.
Speaking of the proposed feature, I have a couple of comments and questions as follows:
- Compilers have an extremely large number of command line options, and the number is growing. Many features accessible via the command line can be enabled/disabled at ./configure-time. Because of these facts, a static command-line completion setting doesn’t work well for compilers. But I don’t think that neither conditions are true to linkers; linkers don’t have large number of options, and new options are not added very frequently. Most commands, like tar or ls, doesn’t have a feature to support command-line auto-comletion. What makes linkers special from other commands?
Now these commands got auto-completion for both zsh and bash shell.So I think we can also write auto-completion for lld as it has more options than them.
- Can’t the auto-completion script for GNU ld work for lld? As you said, that may lack a few command options, but it should work in most cases, and I’m not personally worried too much if an auto-completion is not very precise.
Yeah! we can do something like gcc is doing for clang in zsh-completion package but we are also working to have separate auto-completion for clang using --autocomplete api. Also in bash shell when I parse --help option for completion, gnu ld gives 185 and ld.lld gives 204 possibilities in which these options are different from each other so there is a big gap between them and getting wrong auto-completion is not good to have.
- Somewhat related to the previous point, but on some systems, lld is installed as /usr/bin/ld. How do you distinguish it from GNU ld, or do we really need to distinguish them?
I think you’re talking about FreeBSD or symlink to ld. For them it doesn’t need to be distinguished though, it can be distinguished if we read binary.
- Users are not expected to use a linker directly. Instead, they are expected to invoke a linker using a compiler driver (i.e. clang or clang++). Does your auto-completion work to autocomplete -Wl,-foo options given to a compiler driver?
No,Current implementation of --autocomplete api is not completing linker options but we are also going to make some improvements in clang --autocomplete interface in next few weeks once lld completion is landed.
Regards,
Shivam
Hi Rui,
Hi Shivam,
As to the process of how to add a new feature to lld, it is recommended to start a new discussion thread at the llvm-dev mailing list, so thank you for starting this new thread. It is fine to create a proof-of-concept implementation, but I don’t think you’d want to spend too much time on it before you get an agreement that a proposed new feature looks like a good one.
Speaking of the proposed feature, I have a couple of comments and questions as follows:
- Compilers have an extremely large number of command line options, and the number is growing. Many features accessible via the command line can be enabled/disabled at ./configure-time. Because of these facts, a static command-line completion setting doesn’t work well for compilers. But I don’t think that neither conditions are true to linkers; linkers don’t have large number of options, and new options are not added very frequently. Most commands, like tar or ls, doesn’t have a feature to support command-line auto-comletion. What makes linkers special from other commands?
Now these commands got auto-completion for both zsh and bash shell.So I think we can also write auto-completion for lld as it has more options than them.
The reason why I mentioned tar and ls as examples was because their options can be auto-completed both by bash and zsh even though they don’t have a feature to generate an option candidate list for autocompletion, even though they support many options and new options are added occasionally. It seems like lld is not very different from them.
Have you tried to add lld-specific options to the existing autocompletion script for ld? I’d try that first to see if this is satisfactory.
- Can’t the auto-completion script for GNU ld work for lld? As you said, that may lack a few command options, but it should work in most cases, and I’m not personally worried too much if an auto-completion is not very precise.
Yeah! we can do something like gcc is doing for clang in zsh-completion package but we are also working to have separate auto-completion for clang using --autocomplete api. Also in bash shell when I parse --help option for completion, gnu ld gives 185 and ld.lld gives 204 possibilities in which these options are different from each other so there is a big gap between them and getting wrong auto-completion is not good to have.
- Somewhat related to the previous point, but on some systems, lld is installed as /usr/bin/ld. How do you distinguish it from GNU ld, or do we really need to distinguish them?
I think you’re talking about FreeBSD or symlink to ld. For them it doesn’t need to be distinguished though, it can be distinguished if we read binary.
- Users are not expected to use a linker directly. Instead, they are expected to invoke a linker using a compiler driver (i.e. clang or clang++). Does your auto-completion work to autocomplete -Wl,-foo options given to a compiler driver?
No,Current implementation of --autocomplete api is not completing linker options but we are also going to make some improvements in clang --autocomplete interface in next few weeks once lld completion is landed.
I’d think that supporting autocompletion for -Wl, option is more important than supporting autocompletion for ld, because as I wrote users are not expected to directly use ld. When you invoke a linker, you are supposed to use it via a compiler driver, so you are unlikely to be using command line autocompletion for the ld command.