Correct files are marked as faulty (red) in the file explorer

[Lorandil]

In many of my projects many ino/cpp/h files are marked red in the file explorer shortly after loading.
If I open the red files ,I see red curls under some includes, declaration, comments, etc...
As a board "Leonardo" was selected, but I have similar results with different boards.

To reproduce:

• Open the blink sketch
• Enable the explorer
• add the line '#include <Arduino.h> at the beginning
• the file name will turn red and the '<' after the include will be underlined with red curls
• remove the '#include <Arduino.h>' line
• the red file name and the curls remain (if the project is more complex than 'blink')

Does typing '#include' trigger/disable some Arduino IDE specific magic?

[JayPi4c]

I've noticed something similar:
When editing a class or a file in general, the changes are not propagated to all other files referring to this file. For example, I have a class Test with an attribute x and a getter. Adding a flag to the getter, other files do not notice this and therefore mark the methods as faulty (red). In the Image below I had it the other way around. Removing the flag and editing the other functions accordingly results in red underlining.

The compiler still does what it is suposed to do, but the red underlining is really annoying.
For some reason this also gets worse, the longer the IDE is running. In the early minutes everything is fine, but the longer the IDE is running, the more I get this kind of error (and also the code suggestions tool gets much slower. I don't know if this is somehow related.)

System: Ubuntu Linux 20.04.3 LTS
Version: Arduino IDE 2.0.0-beta.10 and Arduino IDE 2.0.0-beta.10-nightly.20210823

[per1234]

Thanks for your report @Lorandil. There have been some recent improvements to the Arduino Language Server that provides this capability in the IDE. These improvements are available from the latest release of the Arduino IDE.

Please try again with the latest build of the Arduino IDE and let us know whether or not the bug is fixed for you.

[Lorandil]

Hi again,

I'm sorry to say, that nothing changed for me :(
Is there a problem with my installation?

[per1234]

Thanks for your quick feedback @Lorandil!

So that I can try to better replicate your environment, which version of the "Arduino AVR Boards" platform do you have installed? It will be shown in Boards Manager.

[Lorandil]

I have the following boards installed:

Arduboy home made package V1.2.9
Arduino AVR Boards V1.8.4
Arduino Mega AVR Boards V1.8.7
Arduino SAM Boards V1.6.12
Arduino SAMD Boards V1.8.11
ATtiny MicroControllers V1.0.2
ATTinyCore V1.5.2
esp32 V1.0.5
ESP8266 Boards V2.0.5-beta2
megaTinyCore V2.2.9
STM32 Boards V1.9.0
STM32F1 Boards (STM32duino.com) V2020.8.9

Phew, I should clean up ;)

[Lorandil]

Yay - the problem is gone with the rc2-nightly.20211218 - thank you so much!

Because the error highlighting turned usable now, I was even able to fix a nasty bug that has been haunting me (variable declaration in 'case' without a block {} caused the rest of the 'case' list to be skipped - shouldn't this be a compile time bug?)!

Well done!!!

[If nobody has done anything to fix this, I should add, that I updated all my installed boards to the latest versions]

[Lorandil]

Correction :(
The problem is there again (after changing board (Mega 2560 -> ATtinyCore) and recompiling).
Nonetheless it worked before... as I was shown a real bug...

Edit:
After selecting Mega 2560 & compiling, Arduino Uno & compiling and returning to ATtiny85 (& compiling), the bug appears to be gone again - hopefully for good.
Sorry for the confusion - could this have been a caching problem?

[per1234]

the problem is gone with the rc2-nightly.20211218 - thank you so much!

I'm very glad to hear it. Thanks for taking the time to update the issue.

I'll go ahead and close it as resolved. If anyone runs into the problem again later, you can comment here with the details and I'll investigate.

shouldn't this be a compile time bug?

It is normally, but the "Arduino AVR Boards" and "Arduino megaAVR Boards" platforms use the -fpermissive compiler flag, which downgrades the error to a warning. If you have compiler warnings enabled in File > Preferences, you will see a "crosses initialization of ..." warning in the compilation output.

The potential for harm from the decision to use -fpermissive is tracked here: arduino/Arduino#10154. It happens to be centered around that very code bug. See that issue and the links off of it for details and discussion.