macOS Tahoe (26) support / CI

[jwnimmer-tri]

Is your feature request related to a problem? Please describe.

Apple has released macOS Tahoe (26) yesterday. Drake should officially (https://drake.mit.edu/installation.html) support it, which means testing and CI coverage.

Describe the solution you'd like

Add Tahoe builds to CI, get them passing, elevate to Production, then update our docs & releases.

Since we only support the two most recent versions of macOS, that means dropping Sonoma, first. See #23440 for that.

Additional context

See #20339 for prior upgrade.

[jwnimmer-tri]

For reference, our current macOS CI production jobs are:

• mac-arm-sonoma-clang-bazel-continuous-release
• mac-arm-sonoma-clang-bazel-nightly-everything-release
• mac-arm-sonoma-clang-cmake-nightly-everything-release
• mac-arm-sonoma-clang-cmake-nightly-packaging
• mac-arm-sonoma-clang-cmake-nightly-release
• mac-arm-sonoma-clang-wheel-nightly-release
• mac-arm-sequoia-clang-bazel-continuous-release
• mac-arm-sequoia-clang-bazel-nightly-everything-release
• mac-arm-sequoia-clang-cmake-nightly-everything-release
• mac-arm-sequoia-clang-cmake-nightly-release

[BetsyMcPhail]

@tyler-yankee #21910 has an outdated checklist used last year when adding Sequoia

[tyler-yankee]

@BetsyMcPhail: thanks. I'll list a similar checklist here.

• CI: Determine when EC2 can run Tahoe (see: https://aws.amazon.com/ec2/instance-types/mac/faqs/#topic-3). Add EC2 image and update Jenkins cloud configuration.
• Jobs: Add initial set of experimental Tahoe jobs.
• CI: Update Tahoe references.
• CI: Add production (continuous and nightly) jobs.
• Doc: Add Tahoe support.

[tyler-yankee]

Btw, we were able to upgrade one of our local machines to Tahoe. Summary of a vanilla bazel test //... is below:

• had to use --@drake//tools/flags:eigen_repo=module because pkgconfig defaults to Eigen 3.4.1, which had all sorts of build errors. I know this is tracked and in progress anyways with Support Eigen 5.0.0 #23477, but worth noting.
  • this causes //tools/install/libdrake:allowed_headers_lint to fail -- is this intended?

  ...
  Dependency pollution has leaked into Drake's public headers:
  @eigen+ is not allowed in deps
  ...
  

• possible flake timeout on //multibody/plant/images:py/scripts_test
• I'm ignoring the failure on //examples/hardware_sim:py/hardware_sim_py_test because I believe our local machine is not set up with the network settings that CI uses for the LCM stuff.
• Other test failures: //bindings/pydrake/geometry:py/visualizers_test, //geometry/meshcat_test

I can look into these further when I have time, just wanted to provide a status update.

[jwnimmer-tri]

... had to use eigen_repo=module because pkgconfig defaults to Eigen 3.4.1, which had all sorts of build errors.

This is surprising. Is it a newer Xcode (AppleClang) or something that is causing trouble? I guess maybe our existing images are using 3.4.0 instead of 3.4.1 and maybe 3.4.1 has a regression?

... this causes //tools/install/libdrake:allowed_headers_lint to fail -- is this intended?

Yes, tests are only supported with default options. (Or more precisely, options that are covered by CI jobs that run tests.)

[tyler-yankee]

re: Eigen

The problem seems to be with DRAKE_DEFINE_CLASS_TEMPLATE_INSTANTIATIONS_ON_DEFAULT_NONSYMBOLIC_SCALARS. The current example is coming from multibody/contact_solvers/sap/sap_limit_constraint.cc:200. There are several errors, all of which seem to be Eigen's templating not playing nice with double (I'll truncate error messages for readability):

.../Eigen/src/Core/CwiseBinaryOp.h:40:69: error: no type named 'StorageKind' in 'Eigen::internal::traits<const double>'
   40 |                                               typename traits<Rhs>::StorageKind,

.../Eigen/src/Core/CwiseBinaryOp.h:45:20: error: type 'const double' cannot be used prior to '::' because it has no members
   45 |   typedef typename Rhs::Nested RhsNested;

Eigen/src/Core/../plugins/ArrayCwiseBinaryOps.h:120:10: error: no viable conversion from returned value of type 'const CwiseBinaryOp<[2 * ...], const CwiseNullaryOp<internal::scalar_constant_op<Scalar>, PlainObject>>' to function return type 'const CwiseBinaryOp<[2 * ...], const double>'
  120 |   return (max<PropagateFast>)(other);

Oh, and also related in that file, earlier up:

multibody/contact_solvers/sap/sap_limit_constraint.cc:117:24: error: no viable overloaded '='
  117 |   data.mutable_gamma() = data.y().array().max(0.0);