As reported in https://github.com/fish-shell/fish-shell/issues/11535#issuecomment-2915440295,
a command like "complete -C'git '" gets progressively slower every time.
A diff of "fish_trace=1" output shows that each completion invocation added
more stuff to the global "__fish_git_aliases", resulting in output like:
--> for s db
...
--> for s db s db
...
--> for s db s db s db
Reproducer:
$ touch ~/.local/share/fish/generated_completions/foo.fish
$ cargo install --path . --debug
$ ~/.cargo/bin/fish -d autoload -c 'function foo; end; for i in 1 2; complete -C"foo "; end'
We redundantly autoload the embedded file, which, by definition doesn't change.
This happens when
1. the "embed-data" feature is enabled (default for "cargo install")
2. there is a completion file in generated_completions
which triggers a hack to give precedence to "embedded:completions/git.fish"
over "generated_completions/git.fish".
Since we always load all file-based files first, we clobber the autoload cache
("self.autoloaded_files") with the mtime of the generated completion file, even
if we're never gonna return it. This makes the embed-data logic think that
the asset has changed (which is impossible! But of course it is possible that
"fish_complete_path" changes and causes a need to load "embedded:git.fish").
Fix that by treating embedded files more like normal files. This is closer
to historical behavior where $__fish_data_dir/{functions,completions}
are normal directories. Seems like this should fix a false negative in
"has_attempted_autoload" which feels useful.
Add a dead test, I guess. It's not run with feature="embed-data" yet. In
future we should test this in CI.
6737872fb7