VSCode, PlatformIO and AVR: Header files not resolved correctly

[neilyoung]

VSCode Insider Version 1.12.0-insider (1.12.0-insider)

Hi,

trying to use VSCode together with PlatformIO and Atmel framework AVR. Generally ok.

Even though there is a path to the right include headers configured and recognised (ALT-CLICK opens the .h file), there is a problem. Several symbols are underlined in red. The tooltip says "Identifier xxx is undefined". Pressing ALT while hovering an additional entry offers "Click to view/show xxx definitions".

The reason is that the appropriate ATTiny header file cannot be included directly, but needs to be "bootstrapped" (as suggested by AVR) by

#include <avr/io.h>

from where the proper header is included by e.g.

#elif defined (__AVR_ATmega16U2__)
#  include <avr/iom16u2.h>
...

Obviously VSCode is unable to follow this deep link and it marks the definitions red. Including the proper platform file into the source doesn't work, because compilation fails with

#error "Attempt to include more than one <avr/ioXXX.h> file."

due to a previous macro definition in io.h

How can I recover from this?

[neilyoung]

OK, nobody. Will go and use the proper tool instead: Atmel Studio

[bobbrow]

Sorry, I was on vacation last week and am catching up on issues this week. Since you are on the insider build, you were picking up the new IntelliSense engine by default. If you add the symbol __AVR_ATmega16U2__ to your c_cpp_properties.json file in the "defines" array, the IntelliSense engine should be able to include the header that you indicated in your issue report.

[neilyoung]

@bobbrow Hi Bob, thanks for chiming in. Sorry for being so impatient.

OK, tried it, but did just partly work.

My c_cpp_properties.json now contains this:

            "defines": [
                "__AVR_ATtiny2313A__"
            ],

The red underlines are gone now in my source code. Hovering over a symbol opens a popup like this

But if I click I'm landing in a completely unrelated header file.

So a little improvement, but not completely correct.

My header includes are like so:

#include <avr/builtins.h>
#include <avr/cpufunc.h>
#include <avr/io.h>

#include <avr/interrupt.h>

#include <avr/sleep.h>
#include <avr/wdt.h>
#include <util/delay.h>

I had to patch io.h a little, because platformIO currently does not support ATTiny2313A, but ATTiny23 instead, so there is no clean way to get the AVR_ATtiny2313A currently out of the build environment. My change to io.h is illustrated below:

#elif defined (__AVR_ATtiny2313__)
#  include <avr/iotn2313a.h>                         // Originally iotn2313.h instead
#elif defined (__AVR_ATtiny2313A__)
#  include <avr/iotn2313a.h>

[bobbrow]

What you are experiencing with the symbol navigation is currently expected. Only tooltips and error squiggles are powered by the new IntelliSense engine right now.

Everything else is powered by our tag parser which does not respect the "defines" you set in the c_cpp_properties.json file. It will recursively traverse the paths listed in "browse.path" in your c_cpp_properties.json file and add all symbols it finds to the database. This is why symbol navigation is reporting multiple definitions of the same symbol. A fix for this will be coming in a future release, but I don't have a timetable for it right now.

[bobbrow]

Minor correction, the tag parser won't automatically parse all of the files under the "browse.path" settings unless you also set "browse.limitSymbolsToIncludedHeaders" to false. But when it parses through <avr/io.h> it will ignore the #if defined directives and process every #include in the file.

[neilyoung]

OK, thanks for elaboration. browse.path just contains the avr include ~/.platformio/packages/toolchain-atmelavr/avr/include and limitSymbolsToIncludedHeaders is set to true.

I think I have to live with that :)

Regards

[neilyoung]

Sorry, I need to raise this issue again. I have now opened an older project, which worked fine with VSCode Preview and cpp tools.

Now I'm getting red underlined symbols, which resolve fine if I hover and/or click. The same with include, which are blamed to be not there, but open fine on click.

What can be the reason? I suppose it is related to one of the latest updates, because it worked fine in the past.

INFO: The same doesn't happen with 0.10.1 under April 2017 version of VSCode

[sean-mcmanus]

Your includePath and defines should be set to match your build. What error messages are shown in the Problems window? Are you using IntelliSenseEngne "Default"? You can also change errorSquiggles to false.

[bobbrow]

The red underlined symbols is a new feature which is turned on by default for VS Code Preview (insiders). If you do not want to see the red underlines, then you can disable them via "errorSquiggles": false in your settings.json. If you don't want to use the new IntelliSense engine at all, you can disable it by setting "intelliSenseEngine": "Tag Parser" in your settings.json file.

[neilyoung]

@bobbrow Hmm. Aren't red underlines problem indications somehow? What shall this tell me?
@sean-mcmanus Include paths are set as it was set before properly. I always just point to the super directory of an include, hoping Intellisense will traverse subdirs too (?). At least it did in previous versions. And yes, I want to have Intellisense

[sean-mcmanus]

The includePath setting is non-recursive, just like they're non-recursive in your build settings, but the location it looks for local headers is relative to the cpp file that currently being processed, just like when compiling. browse.path is recursive by default unless * is used (although I think there's a bug on Linux that always makes it recursive). In other words, the old includePath is now the browse.path.

[bobbrow]

I need to write a help topic about includePath vs browse.path. I'll open a new issue for that.

[neilyoung]

@bobbrow @sean-mcmanus I don't get the difference at all... I always held both at the same values

An example for a problem is shown here:

The problem window shows this:

On click I'm getting lead to a file which is located at:

/Users/me/.platformio/packages/framework-arduinoespressif8266/libraries/ESP8266WiFi/src/include/wl_definitions.h

I add this path to both entries in

        "includePath": [
            "/Users/me/.platformio/packages/framework-arduinoespressif8266/libraries/ESP8266WiFi/src/include/",

           "path": [
                "/Users/me/.platformio/packages/framework-arduinoespressif8266/libraries/ESP8266WiFi/src/include/",

which is BTW cumbersome...

The problem remains. And all this was not necessary in a couple of versions before.

[bobbrow]

if you open wl_definitions.h, do you see any squiggles in there? Is there a #define that needs to be set in order for WL_CONNECTED to be defined by the header? If so, then that needs to be added to the "defines" array.

[neilyoung]

No, there is no squiggle.

[neilyoung]

The same BTW for a LOT of other symbols, which have all been available before:

Is declared in

/Users/me/.platformio/packages/framework-arduinoespressif8266/tools/sdk/include/osapi.h

Included in the config, but not available.

[bobbrow]

When you hover over that enum with your mouse cursor, do you get a tooltip or do you get nothing? What I'm trying to determine is whether this enum definition is hiding inside a #ifdef/#endif block that is not being entered by the IntelliSense engine. If no tooltip pops up, then the engine thinks you're inside an inactive preprocessor block.

[neilyoung]

Would that be OK?

[bobbrow]

Is there some other extension providing tooltips too? Only the bottom half of that tooltip comes from our extension. It looks like our extension knows about the type. I'll see if I can reproduce this error on my end.

[neilyoung]

Yes, seems so, although I cannot tell, which extension causes this. At least there is just one small window (the one you call "lower window") when I'm hovering w/o pressing "CMD". CMD/Hover adds that extra information. Sorry.

[neilyoung]

In the meantime I return to the April VSCode, which works as expected.

[bobbrow]

Just set "intelliSenseEngine": "Tag Parser" in your settings.json file, and the extension will revert to the 0.10.5 behavior

[neilyoung]

Indeed, that heals my project :) Thanks for the hint. Although - not entirely. There is still this little yellow bulb on the left, demanding to "Add include path to settings"...

[bobbrow]

Oh, did the red underlines not go away?

[neilyoung]

They are gone.

[bobbrow]

That's strange. The light bulb should only appear when you move the cursor onto one of the underlines. If you close and reopen the file, does it go away?

[neilyoung]

Getting "Microsoft.VSCode.CPP.Extension.darwin has been terminated unexpectedly" since a couple of hours whenever I close VSCode.

But yes, after restart the bulb is gone too.

[bobbrow]

If you have any crash reports for that process under ~/Library/Logs/DiagnosticReports that you can share with us, we will take a look at them.

[neilyoung]

Where to send?

[bobbrow]

You can zip them up and drag them into the comment box and GitHub will upload them to this issue.

[neilyoung]

DiagnosticReports.zip

[bobbrow]

Thank you

[neilyoung]

I'm still suffering from the crashes in Microsoft.VSCode.CPP.Extension.darwin. Any news here?

[sean-mcmanus]

The next update will fix some crashes and uses an auto-restart for intermittent crashes and falls back to the Tag Parser, so the crash popup won't appear anymore. We have a bunch of known crashes on our backlog we plan to investigate/fix later.

[ivankravets]

@neilyoung could you re-test with the latest version of VSCode and PlatformIO extension? It should work now.

[neilyoung]

@ivankravets Noticed it a couple of weeks ago. Did not check it with the latest version yet. Will do