Compiler arguments are de-duplicated in configuration

[apples]

Brief Issue Summary

When configuring, the compilerArgs field of the configuration passed to the C/C++ extension has duplicate arguments removed.

Expected:

1. Create a CMakeLists.txt with duplicate compiler arguments using the SHELL: syntax, e.g.:

   add_compile_options("SHELL:-s DISABLE_EXCEPTION_CATCHING=0" "SHELL:-s USE_SDL=2")
   

   (in this case, the duplicate argument is -s)
2. Open and configure the project.
3. Compiler is detected properly and the configuration is correct.

Apparent Behavior:

1. Create a CMakeLists.txt with duplicate compiler arguments using the SHELL: syntax.
2. Open and configure the project.
3. Duplicate arguments have been stripped.
4. Invalid arguments result in failed compiler detection.
5. A default system compiler is chosen as a fallback.

This only happens sometimes. Other times, the compiler is detected correctly. Sometimes it sporadically switches between working and not working.

CMake Tools Log

[main] Building folder: cmake_emscripten_vscode 
[main] Saving open files before configure/build
[build] Starting build
[driver] Start build all
[driver] Runnnig pre-configure checks and steps
[proc] Executing command: C:\msys64\mingw64\bin\cmake.exe --build c:/Users/dbral/repos/cmake_emscripten_vscode/build --config Debug --target all -- -j 6
[build] [1/2  50% :: 4.548] Building CXX object CMakeFiles/foo.dir/foo.cpp.o
[build] [2/2 100% :: 8.424] Linking CXX executable foo.js
[cmakefileapi-parser] Read reply folder: c:\Users\dbral\repos\cmake_emscripten_vscode\build\.cmake\api\v1\reply
[cmakefileapi-parser] Found index files: ["cache-v2-5772836e1973b1d7599f.json","codemodel-v2-7f0084d7b7bc29219ebd.json","index-2020-07-03T11-16-11-0021.json","target-foo-Debug-1fdfc87e5bbc8bd28ab4.json"]
[driver] Run _refreshExpansions
[driver] Run _refreshExpansions cb
[build] Build finished with exit code 0
[extension] [7541] cmake.build finished (returned 0)
[cache] Reading CMake cache file c:/Users/dbral/repos/cmake_emscripten_vscode/build/CMakeCache.txt
[cache] Parsing CMake cache string

C/C++ Log

This is the top of the C/C++ log when the window is first opened.

Custom browse configuration received: {
  "browsePath": [
    "c:/users/dbral/repos/cmake_emscripten_vscode"
  ],
  "standard": "c++17",
  "compilerPath": "c:/emsdk/upstream/emscripten/em++.bat",
  "compilerArgs": [
    "-g",
    "-s",
    "DISABLE_EXCEPTION_CATCHING=0",
    "USE_SDL=2"
  ]
}
cpptools/didChangeCppProperties
Attempting to get defaults from compiler in "compilerPath" property: 'C:\msys64\mingw64\bin\gcc.exe'
Code browsing service initialized
Attempting to get defaults from compiler in "compilerPath" property: 'C:\msys64\mingw64\bin\gcc.exe'
  Folder: C:/MSYS64/MINGW64/LIB/GCC/X86_64-W64-MINGW32/9.2.0/INCLUDE/ will be indexed
  Folder: C:/MSYS64/MINGW64/INCLUDE/ will be indexed
  Folder: C:/MSYS64/MINGW64/LIB/GCC/X86_64-W64-MINGW32/9.2.0/INCLUDE-FIXED/ will be indexed
  Folder: C:/MSYS64/MINGW64/X86_64-W64-MINGW32/INCLUDE/ will be indexed
  Folder: C:/USERS/DBRAL/REPOS/CMAKE_EMSCRIPTEN_VSCODE/ will be indexed
cpptools/didChangeCustomBrowseConfiguration
Attempting to get defaults from compiler in "compilerPath" property: 'c:/emsdk/upstream/emscripten/em++.bat'
Failed to query compiler. Falling back to 32-bit intelliSenseMode.
Failed to query compiler. Falling back to no bitness.
em++: error: USE_SDL=2: No such file or directory ("USE_SDL=2" was expected to be an input file, based on the commandline arguments provided)

I am not sure why the didChangeCppProperties event is being processed right there, possibly just a race condition when the window is first loaded. The fact that GCC is being checked right there seems to have no impact on the result, aside from GCC being selected as the fallback.

Platform and Versions

• Operating System: Windows
• CMake Version: 3.15.6
• VSCode Version: 1.46.1
• CMake Tools Extension Version: 1.4.1
• Compiler/Toolchain: Emscripten 1.39.18

Other Notes/Information

I am running VS Code from within a MSY2 environment. This means I'm using the MinGW-built versions of tools such as CMake, some of which may have been slightly patched. I do not believe these patches have any significant effect on behavior.

Currently, Emscripten must be run with Python 3.8 in order to work with the C/C++ extension, see emscripten-core/emscripten#11529 for details.

[bobbrow]

I believe the problem is here. https://github.com/microsoft/vscode-cmake-tools/blob/89b9ec8b12ee6d6138cc8865b14e6d0f0ae37d02/src/cpptools.ts#L507

We'll take a look.

[chausner]

@bobbrow Looks like this issue has already been addressed in https://github.com/microsoft/vscode-cmake-tools/pull/1497.

[bobbrow]

@chausner, not sure how I missed your message, but I believe you're right. Between #1497 and #2508, this should have been addressed. Please let us know if it hasn't.