Add support for armcc compiler

[gentooise]

Type: LanguageService

I'm using CMake Tools extension as configurationProvider for cpptools, CMake files are correctly parsed and ARM Compiler toolchain is selected (via my Toolchain.cmake file).

However, it seems cpptools extension does not support ARM Compiler.

This is ARM Compiler -> link (it's proprietary ARM compiler, a license is needed to use the compiler, but I could provide whatever compiler output you may need).

Describe the bug

• OS and Version: Windows 10
• VS Code Version: 1.52.0
• C/C++ Extension Version: v1.1.3
• Other extensions you installed (and if the issue persists after disabling them): CMake Tools

After configuration has been provided via CMake Tools, cpptools gives the following C/C++ Configuration Warning:

[17/12/2020, 09:34:04] Unable to resolve configuration with compilerPath "c:/program files (x86)/arm_compiler_5.06u4/bin64/armcc.exe".  Using "cl.exe" instead.

The path to ARM Compiler is correct, the executable is there.

Steps to reproduce

You cannot reproduce without an active ARM Compiler license.

Expected behavior

C/C++ extension also supports ARM proprietary compilers.

Logs

Insert logs here.

Screenshots

Additional context

Here you can find more details about compiler defines/includes. (I already supported a similar work for an Eclipse IDE plugin some time ago).

Quotes from above link:

For built-in macros and includes, I provide here armcc case as an example:

Built-in macros are provided by the compiler with armcc --list_macros dummy.c (dummy.c can be empty). I could just feed your Parser with this command, whose output is like the following:

#define __STDC__ 1
#define __STDC_VERSION__ 199409L
#define __EDG__ 1
#define __EDG_VERSION__ 407
#define __EDG_SIZE_TYPE__ unsigned int
#define __EDG_PTRDIFF_TYPE__ int
#define __sizeof_int 4
#define __sizeof_long 4
#define __sizeof_ptr 4
#define __ARMCC_VERSION 5060422
#define __TARGET_CPU_ARM7TDMI 1
#define __TARGET_FPU_SOFTVFP 1
#define __CC_ARM 1
#define __arm 1
#define __arm__ 1
#define __TARGET_ARCH_4T 1
#define __TARGET_ARCH_ARM 4
#define __TARGET_ARCH_THUMB 1
#define __TARGET_ARCH_A64 0
#define __TARGET_ARCH_AARCH32 1
#define __TARGET_FEATURE_HALFWORD 1
#define __TARGET_FEATURE_THUMB 1
#define __TARGET_FEATURE_MULTIPLY 1
#define __TARGET_FEATURE_EXTENSION_REGISTER_COUNT 0
#define __a32__ 1
#define __OPTIMISE_SPACE 1
#define __OPT_SMALL_ASSERT 1
#define __OPTIMISE_LEVEL 2
#define __SOFTFP__ 1

There is no armcc command line argument to get the list of include directories. The only include directory is fixed, and it is simply ../include (relative to the location of armcc executable). I could feed your Built-in parser with this path.

Luckily, I see that everything seems well documented. You can find all info starting from the link to the docs I provided above. Moreover, I can suggest other specific links of interests (you can easily find them navigating through docs by yourself):

• Link to Compiler command-line options and search paths (you can also see ../include there);
• Link to Factors influencing how the compiler searches for header files;
• Link to Compiler search rules and the current place;
• Link to The ARMCC5INC environment variable.

Additionally, I want to point out that I'm using version 5 of the ARM compiler, but there is version 6 also. With version 6, ARM seems to switch to clang-compatible compiler. I provide also a link to version 6 command line options here.

Here in section 1.1 Support level definitions they say:

Arm Compiler 6 is built on LLVM technology and preserves the functionality of that technology where possible. This means that there are additional features available in Arm Compiler that are not listed in the documentation. These additional features are known as community features. For information on these community features, see the documentation for the Clang/LLVM project.

[sean-mcmanus]

Thanks for the info on armcc. This sounds like a duplicate of #4269 .

[gentooise]

I'm sorry, I forgot I had already opened a similar issue.

Anyway, I think we may close that one and leave this opened, because I updated my settings in order to use just the configurationProvider (CMake Tools) in favor of the old compileCommands mechanism.

Please let me know if I did well.

Thanks

[gentooise]

Any news about this? Do you have any workaround? It doesn't seem possible to manually override compilerPath when using CMake Tools... any idea? @sean-mcmanus @bobbrow

Thanks

[sean-mcmanus]

Yeah, there isn't a way to override the compilerPath with CMake Tools. Looks like this issue is being tracked in CMake Tools at microsoft/vscode-cmake-tools#1096 and the recommended workaround is to use compileCommands, which allows the compilerPath to be overwritten.

[gentooise]

Thank you for the info @sean-mcmanus

And to override just system include paths and defines (ignoring error on compilerPath), instead? Not possible either?

[sean-mcmanus]

If the configurationProvider is set, then our extension will use the includePath/defines from the configuration provider and there's not currently an override mechanism, other than modifying the open source code to allow such an override.

[Colengms]

Hi @gentooise . Could you set "C_Cpp.loggingLevel": "Debug", and check the C/C++ output for the command lines that are being used to query the compiler? We will actually invoke the compiler up to 4 times:

• To determine the compiler's default C++ standard (based on system defines), so we know which to use if not provided by the config.
• To determine the compiler's default target (-dumpmachine), so we know what IntelliSense mode to use if not provided by the config.
• To determine the system includes and defines (which uses compilerArgs provided by the custom configuration's 'browse config'). Files that we are unable to get a file-specific custom configuration for will fall back to this config..
• To determine the system includes and defines for files we receive a custom configuration for.

I'm curious which of these fail. If the issue is only that the result of -dumpmachine is not recognized, that would be relatively simple to fix. Or, the issue may be with how to compose one of the other command lines.

[gerhardol]

I have the same problem using the WindRiver compiler.
The options to the WindRiver compiler is different from gcc family, CMake overridden.
Similar with other compilers (ARMCC among others)
We could configure the required information manually instead of quering the compiler.

		// Set provider (if compile_commands is not activated)
		"C_Cpp.default.configurationProvider": "ms-vscode.cmake-tools",
		// Use the compile commands if it exists, improves intellisense
		"C_Cpp.default.compileCommands": "D:/g2/path/.vscode/build/compile_commands.json",

First part of output

cpptools/didChangeCppProperties
Attempting to get defaults from compiler found on the machine: 'C:\cygwin\bin\gcc.exe'
Querying compiler for default C++ language standard using command line: "C:\cygwin\bin\gcc.exe" -x c++ -E -dM nul
Querying compiler for default C language standard using command line: "C:\cygwin\bin\gcc.exe" -x c -E -dM nul
Querying compiler's default target using command line: "C:\cygwin\bin\gcc.exe" -dumpmachine
Compiler returned default target value: x86_64-pc-cygwin

No suitable compiler found. Please set the "compilerPath" in c_cpp_properties.json.
Attempting to get defaults from compiler found on the machine: 'C:\cygwin\bin\gcc.exe'
No suitable compiler found. Please set the "compilerPath" in c_cpp_properties.json.
Attempting to get defaults from C compiler in compile_commands.json file: 'D:/g2/Tools/WindRiver/5.9.4.8/diab/WIN32/bin/dcc.exe'
Querying compiler for default C++ language standard using command line: "D:/g2/Tools/WindRiver/5.9.4.8/diab/WIN32/bin/dcc.exe" -x c++ -E -dM nul
Failed to query compiler at path "D:/g2/Tools/WindRiver/5.9.4.8/diab/WIN32/bin/dcc.exe" for default standard versions.  Compiler querying is disabled for this compiler.
Querying compiler for default C language standard using command line: "D:/g2/Tools/WindRiver/5.9.4.8/diab/WIN32/bin/dcc.exe" -x c -E -dM nul
Failed to query compiler at path "D:/g2/Tools/WindRiver/5.9.4.8/diab/WIN32/bin/dcc.exe" for default standard versions.  Compiler querying is disabled for this compiler.
Querying compiler's default target using command line: "D:/g2/Tools/WindRiver/5.9.4.8/diab/WIN32/bin/dcc.exe" -dumpmachine
Compiler returned default target value: 
Unhandled default compiler target value detected: 
Attempting to get defaults from compiler found on the machine: 'C:\cygwin\bin\gcc.exe'
No suitable compiler found. Please set the "compilerPath" in c_cpp_properties.json.
Attempting to get defaults from C compiler in compile_commands.json file: 'D:/g2/Tools/WindRiver/5.9.4.8/diab/WIN32/bin/dcc.exe'

[sean-mcmanus]

@gerhardol Your issue should be fixed in our pending 1.2.1 release (there was a bug querying Cygwin compilers).

[gerhardol]

@gerhardol Your issue should be fixed in our pending 1.2.1 release (there was a bug querying Cygwin compilers).

Thanks, but it is WindRiver that is the compiler that should be used, not detected.
(I will try to get a similar debug with armcc and GreenHills too).

[Colengms]

Hi @gerhardol . Currently, we support compiler paths that refers to cl.exe, gcc, or a gcc variant (such as clang). If using another compiler, I'd suggest specifying a compilerPath of "" in your configuration. This is a special value that prevents compiler querying, and should override the compiler specified by a custom configuration provider or compile_commands.json. Also, since we can't query a compiler for system include paths and system defines, fully configuring IntelliSense would require providing these in the configuration.

[Colengms]

Hi @gerhardol . FYI, I just opened the following issue related to what I described in my last comment. #6909 Until that is addressed, there doesn't seem to be a way to directly provide the system includes and system defines that we are missing, when using compilerPath of "" in combination with a custom config provider or compile_commands.json. But, it should be possible to do so when not using a custom config provider or compile_commands.json.

[gerhardol]

Thanks

With 1.2.1 there should be a way to use Cygwin - maybe MSVC could be used right now. (adding c_cpp_properties.json, but 1.2.1 is probably released before I am done.)

We do not have any compilerpath set at all, CMake Tools is set as the configuration provider with a CMake Toolchain file. That fails maybe as no include system paths are provided. Maybe there are other issues too, I found the following: #3819 microsoft/vscode-cmake-tools#702
But that is sidetracking, supplying the compilerpath from CMake Tools works for the original post.

I am not sure what supplying the compiler settings from CMake Tools really means here, if CPP Tools still tries to query the files then there is no point in supplying that for unsupported compilers. While ARMCC 5 is based on GCC, the arguments are slightly different I believe and it may not work (could be similar for ARMCC 6). The other embedded compilers may not work at all.
This is maybe the core problem for the original post?

compile_commands.json is therefore used as a backup. compile_commands.json requires that CMake configuration has run, which we would like to avoid as source code generation can take a long time. But it is acceptable if CMake Tools do not provide the information and #6909 may be a workaround for the problem reported in this PR too.

[Colengms]

Hi @gerhardol . 1.2.1 will contain a fix to allow using an explicitly blank "" value for compilerPath to override the compiler provided by a custom configuration provider. I had thought this was already handled, as it is for compile_commands.json, but it was not. It was simple to add. That should at least prevent us from trying to query the compiler and choosing another when that fails.
However, #6909 is still an issue.

If we are not able to query a compiler, a custom config provider or compile_commands.json has limited usefulness. We will pick up project defines and include paths this way, but will not pick up system defines and system include paths. Unless/until #6909 is addressed, the only way to add them to the configuration would be to explicitly specify them in CMakeLists.txt (as user include paths and defines) or pass them as -D/-I compiler args. Alternatively, you could provide all include paths and defines via c_cpp_properties.json (and a compilerPath of "").

Another idea might be to create a script or custom binary to use as an proxy compiler, that either passes all command lines through to the actual compiler, or responds to our compiler-querying command lines with system includes and system defines in the format we expect from gcc.

I also opened #6931 to track providing a way users could add support for compilers we don't know about.

[gerhardol]

@Colengms

Thanks for the info
IntelliSense is great

I am partly hijacking this issue now, but the OP and me seem to have misunderstood what a custom provider actually provides to CPP Tools. I had the impression that CPP Tools would not need to query any data with that, but that is clearly not the case. This should maybe be clarified in the documentation - if the pending outcome of this discussion is included, it would be even better. (To put this in another way: How to write the doc so users do not ask stupid questions.)

1. If a configuration provider could provide not just the compiler path but also system includes and both includes and defines for each file, it would be the best. Then we would configure the compile related in one place, in my setup the CMake configuration.
   This would be a great feature - how I interpreted it initially.

2. The second best option is to use a compile_commands.json together with some way to get system defines and includes. That is what Need a way to provide system defines and system includes when compiler querying is disabled (with compilerPath of ""). #6909 will allow. (Will look into setting up c_cpp_properties.json for a compiler version to separate from workspace.)
   The drawback is that compile_commands.json must be generated and it is hard to setup dependencies from the various CMake configuration files. In my case there are also many files that are generated which take a long time and the generated files must exist first.

3. A complete c_cpp_properties.json (with all file specific includes etc) is also a possible option. Then we would need to generate the file from compile_commands.json (as defines and includes varies per file), not a too nice option.

[Colengms]

Hi @gerhardol .

If a config provider can provide all of the system includes and defines, that is supported. A custom config provider implemented to support a specific build system and specific compiler(s) could do this. However, if the config provider supports multiple compilers and does not have deep knowledge of those compilers (such as the case with CMake Tools), then it would have to do the same work cpptools would have to do, to query compilers for this information. CMake Tools essentially defers that work to cpptools.

We also parse the args of the command line to infer user includes, user defines, and check for args that override settings (such as for language standard, target platform and bitness). If the compiler is unknown to us, it's possible the command line syntax is unknown to us also.

I don't think we have a way to fully support compilers that are unknown to us. #6909 would fall short, as it does not address how to parse the command line for user includes, defines, etc.. It looks like #6931 would seem to speak to the more general problem.

[Wetmelon]

I have the same problem with tricore-gcc. It was working fine until a few versions ago (yes, even querying standard include paths based on , which I understand is the original intent of this entry), now I get a stupid dialog box with a warning the first time I open a C or C++ file in VSCode. The compiler's a bog standard GCC aimed at the TriCore target, there should be no reason for this. If it works with arm-none-eabi-gcc, it should work with tricore-gcc. At the very least just stop the console from popping up every time, it's driving me nuts. Make it a squiggle-line error in the .json like the inability to resolve the path to the compiler maybe?

        {
            "name": "RC10-10/31",
            "includePath": [
                "${workspaceRoot}/Src/**",
                "${workspaceRoot}/Lib/**",
                "C:/Tools/API/RC10_10_31/V02.11/C-API/Includes",
                "C:/Tools/API/RC10_10_31/V02.11/C-API/Includes/Core"
            ],
            "compilerPath": "C:/Tools/Compiler/HIGHTEC/TRICORE/3.4.6.1/bin/tricore-g++.exe -O2 -std=gnu++98 -mcpu24 -mcpu=TC13-FPU_ERR13X_OP1 -specs=tricore.specs",
            "cStandard": "c99",
            "cppStandard": "c++98",
            "intelliSenseMode": "gcc-x64"
        },

Unable to resolve configuration with compilerPath "C:\Tools\Compiler\HIGHTEC\TRICORE\3.4.6.1\bin\tricore-g++.exe".  Using "C:\Program Files\LLVM\bin\clang.exe" instead.

[sean-mcmanus]

@Wetmelon Your issue might be fixed by #6898 ? @Colengms Do you know if that's the same issue?

[Wastus]

I'm a bit confused right now and not sure which issue is the correct one to post to, I'm just pretty certain, that I don't need to open another one.
We are using the IAR EWARM compiler, which really doesn't behave like gcc at all, so the query fails (-x is not a valid option for example).

The current solution is to provide all defines and include paths in c_cpp_properties.json. As there are keywords, which are not supported I've created a header file which uses #define to get rid of those keywords. Additionally the system includes need some defines to be present to be parsed correctly (like the compiler version). This header is included with the forcedInclude option.

It is a bit ugly to maintain the include paths and defines in several places, so after moving to CMake, I tried using the compile_commands.json, because all information like the include directories is contained in there. The defines and include directories follow the typical -D -I scheme, so they get parsed correctly. I've explicitly mentioned the system include directory in my CMakeLists.txt, so they are also recognized as include directory.
But still to parse the system headers correctly my header for Intellisense must be included (but only for Intellisense). Sadly, the forcedInclude option gets ignored as described in #1842 when compile_commands.json is used (and I guess the defines as well, but that wouldn't be too bad after I learned that _INTELLISENSE_ is defined if Intellisense is used). I guess I could change the CMakeLists.txt somehow to include that header, but we are aiming at safety critical systems, so I really don't want to inject some header just to make a coding tool (even a very nice one) working.

So #6909 sounds like it would provide a solution for this, but #6931 would also provide a (more general) solution.

A colleague wrote a small utility to fake the compiler query output, but that has no interface to CMake, so suffers from the same drawbacks as writing everything manually in c_cpp_properties.json, so I'd like to get a better native solution working.

[gentooise]

Hi all, I'm glad this issue received a lot of visibility.

I would live well with #6909 solution in the meantime, but I'm really hoping for something like the proposal in #6931: that would be great.

Anyway, just to reply to @Colengms:

Hi @gentooise . Could you set "C_Cpp.loggingLevel": "Debug", and check the C/C++ output for the command lines that are being used to query the compiler? We will actually invoke the compiler up to 4 times:

• To determine the compiler's default C++ standard (based on system defines), so we know which to use if not provided by the config.
• To determine the compiler's default target (-dumpmachine), so we know what IntelliSense mode to use if not provided by the config.
• To determine the system includes and defines (which uses compilerArgs provided by the custom configuration's 'browse config'). Files that we are unable to get a file-specific custom configuration for will fall back to this config..
• To determine the system includes and defines for files we receive a custom configuration for.

I'm curious which of these fail. If the issue is only that the result of -dumpmachine is not recognized, that would be relatively simple to fix. Or, the issue may be with how to compose one of the other command lines.

here's your output (private paths omitted):

Custom configuration provider 'CMake Tools' registered
cpptools/didChangeCppProperties
No suitable compiler found. Please set the "compilerPath" in c_cpp_properties.json.
No suitable compiler found. Please set the "compilerPath" in c_cpp_properties.json.
  Folder: C:/MYPROJECTDIR/PROJSUBDIR will be indexed
cpptools/didChangeCustomBrowseConfiguration
Attempting to get defaults from C++ compiler in "compilerPath" property: 'c:/program files (x86)/arm_compiler_5.06u4/bin64/armcc.exe'
Querying compiler for default C++ language standard using command line: "c:/program files (x86)/arm_compiler_5.06u4/bin64/armcc.exe" -x c++ -E -dM nul
Querying compiler for default C language standard using command line: "c:/program files (x86)/arm_compiler_5.06u4/bin64/armcc.exe" -x c -E -dM nul
Querying compiler's default target using command line: "c:/program files (x86)/arm_compiler_5.06u4/bin64/armcc.exe" -dumpmachine
Unhandled default compiler target value detected: 
MSVC intelliSenseMode specified.  Configuring for compiler cl.exe.
  Unable to retrieve file system information for c:/myprojectdir/subdir1. error = -1
  Unable to retrieve file system information for c:/myprojectdir/subdir2. error = -1
  [...]
  Folder: C:/PROGRAM FILES (X86)/MICROSOFT VISUAL STUDIO/2019/BUILDTOOLS/VC/TOOLS/MSVC/14.27.29110/INCLUDE/* will be indexed
  Folder: C:/PROGRAM FILES (X86)/WINDOWS KITS/10/INCLUDE/10.0.18362.0/UM/ will be indexed
  Folder: C:/PROGRAM FILES (X86)/WINDOWS KITS/10/INCLUDE/10.0.18362.0/UCRT/ will be indexed
  Folder: C:/PROGRAM FILES (X86)/WINDOWS KITS/10/INCLUDE/10.0.18362.0/SHARED/ will be indexed
  Folder: C:/PROGRAM FILES (X86)/WINDOWS KITS/10/INCLUDE/10.0.18362.0/WINRT/ will be indexed
  Folder: C:/PROGRAM FILES (X86)/WINDOWS KITS/10/INCLUDE/10.0.18362.0/CPPWINRT/ will be indexed
  Folder: C:/MYPROJECTDIR/SUBDIR1/ will be indexed
  Folder: C:/MYPROJECTDIR/SUBDIR2/ will be indexed
  [...]
cpptools/didChangeCppProperties
No suitable compiler found. Please set the "compilerPath" in c_cpp_properties.json.
Code browsing service initialized
Populate include completion cache.
No suitable compiler found. Please set the "compilerPath" in c_cpp_properties.json.
  Folder: C:/MYPROJECTDIR/ will be indexed
cpptools/didChangeCustomBrowseConfiguration
Discovering files...
Attempting to get defaults from C++ compiler in "compilerPath" property: 'c:/program files (x86)/arm_compiler_5.06u4/bin64/armcc.exe'
MSVC intelliSenseMode specified.  Configuring for compiler cl.exe.
  Unable to retrieve file system information for c:/myprojectdir/subdir1. error = -1
  Unable to retrieve file system information for c:/myprojectdir/subdir2. error = -1
  [...]
  Processing folder (non-recursive): C:/PROGRAM FILES (X86)/MICROSOFT VISUAL STUDIO/2019/BUILDTOOLS/VC/TOOLS/MSVC/14.27.29110/INCLUDE
  Unable to retrieve file system information for c:/myprojectdir/subdir3. error = -1
  Unable to retrieve file system information for c:/myprojectdir/subdir4. error = -1
  [...]
  Folder: C:/PROGRAM FILES (X86)/MICROSOFT VISUAL STUDIO/2019/BUILDTOOLS/VC/TOOLS/MSVC/14.27.29110/INCLUDE/* will be indexed
  Folder: C:/PROGRAM FILES (X86)/WINDOWS KITS/10/INCLUDE/10.0.18362.0/UM/ will be indexed
  Folder: C:/PROGRAM FILES (X86)/WINDOWS KITS/10/INCLUDE/10.0.18362.0/UCRT/ will be indexed
  Folder: C:/PROGRAM FILES (X86)/WINDOWS KITS/10/INCLUDE/10.0.18362.0/SHARED/ will be indexed
  Folder: C:/PROGRAM FILES (X86)/WINDOWS KITS/10/INCLUDE/10.0.18362.0/WINRT/ will be indexed
  Folder: C:/PROGRAM FILES (X86)/WINDOWS KITS/10/INCLUDE/10.0.18362.0/CPPWINRT/ will be indexed
  Folder: C:/MYPROJECTDIR/SUBDIR1/ will be indexed
  Folder: C:/MYPROJECTDIR/SUBDIR2/ will be indexed
  [...]
File discovery was aborted
  Discovering files: 101 file(s) processed
cpptools/didChangeCppProperties
Done discovering files.
Populate include completion cache.
Discovering files...
cpptools/pauseParsing
cpptools/didChangeCppProperties
cpptools/pauseParsing
cpptools/clearCustomConfigurations
cpptools/clearCustomConfigurations
cpptools/didChangeCustomBrowseConfiguration
Attempting to get defaults from C++ compiler in "compilerPath" property: 'c:/program files (x86)/arm_compiler_5.06u4/bin64/armcc.exe'
MSVC intelliSenseMode specified.  Configuring for compiler cl.exe.
cpptools/resumeParsing
cpptools/didChangeCustomBrowseConfiguration
Attempting to get defaults from C++ compiler in "compilerPath" property: 'c:/program files (x86)/arm_compiler_5.06u4/bin64/armcc.exe'
MSVC intelliSenseMode specified.  Configuring for compiler cl.exe.
cpptools/resumeParsing
cpptools/clearCustomConfigurations
cpptools/clearCustomConfigurations
cpptools/didChangeCustomBrowseConfiguration
Attempting to get defaults from C++ compiler in "compilerPath" property: 'c:/program files (x86)/arm_compiler_5.06u4/bin64/armcc.exe'
MSVC intelliSenseMode specified.  Configuring for compiler cl.exe.
cpptools/resumeParsing
cpptools/didChangeCustomBrowseConfiguration
Attempting to get defaults from C++ compiler in "compilerPath" property: 'c:/program files (x86)/arm_compiler_5.06u4/bin64/armcc.exe'
  Processing folder (non-recursive): C:/PROGRAM FILES (X86)/MICROSOFT VISUAL STUDIO/2019/BUILDTOOLS/VC/TOOLS/MSVC/14.27.29110/INCLUDE
MSVC intelliSenseMode specified.  Configuring for compiler cl.exe.
cpptools/resumeParsing
  Processing folder (recursive): C:/PROGRAM FILES (X86)/WINDOWS KITS/10/INCLUDE/10.0.18362.0/UM/
  Processing folder (recursive): C:/PROGRAM FILES (X86)/WINDOWS KITS/10/INCLUDE/10.0.18362.0/UCRT/
  Processing folder (recursive): C:/PROGRAM FILES (X86)/WINDOWS KITS/10/INCLUDE/10.0.18362.0/SHARED/
  Processing folder (recursive): C:/PROGRAM FILES (X86)/WINDOWS KITS/10/INCLUDE/10.0.18362.0/WINRT/
  Processing folder (recursive): C:/PROGRAM FILES (X86)/WINDOWS KITS/10/INCLUDE/10.0.18362.0/CPPWINRT/
  Processing folder (recursive): C:/MYPROJECTDIR/SUBDIR1
  Processing folder (recursive): C:/MYPROJECTDIR/SUBDIR2
  Processing folder (recursive): [...]
  Processing folder (non-recursive): C:/PROGRAM FILES (X86)/MICROSOFT VISUAL STUDIO/2019/BUILDTOOLS/VC/TOOLS/MSVC/14.27.29110/INCLUDE
  Processing folder (recursive): C:/PROGRAM FILES (X86)/WINDOWS KITS/10/INCLUDE/10.0.18362.0/UM/
  Processing folder (recursive): C:/PROGRAM FILES (X86)/WINDOWS KITS/10/INCLUDE/10.0.18362.0/UCRT/
  Processing folder (recursive): C:/PROGRAM FILES (X86)/WINDOWS KITS/10/INCLUDE/10.0.18362.0/SHARED/
  Processing folder (recursive): C:/PROGRAM FILES (X86)/WINDOWS KITS/10/INCLUDE/10.0.18362.0/WINRT/
  Processing folder (recursive): C:/PROGRAM FILES (X86)/WINDOWS KITS/10/INCLUDE/10.0.18362.0/CPPWINRT/
  Processing folder (recursive): C:/MYPROJECTDIR/SUBDIR1
  Processing folder (recursive): C:/MYPROJECTDIR/SUBDIR2
  Processing folder (recursive): [...]
  Discovering files: 11702 file(s) processed
  0 file(s) removed from database
Done discovering files.
Parsing remaining files...
  tag parsing file: C:\MYPROJECTDIR\MYPROJECTFILE.H
  tag parsing file: [...]
  tag parsing file: C:\PROGRAM FILES (X86)\WINDOWS KITS\10\INCLUDE\10.0.18362.0\WINRT\WRL\ASYNC.H
  tag parsing file: [...]
  [...]
  Parsing: 1918 files(s) processed
Done parsing remaining files.
Database safe to open

If you need, I can query armcc compiler by hand with any command you like and provide the output to you.

[github-actions]

This feature request is being closed due to insufficient upvotes. When enough upvotes are received, this issue will be eligible for our backlog.

[github-actions]

This feature request has received enough votes to be added to our backlog.