Log full of "Invalid variable reference" on Fedora 34

[reddwarf69]

It may be related to https://src.fedoraproject.org/rpms/which/c/98662a9c460f663b1bef1887cfd28c6f7f1bfe5f?branch=f34, not sure. But the thing is that Fedora has https://src.fedoraproject.org/rpms/which/blob/f34/f/which2.sh in /etc/profile.d/which2.sh. AFAICT it works fine:

$ which ls
alias ls='ls --color=auto'
	/usr/bin/ls
$ which okular 
/usr/bin/okular
$

But the thing is that my CMake/Build log is full of this stuff:

[variant] Loaded new set of variants
[kit] Successfully loaded 2 kits from /home/reddwarf/.local/share/CMakeTools/cmake-tools-kits.json
[presetController] Successfully validated presets in /home/reddwarf/git/router_sdk/CMakePresets.json
[expand] Invalid variable reference ${which_declare} in string: () {  ( alias;
 eval ${which_declare} ) | /usr/bin/which --tty-only --read-alias --read-functions --show-tilde --show-dot "$@"
}
[driver] Switching to configure preset: full
[expand] Invalid variable reference ${which_declare} in string: () {  ( alias;
 eval ${which_declare} ) | /usr/bin/which --tty-only --read-alias --read-functions --show-tilde --show-dot "$@"

No idea how it got there.

[andreeis]

Thank you for opening this report. I am not sure yet what happens. Is your project easy to share?
If not the whole project maybe your settings.json, your kit files and your presets?
Did this work before?
A long short, but does it happen with presets off?

[reddwarf69]

I didn't think about the possibility it could be project-specific.
But after playing with this a bit:

• A new clone of the same project doesn't show the issue. They are otherwise identical.
• After deleting ~/.vscode/ and ~/.config/Code/ and restoring a backup of ~/.config/Code/User/settings.json... the original project doesn't show the problem either any more.

This is a brand new installation. Fedora 34 was release only last week. So... no idea what happened, but I didn't back up ~/.config/Code or ~/.vscode/ so I can't reproduce the problem any more. I will close the issue.

[reddwarf69]

Forget what I said. This simple project reproduces the issue:

$ ls -l
total 8
-rw-rw-r--. 1 reddwarf reddwarf  75 May  6 21:36 CMakeLists.txt
-rw-rw-r--. 1 reddwarf reddwarf 266 May  6 21:36 CMakePresets.json
$ cat CMakeLists.txt 
cmake_minimum_required(VERSION 3.20 FATAL_ERROR)

project(cmaketools_test)
$ cat CMakePresets.json 
{
    "version": 2,
    "cmakeMinimumRequired": {
        "major": 3,
        "minor": 20,
        "patch": 0
    },
    "configurePresets": [
        {
            "name": "test",
            "generator": "Ninja",
            "binaryDir": "build"
        }
    ]
}
$

The issue starts the second I select the configure preset in VSCode.

[andreeis]

Do you have ${which_declare} anywhere in your project json files?

[reddwarf69]

Sorry, I don't understand the question. What do you mean by "your project json files"?
To be clear, this happens in a "project" with only the two files shown before: CMakeLists.txt and CMakePresets.json. The contents of the files are in the comment, none includes which_declare.

[andreeis]

I thought you didn't share parts of the project and that you were invoking some variables that would cause those fragments of log during their expansion. Good to know that you don't reference such variables and even better that the whole project consists of only those 2 files. We have enough to investigate, thank you.

[reddwarf69]

FWIW the issue is still there in v1.8.2-a6cbd35

[nilssonk]

This issue is indeed related to https://src.fedoraproject.org/rpms/which/c/98662a9c460f663b1bef1887cfd28c6f7f1bfe5f?branch=f34

Explanation

In preset.ts:expandConfigurePreset, beginning at line 674 environmental variables are unconditionally passed to expandString, which internally at expand.ts:132 scans for substitutions using the regex literal /\$\{(\w+)\}/g. In earlier versions of Fedora the alias for which contained an expansion ${_declare} which due to its leading underscore for some reason would not trigger a match. Fedora 34 instead ships with an updated which2.sh that has had its expansion renamed to ${which_declare}. The new name unfortunately triggers a match and subsequently fails the substitution check at expand.ts:140 since which_declare usually is not present in the provided opt.args as is in this case generated by a call to getExpansionOptions at preset.ts:671.

What is a good solution for this? I dislike that Fedora is doing alias hacks, but I also dislike that cmake-tools performs expansion on all available environmental variables.