Arduino: 1.8.7 (Linux), Board: "Arduino Nano, ATmega328P"
sketch_oct27a:15:16: error: variable or field 'storeData' declared void
void storeData (DataEntry dataEntry) {
^
sketch_oct27a:15:16: error: 'DataEntry' was not declared in this scope
exit status 1
variable or field 'storeData' declared void
This report would have more information with
"Show verbose output during compilation"
option enabled in File -> Preferences.
I'm baffled. This function used to compile just fine and as far as I know is perfectly valid C++, then I made some changes in my actual sketch, and compilation started to fail. This super minimal sketch also fails, same error message.
Some research told me that the real issue the compiler has is that type DataEntry is not declared, but it definitely is!
As said it USED to compile for me.
Restarted the IDE already, no luck.
Copied to new sketch (clean directory), fail.
Tried new struct, fail.
So I guess some temporary file got in the way - but what/where??
sterretje:
. . .
Reason is possibly that the Arduino builder puts a prototype before the definition of the struct.
That looks like it. In sloeber (which will use the same build mechanism), the generated .cpp looks like this:
#ifdef __IN_ECLIPSE__
//This is a automatic generated file
//Please do not modify this file
//If you touch this file your change will be overwritten during the next build
//This file has been generated on 2018-10-27 08:49:55
#include "Arduino.h"
void storeData(DataEntry dataEntry) ;
void setup() ;
void loop() ;
#include "BareMinimum.ino" // this is wvmarle's file
#endif
The problem appeared after making multiple changes to my sketch. First I suspected a missing ; or } or so somewhere (the usual culprit of weird errors) but that wasn't the case. After commenting out basically everything it still didn't compile!
Well, I finally found out what caused the problem.
The sketch as posted in OP I managed to compile after I logged off and logged on again (apparently indeed some temp file that got in the way and that got cleared that way). So that was good progress. Then back to my original sketch, and
I have a function:
void setupWebsite() {
// Enable some callbacks for the web server.
}
And another one:
void setupLogging() {
}
As soon as I enable either function in code (empty body), compilation fails. Renaming the function to beginLogging(), no problem. So the issue is the name of the function itself: as soon as it starts with setup the compiler trips somehow. Same if I rename the second to loggingsetup(), it fails. Naming it loggingSetup() and there is no problem.
I named them setupLogging and setupWebsite as this were functions called from setup()...
I can't reproduce this in my minimal sketch - that one compiles just fine - so there must be more to my sketch that triggers this bug, as that's what I think it is: a bug in the Arduino environment.
Boards are up to date, and I'm trying to compile for ESP8266 (NodeMCU). Should have mentioned that part. Can't compile for Arduino due to missing ESP8266 specific libraries (web server and so).
Right... but definitely not from myself, as I don't use macros in that sketch.
So that would mean some library has something like
#define setup something
?
Same sketch had more trouble: the WiFiManager type can not be found if the library is included in the file it's used (sketch is split in five separate files), but no issues if it's at the top of the primary .ino - it's a callback function so I guess this has to do with unexpected order of compilation.
Could be - I haven't found a way to reproduce my problem in a small sketch, but indeed it was the "setup" substring in the function names that caused the trouble.
Indeed. Looks like the same (kind of) issue. Thanks for the info!
Very frustrating, cost me a few hours of hair pulling as of course I assume the fault is with me, after all so far compiler errors have always been my own fault. Also no idea really what to look for or what could be the actual problem (hence the rather nondescript subject).
I upgraded from another 1.8.something as it was every time doing a full recompile (something like "parameters changed, recompiling all), so compiling of just a small change took ages. Which also was very frustrating.