Vscode-cpptools: ARM IntelliSense mode

[csholmq]

Running latest 0.11.0 on latest Insiders.

[bobbrow]

Can you give us a little more information about the project where you're seeing this?

• which OS are you on? Mac/Linux/Windows
• is this a header or a source file?
• what does the c_cpp_properties.json file for the folder you opened look like?
  
  
  
  • does the includePath for the currently selected configuration include all of the paths where the headers files for your project are located?
  
  

If this is getting in the way of your development, you can disable the new IntelliSense engine by adding the following setting to your settings.json file "C_Cpp.intelliSenseEngine": "Tag Parser"

[csholmq]

@bobbrow Apologies. Should have specified better.

I'm on Win10 (creators update) and editing a .c source file in one of my embedded projects. Normally compiled using an ARM toolchain from GCC.

My c_cpp_properties.json is auto generated with the exception of

"name": "Win32",
"includePath": [
    "${workspaceRoot}/Sw/A_XMC/out/obj"
],

So yes, all of my .h files are included and modifying the includePath removed the squiggly lines below all of my #includes, confirming it took effect.

This error message is seen for all the .c files I have tried to open in my project so far.

Switching to a smaller projects seems to work. But I'm not feeling the "context aware IntelliSense".

I can live without the Tag Parser for now, so no worries.

[bobbrow]

Just to clarify, the "Tag Parser" is the "fuzzy" IntelliSense that we've had all along. Changing the setting to "Tag Parser" just reverts you back to the functionality from 0.10.5 and earlier.

The "context aware IntelliSense" is still a work in progress. As of 0.11.0, we have tooltips and error squiggles enabled. Code completion suggestions aren't available in the new engine yet and are currently supplied by the Tag Parser.

I'll see if I can find a bigger C project to test with to try to reproduce your issue.

[csholmq]

Ok. Good information. Didnt realise new completion suggestions were omitted from this release. The tooltips and squiggles work great though :)

What's the difference between browse path and include path? One is recursive and one is not?

[bobbrow]

So the tooltips/squiggles are working for your other projects? Just not the embedded one?

browse.path is used by the tag parser. The folders you specify in that setting are searched recursively.

includePath is essentially the list of paths you would send down to your compiler with -I and is not recursive. You can also add a "defines": ["FOO", "BAR=1"]" setting if you have preprocessor directives that you want the IntelliSense engine to know about.

Your old includePath setting (which was the tag parser's setting prior to 0.11.0) was copied into browse.path when you upgraded.

[csholmq]

Can I run the extension in debug somehow? Maybe readout the raw error message?

[sean-mcmanus]

There's no way currently to run in debug or show logging messages. We might need to add better error reporting. We ship with debug symbols so you could attach a debugger to see call stacks. I've seen the "too many errors" message when the opened file is not really C/C++ and the "No IL available" message when the code was not actually being compiled due to missing defines. Before using the feature, you should make sure the includePath and defines settings are setup correctly to match the compiler's.

[bobbrow]

I just took another look at this issue and thought I would follow up. @csholmq, this seems like a really narrow include path, are all of your headers for the embedded project in this one folder? I wouldn't normally expect to see headers in an obj folder.

"includePath": [
    "${workspaceRoot}/Sw/A_XMC/out/obj"
],

[csholmq]

Yes, that is the case. We have dynamic event handling in our build system so all our .h files are generated and put in the obj folder. No external libraries.

[bobbrow]

I suspect that if squiggles are working fine for your other projects and not this one, then it's possibly because our IntelliSense engine is assuming your code is 64-bit. We haven't exposed a way to change the platform architecture yet.

You can try bumping up the error limit to see if you can get some actionable messages from the IntelliSense engine to see if there's a way to work around it (e.g. adding some "defines" to your c_cpp_properties.json).

Edit %userprofile%\.vscode\extensions\ms-vscode.cpptools-0.11.0\bin\msvc.json by adding "--error_limit", "5000" to the "defaults" array (two separate items). This will raise the error limit for the IntelliSense engine. VS Code won't show you more than 250 at a time though.

[csholmq]

My code compiles as both 32 and 64 bit using GCC. The squiggles work for other, smaller projects. None of my larger though.

I'll give the error limit a try tomorrow. Not sure what to do with my c_cpp_properties.jsom, but I'll try editing the msvc.json as per your suggestion.

[csholmq]

Just tried raising the error limit. I can now see all "errors".

identifier "MMain_Type" is undefined

Then looking at the MMain.h file:

expected a ';'

Looks like the parser doesn't really care for typedef struct declarations. Perhaps you could reproduce?

(I also tried without the define STRUCT_PACKED, but it made little difference.)

[bobbrow]

Thank you. This is helpful. I will take a deeper look into this.

[sean-mcmanus]

I'm not able to reproduce this.

[bobbrow]

We submitted a fix that should resolve the errors you reported in your MMain.h. Can you try with version 0.11.1 of the extension?

[csholmq]

@bobbrow I just tried with 0.11.2 with no luck. Restarted VSCode and even flushed %appdata%\Code - Insiders\User\workspaceStorage.

What fix were you referring to?

[csholmq]

@bobbrow @sean-mcmanus From #779 I understood that this was related to supporting ARM code. In what way? Is there a workaround? And is there a timeline?

[sean-mcmanus]

The IntelliSense engine needs to have certain flags for ARM mode, but we don't have a timeline for when support will be added. Our next release will have a msvc.64.intel.clang.json file, which is for a Windows host targeting Linux (the contents are the same as the current msvc.64.linux.json), but that might not work for ARM. We don't have a verified workaround yet, other than falling back to the Tag Parser, but you could try to replace the contents of the bin\msvc.64.intel.json file with the contents of the msvc.64.linux.json file and add "-D_M_ARM=8" (replace 8 by the arm version) to the end of the "defaults" list, but we don't know if this works yet (we don't have an ARM project that repros the problem you're seeing).

[csholmq]

I seem to have a shift in error messages. But still no luck.

variable "U32" is not a type name

despite

typedef unsigned long       U32;

[csholmq]

I realized I have a custom ARM toolchain. Will try and include the headers from that one as I donät rely on a system global compiler.

[csholmq]

Still no dice with 0.12.1. Here's my config:

{
    "configurations": [
        {
            "name": "Win32",
            "includePath": [
                "${workspaceRoot}/Sw/A_XMC/out/obj",
                "${workspaceRoot}/Sw/P_Xmc/tools/ARM-GCC/arm-none-eabi/include"
            ],
            "defines": [
                "_DEBUG",
                "UNICODE"
            ],
            "intelliSenseMode": "clang-x64"
        }
    ],
    "version": 2
}

With --debug-limit set to 5000 (msvc.64.intel.clang.json), I don't even get any errors. Just FE: 'Compiler exited with error - No IL available'.

[balajivasudevan1]

+1 for the above request.
Some projects which use ARM compiler for Windows Embedded Compact (7 or 2013) also produce the same error:
FE: 'Compiler exited with error - No IL available'

Please consider this for a fix. Would be glad to provide any samples to get this done.

-Balaji.

[sean-mcmanus]

@balajivasudevan1 Yeah, can you help us get a repro project?

[csholmq]

Hey, with 0.12.2 this just started working! Actually, there were three things that needed config, so I'm not sure if this would have worked in earlier versions. Where can I find old releases?

1. Specify build folder with all my .h files (already did)
2. Specify clang-x64 (already did)
3. Specify GCC version

{
    "configurations": [
        {
            "name": "Win32",
            "includePath": [
                "${workspaceRoot}/Sw/A_XMC/out/obj"
            ],
            "defines": [
                "_DEBUG",
                "UNICODE",
                "__GNUC__=5"
            ],
            "intelliSenseMode": "clang-x64"
        }
    ],
    "version": 2
}

[sean-mcmanus]

I don't think we did anything that would have fixed this in the previous release, so the __GNUC__=5 probably fixed it. Older versions aren't available -- there isn't any mechanism for making older versions via the VS Code extension marketplace.

[csholmq]

I see. But then I consider this issue solved. Yay!