Hi,
I'm not quite sure if this is the right place or if arduino-builder would be better.
The following stripped-down code used to compile with an older version of the IDE (1.8.5) and does no longer with 1.8.10:
namespace
{
struct State {
};
struct Configuration {
enum class AutoMode : uint8_t {
INDEPENDENT,
LINKED
};
};
struct StatsMinMax {
};
struct StatsDurations {
};
enum class Command : uint8_t {
GET_STATE,
GET_CONFIG,
GET_STATS_MIN_MAX,
GET_STATS_DURATIONS
};
void dump(const StatsMinMax& stats_min_max, const StatsDurations& stats_durations)
{
}
template<typename T>
Command getCommand(const T& type);
template<>
Command getCommand(const State& type)
{
return Command::GET_STATE;
}
template<>
Command getCommand(const Configuration& type)
{
return Command::GET_CONFIG;
}
template<>
Command getCommand(const StatsMinMax& type)
{
return Command::GET_STATS_MIN_MAX;
}
template<>
Command getCommand(const StatsDurations& type)
{
return Command::GET_STATS_DURATIONS;
}
}
void setup()
{
}
void loop()
{
}
The output is:
sketch_nov27a:33:49: error: 'getCommand' is not a template function
^
sketch_nov27a:39:57: error: 'getCommand' is not a template function
^
sketch_nov27a:45:55: error: 'getCommand' is not a template function
^
sketch_nov27a:51:58: error: 'getCommand' is not a template function
^
exit status 1
'getCommand' is not a template function
Seems like the template function prototype isn't picked up. Removing dump() makes it compile again as does removing the enum class inside Configuration. A real workaround is to define the prototype like so:
template<typename T>
Command getCommand(const T& type)
{
}
As template function prototype declaration is normally (speaking for C++) sufficient it would be nice if the Arduino toolchain could cope with it.
Best,
Fl枚ssie
Hi @Floessie ,
I moved the issue to arduino-cli since the builder repo is now just a "frontend" for the cli .
The problem here is that spurious prototypes are being inserted inside the namespace (here's the preprocessed file)
enum class Command : uint8_t {
GET_STATE,
GET_CONFIG,
GET_STATS_MIN_MAX,
GET_STATS_DURATIONS
};
#line 27 "/tmp/arduino_modified_sketch_538281/sketch_nov29b.ino"
void dump(const StatsMinMax& stats_min_max, const StatsDurations& stats_durations);
#line 33 "/tmp/arduino_modified_sketch_538281/sketch_nov29b.ino"
template<> Command getCommand(const State& type);
#line 39 "/tmp/arduino_modified_sketch_538281/sketch_nov29b.ino"
template<> Command getCommand(const Configuration& type);
#line 45 "/tmp/arduino_modified_sketch_538281/sketch_nov29b.ino"
template<> Command getCommand(const StatsMinMax& type);
#line 51 "/tmp/arduino_modified_sketch_538281/sketch_nov29b.ino"
template<> Command getCommand(const StatsDurations& type);
#line 27 "/tmp/arduino_modified_sketch_538281/sketch_nov29b.ino"
void dump(const StatsMinMax& stats_min_max, const StatsDurations& stats_durations)
{
}
template<typename T>
Command getCommand(const T& type);
template<>
Command getCommand(const State& type)
{
@cmaglie any idea on why they are being generated?
I think I got it (more or less).
The generated prototypes are inserted just above the first function implementation.
In this way, template<> Command getCommand(... is being declared before template<typename T> Command getCommand(const T& type) (which is not valid/compilable C++).
"Implementing" template<typename T>Command getCommand(const T& type) "fixed" the issue since the forward declaration is created in the right place. Removing dump() / moving template<typename T> Command getCommand(const T& type); above dump() "fixes" it too.
Removing the namespace fixes it too because no prototype is being generated (and it's the right behaviour since no-one forward uses them)
@facchinm Is there a switch to make the builder assume that the sketch is already valid C++ (kind of "expert mode")?
The official way to avoid the preprocessor dance is to rename all "expert" files to .cpp. The preprocessor only fires on .ino but that file can simply be an empty placeholder, while all the code can be contained in normal cpp files with forward declarations.
@rsora Just saw the "waiting for feedback". Were you waiting for my feedback? Sure I can work around the problem with a .cpp file, but I wasn't aware of any progress on the preprocessor regarding this bug, so I assume it's still present.