It appears that particle build may be giving the wrong line number and/or displaying/highlighting the wrong line text on compile error?
Tom
1 Like
I see the same problem. The line number of the error is correct, but the display of the line with the error is incorrect.
Example screen shot.
This is a common C compiler thing, since your code cannot be āunderstoodā properly due to violating the semantic structure the compiler has to the last thing he did actually āunderstandā.
The line number and error indicator should be understood as hints where the error most likely will be found rather than an exact location - since it does not compile the compiler obviously doesnāt quite get whatās meant and has to guess a bit 
1 Like
@ScruffR ā¦ thanks for the reply, but Iām afraid you havenāt looked into this deeply enough and your answer is incorrect. There is definitely something wrong here, and it can be demonstrated in a few ways.
First, in the example I gave the compiler has correctly understood the line with the error, but the line it shows is different than the one it reports. The error is on line 8, character 1, where the close brace ā}ā is identified as the syntax error. But the line it shows is from much earlier in the file, line 3, although the caret correctly shows the first character.
Secondly, you can demonstrate this error with examples where there are no syntax errors, but rather just semantic errors. See this screen shot.
In this example I introduced an error and a warning. In both cases the correct line and character position is identified by the compiler. In the first case the error is on line 12, character 15 where I attempted to ācallā a double. Again, the line it shows is wrong, although the caret correctly identifies the position on the line.
In the second case the warning on an unused local again shows exactly the same characteristic.
If I were to guess, what looks like is going on is an off-by-one error or other indexing problem when trying to retrieve the line that goes with a given warning or error. Note how in this second example it shows line 7 for the error that is on line 12. I suspect that my original example shows something similar where the declaration of āiā is displayed because it is āunusedā or used before initialized depending on how the compiler interprets that.
Anyway, this isnāt a major problem, but it is a bug, and should not be dismissed as just a crazy compiler thing.
1 Like
Hmm, I see now!
Sorry for answering prematurely without actually trying it out 
Iāve now tried your samples and got the same results but also a new (hopefully less wrong) explanation; but Iām open for another rebuke (maybe by @Dave - my personal master of preprocessors ;-))
If you add this at the top of your sketches, the lines are shown correctly
#pragma SPARK_NO_PREPROCESSOR
#include "application.h"
So my suspission now is, that the preprocessor adds some lines to the ābehind the scenesā code that is taken for the error messages while the row:column figures are actually taken from the pre-preprocessor code.
Maybe @Dave could comment on this and redeem me for my earlier ignorance 
1 Like
That could be a viable explanation, but if that is the case, itās probably a situation where the preprocessor is failing to add proper documentation of this factā¦
When I look at normal preprocessor output, itās littered with lines that look like:
# 9 "file.h" 2
# 24 "file.h"
<some code>
# 12 "original.c" 1As near as I can tell, this is # <original-line-number> āfilenameā <nesting-depth>
where original-line-number is the line number in the applicable source file and nesting-depth indicates how many levels of include we are currently following (the source file handed to gcc is depth 1, files it includes are depth 2, files those includes include are depth 3, etc.).
I believe these lines are placed there by the preprocessor in order to allow the compiler to know that a line that went wrong in line 985 of the preprocessor output was actually line 28 of the original source file or line 192 of foo.h, etc.
However, if the preprocessor didnāt provide these correctly, one would expect the error messages to point to the wrong line as well as the incorrect line being displayed.
Rather I think this is an error in the IDE processing the output of the compiler as command line compilers donāt generally display the line of code where the error occurred, just the message about where it occurred. It appears that the IDE is building a list of items from this output and then losing its place in correlating the list of errors with the lines of code retrieved.
There definetly is something fishy 
Maybe itās time to reping @Dave and also @suda - they might know of this already, but just to bump things
2 Likes
Hey All!
Good questions! The pre-processor does include some #line pragmas to make sure the line numbers are correct after injecting function declarations and the application.h include statement. Whatās strange here is that the line number is correct, but the line of code suggested by the GCC compiler appears to be wrong. Those line numbers and code suggestions both come from GCC, so Iām a bit surprised that they would be mismatched, but we are using a fairly new version of GCC.
I think Iād need to do some more research to track this down (testing using old gcc versions, looking for other similar gcc bug reports, checking our makefiles, etc), but Iāll post back here when I find out more.
Thanks,
David
3 Likes
I have occasionally seen this kind of thing on other GCC environments. However, it definitely seems to be a more regular occurrence in the Particle world.
Any update on this?
We are still getting correct line numbers but wrong code fragments 
1 Like
and in
FYI, in web IDE with firmware 0.5.2 I get:
test-ctc-south.cpp:1:0: warning: ignoring #pragma SPARK_NO_PREPROCESSOR [-Wunknown-pragmas]
#pragma SPARK_NO_PREPROCESSOR
Has the name changed?
That warning is a bit confusing, but correct, since you are looking at the output of the GCC preprocessor which has no idea about the Wiring preprocessor that had already āmessedā with the .ino file (or rather not after having been told not to with this #pragma).
So since that instruction is meant for the first preprocessor in the line, which does in fact interpret it correctly, but not remove it from the output, the second preproc has no idea what this should be and warns about it - but that can be ignored without second thought
There is some serious fubar going on in the GUI/web IDE and 0.5.2 firmware:
If I start my code with
//#pragma SPARK_NO_PREPROCESSOR
it compiles/verifies OK. Note the comment. This statement should be ignored, but (as below) apparently it isnāt.
This can be seen when I try
#pragma SPARK_NO_PREPROCESSOR
and get the same results (verifiedā¦). The fubar happens when I try to DELETE this line (and not simply comment it out) - I get a stream of consciousness flow of warnings with a compile time error related to code that is correct in the source.
The error sure feels like a fail from the preprocessor trying to do its own extern preprocessing - and screwing things up. It is is unnecessary for this code, which explicitly forward declares all its functions.
test-ctc-south.cpp:36:23: error: variable or field 'initI2Cexpander' declared void
void initI2Cexpander( I2Cexpander *m );
^
test-ctc-south.cpp:36:23: error: 'I2Cexpander' was not declared in this scope
test-ctc-south.cpp:36:36: error: 'm' was not declared in this scope
void initI2Cexpander( I2Cexpander *m );
^
test-ctc-south.cpp:30:52: warning: deprecated conversion from string constant to 'char*' [-Wwrite-strings]
bool sendControlsTo_CP_Sargent(void);
^
make[1]: *** [../build/target/user/platform-6test-ctc-south.o] Error 1
make: *** [user] Error 2
Error: Could not compile. Please review your code.
(Edit: The shift errors were benign, and I removed them from this post to simplify things)
The Spark/Particle/Arduino pre-processor creates forward declaration for all your functions so you donāt have to. This is one of the simplification that Arduino tries to bring to non-C programmers.
If you have forward declarations, then you will get two (or four) declarations for each function and things will come off the rails pretty quickly. If you have a class and use the preprocessor on a .ino file containing that class, it will fail in my experience.
I think the pre-processor is pretty dumb and just grepās for the pragmaāit is not surprising to me that it ignores the comment characters.
then you will get two (or four) declarations for each function and things will come off the rails pretty quickly.
I've got to call a "BS" on this statement... 
if you have a class and use the preprocessor on a .ino file containing that class, it will fail in my experience.
...and this is somehow OK?
If this is what the Particle Web IDE preprocessor does, it is broken. Period.
Multiple CORRECT / IDENTICAL forward declarations in a compile unit is not a problem for the C compiler - or the C/C++ language definition.
The bug is that the pre-pre-processor is generating WRONGLY PLACED forward declarations - it is apparently generating correct declarations, but placing them BEFORE the include file lines that define the data types that they require.
Worse, the Arduino IDE does not behave this way, making this a Particle-only issue. The current Arduino preprocessor only adds forward declarations if needed, and it places them into the intermediate file in "the right place". It does this by leveraging the C/C++ compiler itself instead of creating another buggy pre-compiler tool.
Maybe it is time to resync with the Arduino code base to pick up all the fixes (like for this) that the community has produced in the last several years? Maybe use what the Oak folks did and make the Photon/Core/Electron all work with the native Arduino IDE?
It's a real bitch trying to support both the Arduino and divergent Particle worlds...
Could someone PLEASE fix this problem? The error message points to the right line number, but the line it prints is still from somewhere else. Today it told me that a line which is a comment had an error in it.
Or better yet, is there a version of Particle Dev that will run in Windows XP so I can stop using the online IDE entirely?
@Michele, this is not a problem with Particle Dev but with the compiler itself. It takes itās best shot at identifying the line where the error is but the results are not always valid (as you observed). Look the the description of the error for guidance as to where the actual error is located. It is typically close to the line (mis-)identified in the error message.
The issue is regarding the online build tool.
The compiler output includes the correct line number, but displays the code fragment shown is not that line.
If you see the picture posted in Jul 15, the message says line 12:15 which is spot on, but the code fragment shown is line 7ā¦
@MORA, this is still a compile issue, not the IDE itself. Try with Particle CLI and you will most likely get the same output. @bko, @ScruffR any comments?
I agree with that - Web IDE (Build), CLI and Desktop IDE (Dev) all use the online build farm with the same compiler settings, so this issue will be omnipresent.
But Iād also consider this more a nuisance than an issue since when you get an error you should go to the line number anyway, since the actual cause of the error might be a few lines up anyway (e.g missed braces or semicolon or declarations, ā¦)
1 Like