Hi,

We just use standard visual studio c++ projects to give us intellisense and code editor. Therefore you can create/add files using any method you want. If you use the standard "add new item" and add a .c file I assume you see the wrong icon too? If so then maybe you vs needs a repair.

It would help to have a sample project that shows this issue. I have installed the latest teensy and selected the "arduino 1.6/18" app to use it without issue.

The vs intellisense does struggle at times with certain gcc syntax but I wouldn't expect an issue with basic types! Did you make a build of the new project? building does add extra intellisense support. Microsoft are slowly releasing a new intellisense system based on clang which will be better for gcc.

Did you mean to create a .c file or a .cpp?

Are you seeing these errors in your own code or in he Errors List window? If just in the error window then set it to "open documents" or "build only". The underlying teensy system code is not great for the vs intellisense engine but might have improved in vs2019.

Please follow the guide in yellow at the top of this page to give your full config so that it can be reviewed.

Thanks

OK.  I have this mostly figured out. 

It's a .c/.cpp thing.  Though oddly the problems flow to the header file too. 

I'm calling FlexCAN lib which is C++.  But I'm using (temporarily - fully intend to convert to OO/C++ ASAP... ) ported C code, so I added a .h and .c file. 

Of course (duh moment when I realized this) the compiler (and Intellisense) can't use the FlexCAN classes in the .c file. Very obvious dumb mistake by me on that end. 

Whats less obvious is that it breaks IS parsing vastly beyond just error-ing on the ++ extension keywords and syntax.  It blows up the header file too (which I find odd.. as I'd think the header file would be non-denominational).  Clearly there's some hard coding of matching-named header files with source files in the parsing and checking.  I wonder if I named the header file I_don't_match_source_file.h and the C file I_don't_match_header.c if it would work better (which is to say confine my errors to the .c file...).  

But beyond the header it isn't just C++ keywords like "class"... bool doesn't work, and, furthermore, it will cause erratic problems even with the parsing of the master .ino file - its like the presence of the .c file at all forces all files to be parsed as .c only, or 'sometimes' parsed as C. Though that doesn't explain totally the loss of 'bool' and 'uint8_h' keywords/identifiers which naturally should be fine (why is uint8_h busted but uint32_h not?)  

Another symptom is sometimes includes even in the INO are not recognized either as you move between the files back and forth... The behaviour is odd and erratic, sometimes the include-related code lines break and sometimes they look fine.  An example would be declaration of an Adafruit_SSD1306 display aka:

Adafruit_SSD1306 display(OLED_DC, OLED_RESET, OLED_CS); 

Sometimes looks fine, other times, broken/errored/acts as if there is no include. 

I have made 2 simplified code projects I will email as above.  One total screwed up w/ .c and the other (almost) fine w/ a .cpp instead. 

I still have a wee problem with collect2.exe and multiple declaration, clearly a result of var initilization in the header.  Thats' just a dumb porting error vs the legacy code structure copy pasted which I can fix easily.  The oldskool code nazi contingent on StackOverflow would probably be enraged at me for even thinking to init the vars in a header file anyway