h/fish-shell
1
Fork 0
mirror of https://github.com/fish-shell/fish-shell.git synced 2026-06-06 17:31:14 -03:00
Code Issues Packages Projects Releases Wiki Activity
Files
master
fish-shell/tests/checks/autoload.fish

22 lines
454 B
Fish
Raw Permalink Normal View History

embed-data: naturalize generated_completions-hack to prevent repeated autoloading 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.
2025-05-28 13:31:24 +02:00
#RUN: %fish %s
Fix "set fish_complete_path" accidentally disabling autoloading Commit 5918bca1eba (Make "complete -e" prevent completion autoloading, 2024-08-24) makes "complete -e foo" add a tombstone for "foo", meaning we will never again load completions for "foo". Due to an oversight, the same tombstone is added when we clear cached completions after changing "fish_complete_path", preventing completions from being loaded in that case. Fix this by restoring the old behavior unless the user actually used "complete -e".
2025-05-29 14:20:11 +02:00
set -g fish_complete_path c1 c2
mkdir c1 c2
embed-data: naturalize generated_completions-hack to prevent repeated autoloading 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.
2025-05-28 13:31:24 +02:00
function foo; end
Fix "set fish_complete_path" accidentally disabling autoloading Commit 5918bca1eba (Make "complete -e" prevent completion autoloading, 2024-08-24) makes "complete -e foo" add a tombstone for "foo", meaning we will never again load completions for "foo". Due to an oversight, the same tombstone is added when we clear cached completions after changing "fish_complete_path", preventing completions from being loaded in that case. Fix this by restoring the old behavior unless the user actually used "complete -e".
2025-05-29 14:20:11 +02:00
for i in c1 c2
echo >$i/foo.fish "echo auto-loading $i/foo.fish"
end
embed-data: naturalize generated_completions-hack to prevent repeated autoloading 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.
2025-05-28 13:31:24 +02:00
complete -C "foo " >/dev/null
Fix "set fish_complete_path" accidentally disabling autoloading Commit 5918bca1eba (Make "complete -e" prevent completion autoloading, 2024-08-24) makes "complete -e foo" add a tombstone for "foo", meaning we will never again load completions for "foo". Due to an oversight, the same tombstone is added when we clear cached completions after changing "fish_complete_path", preventing completions from being loaded in that case. Fix this by restoring the old behavior unless the user actually used "complete -e".
2025-05-29 14:20:11 +02:00
# CHECK: auto-loading c1/foo.fish
embed-data: naturalize generated_completions-hack to prevent repeated autoloading 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.
2025-05-28 13:31:24 +02:00
complete -C "foo " >/dev/null
# already loaded
Fix "set fish_complete_path" accidentally disabling autoloading Commit 5918bca1eba (Make "complete -e" prevent completion autoloading, 2024-08-24) makes "complete -e foo" add a tombstone for "foo", meaning we will never again load completions for "foo". Due to an oversight, the same tombstone is added when we clear cached completions after changing "fish_complete_path", preventing completions from being loaded in that case. Fix this by restoring the old behavior unless the user actually used "complete -e".
2025-05-29 14:20:11 +02:00
set -g fish_complete_path c2
complete -C "foo " >/dev/null
# CHECK: auto-loading c2/foo.fish
set -g fish_complete_path c1 c2
complete -C "foo " >/dev/null
# CHECK: auto-loading c1/foo.fish
Reference in New Issue Copy Permalink