Describe the bug
On 2a17de7eabd2d917e70c254b1d93527a028d8a8d
Running run-tests.sh -s /usr/bin/clang++ on macOS with Xcode 15 installed incorrectly identifies "Apple clang version 15" as "clang version 15" (and a couple of the regression tests then fail, as would be reasonable to expect).
I thought this is a regression since https://github.com/hsutter/cppfront/commit/f0018d757d09aae09d18a25a6b22bc3e24eecf85 due to its removal of the code for detecting "Apple clang version 15" which tries to switch over to "Apple clang version 14", but apparently "clang version 15" is still selected with that code still in place on a machine with just Xcode 15 installed and no Xcode 14.
Possible resolutions: Either restore the code to recognize "Apple clang version 15" with more aggressive bail-out behavior in case there's no Xcode 14 also installed, or simply add support for "Apple clang version 15".
Describe the bug On 2a17de7eabd2d917e70c254b1d93527a028d8a8d
Running
run-tests.sh -s /usr/bin/clang++on macOS with Xcode 15 installed incorrectly identifies "Apple clang version 15" as "clang version 15" (and a couple of the regression tests then fail, as would be reasonable to expect).I thought this is a regression since https://github.com/hsutter/cppfront/commit/f0018d757d09aae09d18a25a6b22bc3e24eecf85 due to its removal of the code for detecting "Apple clang version 15" which tries to switch over to "Apple clang version 14", but apparently "clang version 15" is still selected with that code still in place on a machine with just Xcode 15 installed and no Xcode 14.
Possible resolutions: Either restore the code to recognize "Apple clang version 15" with more aggressive bail-out behavior in case there's no Xcode 14 also installed, or simply add support for "Apple clang version 15".