Skip to content

Fix MacOS C++ tests compatibility issues#3677

Open
nycrat wants to merge 11 commits intoUBC-Thunderbots:masterfrom
nycrat:avah/resolve_macos_cpp_test_issues
Open

Fix MacOS C++ tests compatibility issues#3677
nycrat wants to merge 11 commits intoUBC-Thunderbots:masterfrom
nycrat:avah/resolve_macos_cpp_test_issues

Conversation

@nycrat
Copy link
Copy Markdown
Member

@nycrat nycrat commented Apr 5, 2026

Description

This PR makes unit tests and c++ simulated tests able to run on macos, and resolved issues caused by differences between mac and ubuntu (clang & gcc).

  • Remove fedisableexcept which is no longer an issue: Fix Floating Point Errors with Er Force Simulator #2419
  • Add portable wrapper for feenableexcept. Note: on MacOS ARM, it is not possible to crash on floating-point exceptions. So, there is a warning logged when unit tests are ran that floating point exceptions may not be caught.
  • Resolve issue with nanopb: (14:40:33) ERROR: /Users/avah/2_school/team/thunderbots/src/proto/BUILD:64:21: Linking proto/liblink_nanopb_outputs.dylib failed: (Exit 1): cc_wrapper.sh failed: error exe cuting CppLink command (from target //proto:tbots_nanopb_proto) by adding linker flags to use dynamic lookup
  • Fix failing tests (math_functions, typename, thunderscope requirements). More details below.
Screen.Recording.2026-04-06.at.13.55.44.mov

Testing Done

Ran simulated gameplay test suite and everything works. Ran software tests and there were three test failures and how they were fixed:

  • math_functions_test fails due to floating-point rounding error (use EXPECT_NEAR with abs_error of 1e-15 instead of EXPECT_EQ)
  • thunderscope requirements_lock was outdated (just updated it)
  • typename_test did not work since clang (libc++) uses internal namespace std::__1 (fixed by adding macro to the test case to check for macos, could possibly add to functionality of demangleTypeId function to handle this internal namespace)

Resolved Issues

There was no issue made, but in #3496, it was stated that unit tests do not work on macos: #3496 (comment).

Length Justification and Key Files to Review

Review Checklist

It is the reviewers responsibility to also make sure every item here has been covered

  • Function & Class comments: All function definitions (usually in the .h file) should have a javadoc style comment at the start of them. For examples, see the functions defined in thunderbots/software/geom. Similarly, all classes should have an associated Javadoc comment explaining the purpose of the class.
  • Remove all commented out code
  • Remove extra print statements: for example, those just used for testing
  • Resolve all TODO's: All TODO (or similar) statements should either be completed or associated with a github issue

@nycrat nycrat changed the title Resolve MacOS c++ test compatibility issues Resolve MacOS c++ unit tests compatibility issues Apr 5, 2026
@nycrat nycrat changed the title Resolve MacOS c++ unit tests compatibility issues Fix MacOS C++ unit tests compatibility issues Apr 5, 2026
@nycrat nycrat marked this pull request as draft April 5, 2026 00:50
@nycrat nycrat changed the title Fix MacOS C++ unit tests compatibility issues [DRAFT] Fix MacOS C++ unit tests compatibility issues Apr 5, 2026
@nycrat nycrat changed the title [DRAFT] Fix MacOS C++ unit tests compatibility issues [DRAFT] Fix MacOS C++ tests compatibility issues Apr 6, 2026
@nycrat nycrat changed the title [DRAFT] Fix MacOS C++ tests compatibility issues Fix MacOS C++ tests compatibility issues Apr 6, 2026
@nycrat nycrat marked this pull request as ready for review April 6, 2026 22:32
@nycrat nycrat requested review from Lmh-java and maggiettu April 6, 2026 22:33
Copy link
Copy Markdown
Contributor

@Andrewyx Andrewyx left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Left some comments

Comment on lines +88 to +93
@@ -63,7 +89,8 @@ int main(int argc, char **argv)
{
// disable floating point errors when using visualizer due to potential
// floating point errors in QT
fedisableexcept(FE_INVALID | FE_OVERFLOW);
// TODO #(2510) Remove this once we port over to simulated pytests entirely
// fedisableexcept(FE_INVALID | FE_OVERFLOW);
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not remove this now?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh true I'll remove them now

{
double out = linear(0, 0, 2);
EXPECT_EQ(out, 0.5);
EXPECT_NEAR(out, 0.5, 1e-15);
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we use std::numeric_limits<double>::epsilon() here instead?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure that should work

Comment on lines +123 to +126
qtawesome==1.4.0 \
--hash=sha256:783e414d1317f3e978bf67ea8e8a1b1498bad9dbd305dec814027e3b50521be6 \
--hash=sha256:a4d689fa071c595aa6184171ce1f0f847677cb8d2db45382c43129f1d72a3d93
# via -r software/thunderscope/requirements.in
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are these intended dep updates?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes

Comment on lines +230 to +231
# Linker flags required for macos, doesn't affect linux
link_flags = ["-Wl,-undefined,dynamic_lookup"]
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this affect the robots/cross-compile toolchain? They run on ARM.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll look into it a bit more, from what I understand its a difference between apple's llvm ld and gnu ld

@nycrat nycrat force-pushed the avah/resolve_macos_cpp_test_issues branch from 9db98e8 to 031ab83 Compare April 8, 2026 03:00
@nycrat nycrat force-pushed the avah/resolve_macos_cpp_test_issues branch from 914b755 to bbf6240 Compare April 8, 2026 03:03
@nycrat nycrat requested a review from Andrewyx April 8, 2026 18:51
Comment on lines +30 to +35
#if defined(__linux__) && defined(__GNUC__)
feenableexcept(excepts);
return true;
#else
// Unsupported platform
return false;
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks fine, but just curious:
Is there any reason that we did not use polyfills such as
https://github.com/adobe/lagrange/blob/771d85889dd052b545de1fa4a66fe4b3ff2c5e91/modules/core/src/fpe.cpp#L94-L113

Not sure if polyfills like this will work, but I think if it does, it will enable more consistency behaviours across different platforms?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh yea I tested it and it should technically be possible since I got it working for a minimal example https://gist.github.com/nycrat/3bfd574a7b3d328e51ae1b3705de9ebc. But for some reason it doesn't work with gtest. I'll keep trying to make it work since that would be optimal

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants