Generate completion files on toolchain switch or update

[rosingrind]

Problem you are trying to solve

To utilize rustup completions, you are suggested to run rustup completions every time login shell is opened https://rust-lang.github.io/rustup/installation/index.html#enable-tab-completion-for-bash-fish-zsh-or-powershell. On some machines, this may drastically affect shell startup time

Solution you'd like

rustup completions can be called in a rustup internal post-install routine and generate proper completion files after updating or switching toolchain (or at first install); users will be able to source pre-baked completion files without calling rustup each time they login to shell

Notes

An example of how this process may look for zsh:

• calling rustup update alters rustup and cargo versions, new cli arguments are added
• after successful update, a post-install routine of completion generation started:
  • rustup completions zsh rustup >$RUSTUP_HOME/completions/_rustup makes completions for rustup
  • rustup completions zsh cargo >$CARGO_HOME/completions/_cargo makes completions for cargo
  • performing rm -f ~/.zcompdump; compinit to reset and reload completions in zsh
• if user has FPATH="$RUSTUP_HOME/completions:$CARGO_HOME/completions:$FPATH" in their .zshrc, the completions will work and be up-to-date

[djc]

Seems like a reasonable improvement. @rami3l any thoughts?

[rami3l]

Seems like a reasonable improvement. @rami3l any thoughts?

@djc I am surprised to find out about this suggestion just now.

The proper way of doing this definitely won't be re-generating completions on toolchain switch though (I won't do this on my machine anyway). I remember saying somewhere that we need a static skeleton for completions and then update them on re-installations of Rustup itself. Hopefully this will just be a documentation thing.

For the dynamic part of this, we will need to add specific support.

[rami3l]

Interestingly enough, rustup completions --help gives the right instructions:

Enable tab completion for Bash, Fish, Zsh, or PowerShell
The script is output on `stdout`, allowing one to re-direct the
output to the file of their choosing. Where you place the file
will depend on which shell, and which operating system you are
using. Your particular configuration may also determine where
these scripts need to be placed.

Here are some common set ups for the three supported shells under
Unix and similar operating systems (such as GNU/Linux).

Bash:

Completion files are commonly stored in `/etc/bash_completion.d/` for
system-wide commands, but can be stored in
`~/.local/share/bash-completion/completions` for user-specific commands.
Run the command:

    $ mkdir -p ~/.local/share/bash-completion/completions
    $ rustup completions bash >> ~/.local/share/bash-completion/completions/rustup

This installs the completion script. You may have to log out and
log back in to your shell session for the changes to take effect.

...

[rami3l]

@djc As you may already know, I use Homebrew's Rustup distribution, and so far the completion file is purely static. This is a recurring pattern for many applications, for which Homebrew has very good support:

    generate_completions_from_executable(bin/"rustup", "completions")

[rosingrind]

proper way of doing this definitely won't be re-generating completions on toolchain switch though

There are 2 cases:

1. If an end-user that configured his completions according to instructions from rustup completions --help, and switches his global rust toolchain to nightly, he gets fresh cargo with stable completions (same with brew isn't it?)
2. If an end-user cwds to a 5 y/o rust project with .rust-toolchain file and invokes build, then about 5 y/o cargo will be fetched https://rust-lang.github.io/rustup/overrides.html#components

When cargo component is altered by switching either global or local toolchain, you are supposed to rebuild completions https://github.com/rust-lang/cargo/blob/master/CHANGELOG.md

[rami3l]

proper way of doing this definitely won't be re-generating completions on toolchain switch though

There are 2 cases:

1. If an end-user that configured his completions according to instructions from rustup completions --help, and switches his global rust toolchain to nightly, he gets fresh cargo with stable completions (same with brew isn't it?)
2. If an end-user cwds to a 5 y/o rust project with .rust-toolchain file and invokes build, then about 5 y/o cargo will be fetched rust-lang.github.io/rustup/overrides.html#components

When cargo component is altered by switching either global or local toolchain, you are supposed to rebuild completions rust-lang/cargo@master/CHANGELOG.md

@rosingrind Thanks for your reply. However I still doubt if anything should be regenerated even for cargo.

Wouldn't a double FS link be sufficient in this case? Let's say we put a note for you to generate a symlink to our symlink to some completions file, and we control where the latter points to just like we do with rustc and other stuff... That's what I meant by "the dynamic part".

Update: I just found out that our completion script is already dynamic for cargo so there's nothing to be done:

> rustup completions zsh cargo
#compdef cargo
if command -v rustc >/dev/null 2>&1; then
        source "$(rustc --print sysroot)"/share/zsh/site-functions/_cargo
fi

... where rustc would be dynamic given that it is taken over by rustup.

[rami3l]

My conclusion is that https://rust-lang.github.io/rustup/installation/index.html#enable-tab-completion-for-bash-fish-zsh-or-powershell needs to be changed to align with rustup completions --help.

Also, we need to check whether we should update the completion files on a per-update basis. However I think we should just dump our files somewhere (like $CARGO_HOME) and allow/prompt the users to pick them up via FS links.