Remove obsolete compilation error interpretations #1113
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I was not diligent enough in my review duties and missed the migration of some legacy code from Arduino IDE 1.x that was intended to be removed as part of the rewrite (arduino/Arduino#8385 (comment)).
The Arduino IDE attempts to provide some additional guidance to users based on matches against compilation error messages.
This practice was established during a time when some significant breaking changes were made to the common APIs in order to ease the transition.
Since that time, the practice has mostly been discontinued. The interpretations are only valid for very old code that is unlikely to be used by the target users now. So their benefit is negligible. The patterns used are inexact, meaning that the interpretations may be printed inappropriately, which is more and more likely as the cases where the matches would be valid become increasingly rare. When the maintenance burden is taken into consideration, it is clear that the harm is far more than any benefits from these. So they are removed.
Notes for specific interpretations:
The target error was more common prior to Arduino IDE 1.6.6 (released ~6.5 years ago), when it was necessary for the sketch to contain
#include
directives for transitive in addition to direct library dependencies (the "SPI" library is a common transitive dependency).Due to the nature of the "SPI" library, it is not often used directly, and when it is used directly it is done by more advanced users who are unlikely to forget the
#include
directive and would have no need for this interpretation even if they did.It is far more likely for the user to forget an
#include
for a popular library, yet Arduino rightly does not attempt to maintain interpretations for those.The "Sketch > Import Library" menu path was renamed to "Sketch > Include Library" ~7 years ago.
Arduino IDE 0019 was released ~12 years ago. We can safely assume the migration to the new "Ethernet" library API is complete.
Arduino IDE 1.0 was released ~10.5 years ago. We can safely assume the migration to the new Serial API is complete.
This compilation error pattern is now far more likely to occur due to incorrect usage of a completely unrelated occurrence of the common
BYTE
name in the user's code.Arduino IDE 1.0 was released ~10.5 years ago. We can safely assume the migration to the new "Ethernet" library API is complete.
The compilation error patterns are in no way specific to the "Ethernet" library so is prone to false positives (e.g., arduino/Arduino#8385).
Arduino IDE 1.0 was released ~10.5 years ago. We can safely assume the migration to the new "Wire" library API is complete.
Due to the nature of the "Wire" library, it is not often used directly, and when it is used directly it is done by more advanced users who have less need for an interpretation of the compiler error.
I left these in because they are the most "recent" (added due to a breaking change made 7 years ago: arduino/Arduino#3304).
However, I also feel that these are harmful and should either be removed or changed. The problem is that there is a false match when the user attempts to compile the Keyboard or Mouse libraries for a board which does not have native USB support (e.g., Uno, Mega), even when their sketch does contain the
#include
directives that are recommended by the interpretation. That cause of the compilation error matching the pattern is more common than the case where the user is compiling old code or forgot the#include
directive, for which the interpretation is valid.Reviewer checklist