Godot stops compiling if I try to test my custom module :'(

Help
,
1

Godot Version

4.6beta

Background

I’ve been working on this wacky audio processing module for.. oh god 4 months. Please forgive me. Anyway. It’s never too late to start writing unit tests. The compiler, however, disagrees with me.

According to the custom modules documentation ( https://docs.godotengine.org/en/stable/engine_details/architecture/custom_modules_in_cpp.html#writing-custom-unit-tests ), testing works like this:

#pragma once

#include "tests/test_macros.h"

#include "modules/summator/summator.h"

namespace TestSummator {

TEST_CASE("[Modules][Summator] Adding numbers") {
	Ref<Summator> s = memnew(Summator);
	CHECK(s->get_total() == 0);

	s->add(10);
	CHECK(s->get_total() == 10);

	s->add(20);
	CHECK(s->get_total() == 30);

	s->add(30);
	CHECK(s->get_total() == 60);

	s->reset();
	CHECK(s->get_total() == 0);
}

} // namespace TestSummator

Then compile with tests=yes and bob’s your uncle. I am unsure of the significance of the “[Module][Summator]” part of the test name. I am testing functions, not a class, so I don’t know what to put instead of Summator.

The Problem

When I compile my test, the compiler freaks out, and decides the gdscript module is suddenly an enemy:

C:\Users\friba\Documents\lang_experiments\godot\modules\gdscript\gdscript_tokenizer.h(161): error C2143: syntax error: missing '}' before 'constant'
C:\Users\friba\Documents\lang_experiments\godot\modules\gdscript\gdscript_tokenizer.h(161): error C2059: syntax error: 'constant'
C:\Users\friba\Documents\lang_experiments\godot\modules\gdscript\gdscript_tokenizer.h(164): error C2143: syntax error: missing ';' before '}'
C:\Users\friba\Documents\lang_experiments\godot\modules\gdscript\gdscript_tokenizer.h(164): error C2238: unexpected token(s) preceding ';'

(A lot more errors)

A quick AI check suggests that there may be a macro redefinition caused by my test case, but it was unable to find the actual macro at the root of the issue.

Here’s my test:

#pragma once

#include "tests/test_macros.h"

#include "core/math/audio_frame.h"

#include "modules/flex_logic_cpp_2/tap_circuit_types.h"

namespace TestFlexLogic {

TEST_CASE("[Modules][FlexLogic] tap_frame conversions") {
  //test the exact conversion of tap_frame in different scenarios.

  //cases
  AudioFrame frames[] = {
    AudioFrame(1.0f, -1.0f),
    AudioFrame(0.0f, 0.0f),
    AudioFrame(0.00006f, -0.00006f),
    AudioFrame(0.5f, -0.5f),
  };

  //first conversion
  tap_frame tframes[] = {
    //edge cases
    tap_frame(frames[0]), // -> 2^16 - 1, 0

    //center/boundary cases
    tap_frame(frames[1]), // -> 2^15, 2^15
    tap_frame(frames[2]), // -> 2^15 + 1, 2^15 - 2; slight positive bias because of the inclusion of 0 in the output range

    //halfway valus
    tap_frame(frames[3]), // -> 2^14 - 1, -2^14
  };

  //expected results of first conversion
  tap_frame expected[] = {
    tap_frame(65535, 0),
    tap_frame(32768, 32768),
    tap_frame(32769, 32767),
    tap_frame(16383, -16384),
  };

  //compare
  for (int i = 0; i < 4; i++) {
    CHECK(tframes[i].left == expected[i].left);
    CHECK(tframes[i].right == expected[i].right);
  }

  //attempt to extract original frames from converted frames
  for (int i = 0; i < 4; i++) {
    tap_frame f = expected[i];
    AudioFrame af = f.audio_frame();
    CHECK(af.left == frames[i].left);
    CHECK(af.right == frames[i].right);
  }

}
};

Nothing too out of the ordinary. I don’t technically need to include audio_frame.h, since its included in tap_circuit_types.h, but removing that did not fix the issue. The only thing that makes the compiler happy is removing this specific test file. After that, it’s content to compile, even with tests=yes.

If you don’t care about the details of the actual test, you can skip this last paragraph:

This stuff has been driving me off the wall. If you have a reliable way to go between floating point audio samples and 16-bit pcm-style samples, please tell me. The function tests a structure that should be able to do the conversion with no data loss, but everything I can come up with is just.. wrong. Comes up with the wrong range, or the wrong offset. I’ve lost all confidence in my ability to do anything with binary math, or math in general, in the process of making this. So, it’s finally test case time. While I could temporarily avoid unit tests if I came to an elegant solution for this, they’d probably still come back to bite.

I don’t have time to check back on this now, but I’ll be back in the evening.

Update, I have now come back. The issues are still there. Shelving unit testing until I can figure this out :frowning: I have tried undefining ERROR, which is apparently a commonly redefined macro and is the enum entry that the compiler crashed on. I don’t really know how any of that works though, and it didn’t fix the issue to undefine ERROR in my test file, either at the top of the file, after the header, or at the end of the file.