{"thread":{"id":"56225","subject":"[PATCH] makefile: update detect-compiler for newer Xcode version","startedAt":"2021-08-06T08:06:59Z","lastAt":"2021-08-09T18:10:22Z","messageCount":22,"participants":["Carlo Marcelo Arenas Belón","Bagas Sanjaya","Carlo Arenas","Atharva Raykar","Eric Sunshine","Junio C Hamano","Jeff King","Ævar Arnfjörð Bjarmason"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"432154","messageId":"20210806080634.11869-1-carenas@gmail.com","threadId":"56225","inReplyTo":null,"subject":"[PATCH] makefile: update detect-compiler for newer Xcode version","fromName":"Carlo Marcelo Arenas Belón","fromEmail":"carenas@gmail.com","sentAt":"2021-08-06T08:06:34Z","receivedAt":"2021-08-06T08:06:59Z","isPatch":true,"sender":{"key":"carenas@gmail.com","avatar":"https://avatars.githubusercontent.com/u/76036?v=4"},"body":"1da1580e4c (Makefile: detect compiler and enable more warnings in\nDEVELOPER=1, 2018-04-14) uses the output of the compiler banner to\ndetect the compiler family.\n\nApple had since changed the wording used to refer to its compiler\nas clang instead of LLVM as shown by:\n\n $ cc --version\n Apple clang version 12.0.5 (clang-1205.0.22.9)\n Target: x86_64-apple-darwin20.6.0\n Thread model: posix\n InstalledDir: /Library/Developer/CommandLineTools/usr/bin\n\nso update the script to match, and allow DEVELOPER=1 to work as\nexpected again in macOS.\n\nSigned-off-by: Carlo Marcelo Arenas Belón \n---\n detect-compiler | 2 +-\n 1 file changed, 1 insertion(+), 1 deletion(-)\n\ndiff --git a/detect-compiler b/detect-compiler\nindex 70b754481c..c85be83c64 100755\n--- a/detect-compiler\n+++ b/detect-compiler\n@@ -44,7 +44,7 @@ clang)\n \"FreeBSD clang\")\n \tprint_flags clang\n \t;;\n-\"Apple LLVM\")\n+\"Apple LLVM\"|\"Apple clang\")\n \tprint_flags clang\n \t;;\n *)\n-- \n2.33.0.rc0.443.g98cc19b6c0\n\n"},{"id":"432161","messageId":"8d3d5d2e-cad9-2b02-13d0-b6be1b96f730@gmail.com","threadId":"56225","inReplyTo":"20210806080634.11869-1-carenas@gmail.com","subject":"Re: [PATCH] makefile: update detect-compiler for newer Xcode version","fromName":"Bagas Sanjaya","fromEmail":"bagasdotme@gmail.com","sentAt":"2021-08-06T12:00:40Z","receivedAt":"2021-08-06T12:00:47Z","isPatch":true,"sender":{"key":"bagasdotme@gmail.com","avatar":"https://avatars.githubusercontent.com/u/40219486?v=4"},"body":"On 06/08/21 15.06, Carlo Marcelo Arenas Belón wrote:\n> -\"Apple LLVM\")\n> +\"Apple LLVM\"|\"Apple clang\")\n> \tprint_flags clang\n\nWhy not just s/Apple LLVM/Apple clang/?\n\n-- \nAn old man doll... just what I always wanted! - Clara\n"},{"id":"432174","messageId":"CAPUEspgV3KoUOo=EDss+PTdHO6+Cp=ODDjYm7WRm8F0HHgJ08w@mail.gmail.com","threadId":"56225","inReplyTo":"8d3d5d2e-cad9-2b02-13d0-b6be1b96f730@gmail.com","subject":"Re: [PATCH] makefile: update detect-compiler for newer Xcode version","fromName":"Carlo Arenas","fromEmail":"carenas@gmail.com","sentAt":"2021-08-06T13:32:55Z","receivedAt":"2021-08-06T13:33:09Z","isPatch":true,"sender":{"key":"carenas@gmail.com","avatar":"https://avatars.githubusercontent.com/u/76036?v=4"},"body":"On Fri, Aug 6, 2021 at 5:00 AM Bagas Sanjaya wrote:\n>\n> Why not just s/Apple LLVM/Apple clang/?\n\nbecause that would break it for older versions of Xcode that reported\nthemselves as \"Apple LLVM\" and I am not even sure when the change was\nmade to even consider those versions as obsolete.\n\nEither way, I am sure once we figure out which versions are affected\nand which versions macOS developers care enough for, that would be the\nobvious next step.\n\nnote that DEVELOPER=1 was broken for a while in macOS and that also\naffects CI, and it is still known to be suboptimal, since version\nnumbers for Xcode compilers are not always representative of what\nfeatures can be found in the opensource version with similar numbers.\n\nCarlo\n\nCarlo\n"},{"id":"432175","messageId":"m2sfzmu1t7.fsf@gmail.com","threadId":"56225","inReplyTo":"20210806080634.11869-1-carenas@gmail.com","subject":"Re: [PATCH] makefile: update detect-compiler for newer Xcode version","fromName":"Atharva Raykar","fromEmail":"raykar.ath@gmail.com","sentAt":"2021-08-06T13:42:44Z","receivedAt":"2021-08-06T13:42:51Z","isPatch":true,"sender":{"key":"raykar.ath@gmail.com","avatar":"https://avatars.githubusercontent.com/u/24277692?v=4"},"body":"\nCarlo Marcelo Arenas Belón writes:\n\n> 1da1580e4c (Makefile: detect compiler and enable more warnings in\n> DEVELOPER=1, 2018-04-14) uses the output of the compiler banner to\n> detect the compiler family.\n>\n> Apple had since changed the wording used to refer to its compiler\n> as clang instead of LLVM as shown by:\n>\n> $ cc --version\n> Apple clang version 12.0.5 (clang-1205.0.22.9)\n> Target: x86_64-apple-darwin20.6.0\n> Thread model: posix\n> InstalledDir: /Library/Developer/CommandLineTools/usr/bin\n>\n> so update the script to match, and allow DEVELOPER=1 to work as\n> expected again in macOS.\n\nThanks for submitting this enhancement!\n\nFor those of us using Homebrew and using the LLVM installation from\nthere, we get:\n\n$ cc --version\nHomebrew clang version 12.0.1\nTarget: arm64-apple-darwin20.5.0\nThread model: posix\nInstalledDir: /opt/homebrew/opt/llvm/bin\n\n> Signed-off-by: Carlo Marcelo Arenas Belón \n> ---\n> detect-compiler | 2 +-\n> 1 file changed, 1 insertion(+), 1 deletion(-)\n>\n> diff --git a/detect-compiler b/detect-compiler\n> index 70b754481c..c85be83c64 100755\n> --- a/detect-compiler\n> +++ b/detect-compiler\n> @@ -44,7 +44,7 @@ clang)\n> \"FreeBSD clang\")\n> \tprint_flags clang\n> \t;;\n> -\"Apple LLVM\")\n> +\"Apple LLVM\"|\"Apple clang\")\n> \tprint_flags clang\n> \t;;\n> *)\n\nSo maybe we could add another case for \"Homebrew clang\"?\n\n---\nAtharva Raykar\nಅಥರ್ವ ರಾಯ್ಕರ್\nअथर्व रायकर\n"},{"id":"432184","messageId":"CAPig+cQBD5HbjoU=rMi=capLS_KFojYAY_OroeBCW3KRsUqamg@mail.gmail.com","threadId":"56225","inReplyTo":"CAPUEspgV3KoUOo=EDss+PTdHO6+Cp=ODDjYm7WRm8F0HHgJ08w@mail.gmail.com","subject":"Re: [PATCH] makefile: update detect-compiler for newer Xcode version","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2021-08-06T16:37:06Z","receivedAt":"2021-08-06T16:37:20Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Fri, Aug 6, 2021 at 9:33 AM Carlo Arenas wrote:\n> On Fri, Aug 6, 2021 at 5:00 AM Bagas Sanjaya wrote:\n> > Why not just s/Apple LLVM/Apple clang/?\n>\n> because that would break it for older versions of Xcode that reported\n> themselves as \"Apple LLVM\" and I am not even sure when the change was\n> made to even consider those versions as obsolete.\n>\n> Either way, I am sure once we figure out which versions are affected\n> and which versions macOS developers care enough for, that would be the\n> obvious next step.\n\nMy daily development machine still reports \"Apple LLVM\", so it would\nindeed be premature to `s/Apple LLVM/Apple clang/`. Moreover, there's\nsimply no good reason to `s/Apple LLVM/Apple clang/` since it's not a\nmaintenance burden to leave \"Apple LLVM\" in the match pattern.\n"},{"id":"432193","messageId":"xmqq8s1eigto.fsf@gitster.g","threadId":"56225","inReplyTo":"m2sfzmu1t7.fsf@gmail.com","subject":"Re: [PATCH] makefile: update detect-compiler for newer Xcode version","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-08-06T18:11:31Z","receivedAt":"2021-08-06T18:11:35Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Atharva Raykar writes:\n\n> Carlo Marcelo Arenas Belón writes:\n>\n> For those of us using Homebrew and using the LLVM installation from\n> there, we get:\n>\n> $ cc --version\n> Homebrew clang version 12.0.1\n> ...\n>> diff --git a/detect-compiler b/detect-compiler\n>> index 70b754481c..c85be83c64 100755\n>> --- a/detect-compiler\n>> +++ b/detect-compiler\n>> @@ -44,7 +44,7 @@ clang)\n>> \"FreeBSD clang\")\n>> \tprint_flags clang\n>> \t;;\n>> -\"Apple LLVM\")\n>> +\"Apple LLVM\"|\"Apple clang\")\n>> \tprint_flags clang\n>> \t;;\n>> *)\n>\n> So maybe we could add another case for \"Homebrew clang\"?\n\n$ clang --version 2>&1 | sed -ne 's/ version .*//p'\nDebian clang\n\nIt might be necessary to cope with this \"$VENDOR clang version\"\nconvention better with something like the following.\n\nI am afraid that this patch is being a bit too aggressive about\nLLVM, as I do not know if \"$VENDOR LLVM version\" is also a thing, or\nit is just oddity only at Apple, though.\n\ndiff --git c/detect-compiler w/detect-compiler\nindex 70b754481c..a80442a327 100755\n--- c/detect-compiler\n+++ w/detect-compiler\n@@ -38,13 +38,7 @@ case \"$(get_family)\" in\n gcc)\n \tprint_flags gcc\n \t;;\n-clang)\n-\tprint_flags clang\n-\t;;\n-\"FreeBSD clang\")\n-\tprint_flags clang\n-\t;;\n-\"Apple LLVM\")\n+clang | *\" clang\" | *\" LLVM\")\n \tprint_flags clang\n \t;;\n *)\n"},{"id":"432200","messageId":"YQ2LdvwEnZN9LUQn@coredump.intra.peff.net","threadId":"56225","inReplyTo":"xmqq8s1eigto.fsf@gitster.g","subject":"Re: [PATCH] makefile: update detect-compiler for newer Xcode version","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2021-08-06T19:20:22Z","receivedAt":"2021-08-06T19:20:25Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Aug 06, 2021 at 11:11:31AM -0700, Junio C Hamano wrote:\n\n> > So maybe we could add another case for \"Homebrew clang\"?\n> \n> $ clang --version 2>&1 | sed -ne 's/ version .*//p'\n> Debian clang\n> \n> It might be necessary to cope with this \"$VENDOR clang version\"\n> convention better with something like the following.\n\nGood catch. Unfortunately your patch below isn't sufficient because\nget_family() is broken, too. :(\n\nIt insists on there being an extra word after the actual version. There\nis for gcc, but not for clang on my system:\n\n $ CC=gcc get_version_line\n gcc version 10.2.1 20210110 (Debian 10.2.1-6)\n\n $ CC=clang get_version_line\n Debian clang version 11.0.1-2\n\nDoing this on top of your patch makes \"./detect-compiler clang\" behave\nas expected:\n\ndiff --git a/detect-compiler b/detect-compiler\nindex a80442a327..fd388ae783 100755\n--- a/detect-compiler\n+++ b/detect-compiler\n@@ -13,11 +13,11 @@ get_version_line() {\n }\n \n get_family() {\n-\tget_version_line | sed 's/^\\(.*\\) version [0-9][^ ]* .*/\\1/'\n+\tget_version_line | sed 's/^\\(.*\\) version [0-9].*/\\1/'\n }\n \n get_version() {\n-\tget_version_line | sed 's/^.* version \\([0-9][^ ]*\\) .*/\\1/'\n+\tget_version_line | sed 's/^.* version \\([0-9][^ ]*\\).*/\\1/'\n }\n \n print_flags() {\n\n> I am afraid that this patch is being a bit too aggressive about\n> LLVM, as I do not know if \"$VENDOR LLVM version\" is also a thing, or\n> it is just oddity only at Apple, though.\n\nI think even before this issue, all of the versioning of Apple's clang\nis suspect. The \"Apple LLVM\" bit comes from Eric in:\n\n https://lore.kernel.org/git/20180318090607.GA26226@flurp.local/\n\nBut downthread we realized that the version numbers there don't match\nthe clang ones:\n\n https://lore.kernel.org/git/CAPig+cRQXQ_DowS2Dsc1x3TAGJjnWig7P4eYS4kQ+C2piAdSWA@mail.gmail.com/\n\nDuy indicated in the cover letter:\n\n https://lore.kernel.org/git/20180324125348.6614-1-pclouds@gmail.com/\n\nthat the apple support was probably wrong, but it looks like nobody\nstepped up in the meantime to fix it. In practice I think it mostly\nworks anyway because \"clang4\" is the only version check we have for\nclang. So if we err \"ahead\" a few versions (which is what Apple's\nscheme does), you only get bit if you have a pretty old version of\nXcode.\n\nI think if we wanted to get it right, we'd need to encode into the\nscript some form of the version table here:\n\n https://en.wikipedia.org/wiki/Xcode#Xcode_11.x_-_13.x_%28since_SwiftUI_framework%29\n\n-Peff\n"},{"id":"432207","messageId":"20210806205235.988761-1-gitster@pobox.com","threadId":"56225","inReplyTo":"YQ2LdvwEnZN9LUQn@coredump.intra.peff.net","subject":"[PATCH v2 0/3] detect-compiler: clang updates","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-08-06T20:52:32Z","receivedAt":"2021-08-06T20:52:42Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"So here is a mini-series that summarizes what has been suggested so\nfar on the topic.\n\nCarlo Marcelo Arenas Belón (1):\n build: update detect-compiler for newer Xcode version\n\nJeff King (1):\n build: clang version may not be followed by extra words\n\nJunio C Hamano (1):\n build: catch clang that identifies itself as \"$VENDOR clang\"\n\n detect-compiler | 9 +++------\n 1 file changed, 3 insertions(+), 6 deletions(-)\n\n-- \n2.33.0-rc1-159-gdd7297d7fa\n\n"},{"id":"432208","messageId":"20210806205235.988761-2-gitster@pobox.com","threadId":"56225","inReplyTo":"20210806205235.988761-1-gitster@pobox.com","subject":"[PATCH v2 1/3] build: update detect-compiler for newer Xcode version","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-08-06T20:52:33Z","receivedAt":"2021-08-06T20:52:45Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"From: Carlo Marcelo Arenas Belón \n\n1da1580e4c (Makefile: detect compiler and enable more warnings in\nDEVELOPER=1, 2018-04-14) uses the output of the compiler banner to\ndetect the compiler family.\n\nApple had since changed the wording used to refer to its compiler\nas clang instead of LLVM as shown by:\n\n $ cc --version\n Apple clang version 12.0.5 (clang-1205.0.22.9)\n Target: x86_64-apple-darwin20.6.0\n Thread model: posix\n InstalledDir: /Library/Developer/CommandLineTools/usr/bin\n\nso update the script to match, and allow DEVELOPER=1 to work as\nexpected again in macOS.\n\nSigned-off-by: Carlo Marcelo Arenas Belón \nSigned-off-by: Junio C Hamano \n---\n detect-compiler | 2 +-\n 1 file changed, 1 insertion(+), 1 deletion(-)\n\ndiff --git a/detect-compiler b/detect-compiler\nindex 70b754481c..c85be83c64 100755\n--- a/detect-compiler\n+++ b/detect-compiler\n@@ -44,7 +44,7 @@ clang)\n \"FreeBSD clang\")\n \tprint_flags clang\n \t;;\n-\"Apple LLVM\")\n+\"Apple LLVM\"|\"Apple clang\")\n \tprint_flags clang\n \t;;\n *)\n-- \n2.33.0-rc1-159-gdd7297d7fa\n\n"},{"id":"432209","messageId":"20210806205235.988761-3-gitster@pobox.com","threadId":"56225","inReplyTo":"20210806205235.988761-1-gitster@pobox.com","subject":"[PATCH v2 2/3] build: clang version may not be followed by extra words","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-08-06T20:52:34Z","receivedAt":"2021-08-06T20:52:48Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"From: Jeff King \n\nThe get_family and get_version helpers of detect-compiler assume\nthat the line to identify the version from the compilers have a\ntoken \"version\", followed by the version number, followed by some\nother string, e.g.\n\n $ CC=gcc get_version_line\n gcc version 10.2.1 20210110 (Debian 10.2.1-6)\n\nBut that is not necessarily true, e.g.\n\n $ CC=clang get_version_line\n Debian clang version 11.0.1-2\n\nTweak the script not to require extra string after the version.\n\nSigned-off-by: Junio C Hamano \n---\n detect-compiler | 4 ++--\n 1 file changed, 2 insertions(+), 2 deletions(-)\n\ndiff --git a/detect-compiler b/detect-compiler\nindex c85be83c64..955be1c906 100755\n--- a/detect-compiler\n+++ b/detect-compiler\n@@ -13,11 +13,11 @@ get_version_line() {\n }\n \n get_family() {\n-\tget_version_line | sed 's/^\\(.*\\) version [0-9][^ ]* .*/\\1/'\n+\tget_version_line | sed 's/^\\(.*\\) version [0-9].*/\\1/'\n }\n \n get_version() {\n-\tget_version_line | sed 's/^.* version \\([0-9][^ ]*\\) .*/\\1/'\n+\tget_version_line | sed 's/^.* version \\([0-9][^ ]*\\).*/\\1/'\n }\n \n print_flags() {\n-- \n2.33.0-rc1-159-gdd7297d7fa\n\n"},{"id":"432210","messageId":"20210806205235.988761-4-gitster@pobox.com","threadId":"56225","inReplyTo":"20210806205235.988761-1-gitster@pobox.com","subject":"[PATCH v2 3/3] build: catch clang that identifies itself as \"$VENDOR clang\"","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-08-06T20:52:35Z","receivedAt":"2021-08-06T20:52:50Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"The case statement in detect-compiler notices 'clang', 'FreeBSD\nclang' and 'Apple clang', but there are other platforms that follow\nthe '$VENDOR clang' pattern (e.g. Debian).\n\nGeneralize the pattern to catch them.\n\nSigned-off-by: Junio C Hamano \n---\n detect-compiler | 7 ++-----\n 1 file changed, 2 insertions(+), 5 deletions(-)\n\ndiff --git a/detect-compiler b/detect-compiler\nindex 955be1c906..11d60da5b7 100755\n--- a/detect-compiler\n+++ b/detect-compiler\n@@ -38,13 +38,10 @@ case \"$(get_family)\" in\n gcc)\n \tprint_flags gcc\n \t;;\n-clang)\n+clang | *\" clang\")\n \tprint_flags clang\n \t;;\n-\"FreeBSD clang\")\n-\tprint_flags clang\n-\t;;\n-\"Apple LLVM\"|\"Apple clang\")\n+\"Apple LLVM\")\n \tprint_flags clang\n \t;;\n *)\n-- \n2.33.0-rc1-159-gdd7297d7fa\n\n"},{"id":"432220","messageId":"87bl6aypke.fsf@evledraar.gmail.com","threadId":"56225","inReplyTo":"20210806205235.988761-1-gitster@pobox.com","subject":"Re: [PATCH v2 0/3] detect-compiler: clang updates","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2021-08-07T02:02:45Z","receivedAt":"2021-08-07T02:08:22Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Fri, Aug 06 2021, Junio C Hamano wrote:\n\n> So here is a mini-series that summarizes what has been suggested so\n> far on the topic.\n>\n> Carlo Marcelo Arenas Belón (1):\n> build: update detect-compiler for newer Xcode version\n>\n> Jeff King (1):\n> build: clang version may not be followed by extra words\n>\n> Junio C Hamano (1):\n> build: catch clang that identifies itself as \"$VENDOR clang\"\n>\n> detect-compiler | 9 +++------\n> 1 file changed, 3 insertions(+), 6 deletions(-)\n\nPerhaps I've missed some obvious reason not to do this, but why are we\nparsing the --version output of two modern compilers, as opposed to just\nasking them what type/version they are via their usual macro facilities?\nI.e. something like the below:\n\ndiff --git a/detect-compiler b/detect-compiler\nindex 70b754481c8..37908ac9ea8 100755\n--- a/detect-compiler\n+++ b/detect-compiler\n@@ -5,19 +5,47 @@\n \n CC=\"$*\"\n \n-# we get something like (this is at least true for gcc and clang)\n+#!/bin/sh\n #\n-# FreeBSD clang version 3.4.1 (tags/RELEASE...)\n-get_version_line() {\n-\t$CC -v 2>&1 | grep ' version '\n-}\n+# Probe the compiler for vintage, version, etc. This is used for setting\n+# optional make knobs under the DEVELOPER knob.\n+\n+CC=\"$*\"\n+\n+v=$($CC -E - <<-EOF 2>&1 | grep -e '=')\n+GNUC=__GNUC__\n+GNUC_MINOR=__GNUC_MINOR__\n+GNUC_PATCHLEVEL=__GNUC_PATCHLEVEL__\n+clang=__clang__\n+clang_major=__clang_major__\n+clang_minor=__clang_minor__\n+clang_patchlevel=__clang_patchlevel__\n+EOF\n+eval \"$v\"\n \n get_family() {\n-\tget_version_line | sed 's/^\\(.*\\) version [0-9][^ ]* .*/\\1/'\n+\t# Clang also sets the GNUC macros, but GCC does not set\n+\t# clang's.\n+\tif test \"$clang\" != \"__clang__\"\n+\tthen\n+\t\techo clang\n+\telif test \"$GNUC\" != \"__GNUC__\"\n+\tthen\n+\t\techo gcc\n+\telse\n+\t\techo unknown\n+\tfi\n }\n \n get_version() {\n-\tget_version_line | sed 's/^.* version \\([0-9][^ ]*\\) .*/\\1/'\n+\tcase \"$(get_family)\" in\n+\tclang)\n+\t\techo \"$clang_major.$clang_minor.$clang_patchlevel\"\n+\t\t;;\n+\tgcc)\n+\t\techo \"$GNUC.$GNUC_MINOR.$GNUC_PATCHLEVEL\"\n+\t\t;;\n+\tesac\n }\n \n print_flags() {\n@@ -41,12 +69,6 @@ gcc)\n clang)\n \tprint_flags clang\n \t;;\n-\"FreeBSD clang\")\n-\tprint_flags clang\n-\t;;\n-\"Apple LLVM\")\n-\tprint_flags clang\n-\t;;\n *)\n \t: unknown compiler family\n \t;;\n"},{"id":"432221","messageId":"YQ3raB5ZtPHBQWSQ@coredump.intra.peff.net","threadId":"56225","inReplyTo":"20210806205235.988761-4-gitster@pobox.com","subject":"Re: [PATCH v2 3/3] build: catch clang that identifies itself as \"$VENDOR clang\"","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2021-08-07T02:09:44Z","receivedAt":"2021-08-07T02:09:47Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Aug 06, 2021 at 01:52:35PM -0700, Junio C Hamano wrote:\n\n> diff --git a/detect-compiler b/detect-compiler\n> index 955be1c906..11d60da5b7 100755\n> --- a/detect-compiler\n> +++ b/detect-compiler\n> @@ -38,13 +38,10 @@ case \"$(get_family)\" in\n> gcc)\n> \tprint_flags gcc\n> \t;;\n> -clang)\n> +clang | *\" clang\")\n> \tprint_flags clang\n> \t;;\n> -\"FreeBSD clang\")\n> -\tprint_flags clang\n> -\t;;\n> -\"Apple LLVM\"|\"Apple clang\")\n> +\"Apple LLVM\")\n> \tprint_flags clang\n> \t;;\n\nAll three patches look fine to me, and functionality-wise are a strict\nimprovement over the status quo. But I suspect in the long run we'd need\nto keep all of the Apple bits in their own case-arm, like:\n\n # this must come first, so we prefer it over \"* clang\".\n \"Apple LLVM\" | \"Apple clang\")\n\tprint_apple_magic\n ;;\n clang | *\" clang\")\n print_flags clang\n ;;\n\nand then apple_magic does the version conversion from Wikipedia I linked\nto earlier.\n\nI don't think your patch is really making it significantly harder to get\nthere, though splitting up \"Apple LLVM\" and \"Apple clang\" feels a bit\nlike it's the wrong direction.\n\nI wasn't personally planning to take that next step, as I lack the\nplatform to test it on. And as noted, unless you have a pretty old\nversion of Xcode, it doesn't matter either way (so I'm content to leave\nit until dev with a mac is bitten by it and cares enough to make it more\naccurate).\n\n-Peff\n"},{"id":"432222","messageId":"YQ3suvJfspzRNPL9@coredump.intra.peff.net","threadId":"56225","inReplyTo":"87bl6aypke.fsf@evledraar.gmail.com","subject":"Re: [PATCH v2 0/3] detect-compiler: clang updates","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2021-08-07T02:15:22Z","receivedAt":"2021-08-07T02:15:25Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Aug 07, 2021 at 04:02:45AM +0200, Ævar Arnfjörð Bjarmason wrote:\n\n> Perhaps I've missed some obvious reason not to do this, but why are we\n> parsing the --version output of two modern compilers, as opposed to just\n> asking them what type/version they are via their usual macro facilities?\n> I.e. something like the below:\n\nThat would probably work OK in practice, but it actually seems more\ncomplex to me (how do other random compilers react to \"-E -\"? Is it\npossible for us to get other output from the preprocessor that would\nconfuse an eval?).\n\nIt could perhaps make the Apple version-string confusion go away,\nthough, which might make it worth doing.\n\n-Peff\n"},{"id":"432224","messageId":"875ywiyn4y.fsf@evledraar.gmail.com","threadId":"56225","inReplyTo":"YQ3suvJfspzRNPL9@coredump.intra.peff.net","subject":"Re: [PATCH v2 0/3] detect-compiler: clang updates","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2021-08-07T02:56:04Z","receivedAt":"2021-08-07T03:00:50Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Fri, Aug 06 2021, Jeff King wrote:\n\n> On Sat, Aug 07, 2021 at 04:02:45AM +0200, Ævar Arnfjörð Bjarmason wrote:\n>\n>> Perhaps I've missed some obvious reason not to do this, but why are we\n>> parsing the --version output of two modern compilers, as opposed to just\n>> asking them what type/version they are via their usual macro facilities?\n>> I.e. something like the below:\n>\n> That would probably work OK in practice, but it actually seems more\n> complex to me (how do other random compilers react to \"-E -\"?\n\nWe only care about gcc and clang in that script, which I think have\nsupported that form of \"-E\" on stdin input for any version we're likely\nto care about for the purposes of config.mak.dev. It seems unlikely that\nwe'll care about non-modern compilers in config.mak.dev, so using more\nmodern features there seems fine (it's all for opting us into even more\nmodern warning flags and the like...).\n\n> Is it possible for us to get other output from the preprocessor that\n> would confuse an eval?).\n\nProbably, I just meant that as a POC. We could pipe it into some\nawk/grep/cut/perl or whatever that would be more strict.\n"},{"id":"432245","messageId":"YQ6VJW0AwkouDnDe@coredump.intra.peff.net","threadId":"56225","inReplyTo":"875ywiyn4y.fsf@evledraar.gmail.com","subject":"Re: [PATCH v2 0/3] detect-compiler: clang updates","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2021-08-07T14:13:57Z","receivedAt":"2021-08-07T14:14:01Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Aug 07, 2021 at 04:56:04AM +0200, Ævar Arnfjörð Bjarmason wrote:\n\n> > On Sat, Aug 07, 2021 at 04:02:45AM +0200, Ævar Arnfjörð Bjarmason wrote:\n> >\n> >> Perhaps I've missed some obvious reason not to do this, but why are we\n> >> parsing the --version output of two modern compilers, as opposed to just\n> >> asking them what type/version they are via their usual macro facilities?\n> >> I.e. something like the below:\n> >\n> > That would probably work OK in practice, but it actually seems more\n> > complex to me (how do other random compilers react to \"-E -\"?\n> \n> We only care about gcc and clang in that script, which I think have\n> supported that form of \"-E\" on stdin input for any version we're likely\n> to care about for the purposes of config.mak.dev. It seems unlikely that\n> we'll care about non-modern compilers in config.mak.dev, so using more\n> modern features there seems fine (it's all for opting us into even more\n> modern warning flags and the like...).\n\nYeah, but we don't find out what we have until we run the script in\nquestion. I guess it is OK as long as we redirect stderr, ignore the\nexit code, and only look for a positive outcome in the output (your\npatch does the latter two already).\n\nI also wondered how this might interact with CC=\"ccache gcc\" (where\ncaching might fail to notice version changes). But from some quick\ntesting, it looks like it doesn't cache in this case (neither stdin, nor\nwith -E).\n\n> > Is it possible for us to get other output from the preprocessor that\n> > would confuse an eval?).\n> \n> Probably, I just meant that as a POC. We could pipe it into some\n> awk/grep/cut/perl or whatever that would be more strict.\n\nThat would probably be better. I would be curious to hear from somebody\nwith a mac if this technique gives more sensible version numbers for the\nApple-clang compiler.\n\n-Peff\n"},{"id":"432246","messageId":"8735rlz5r2.fsf@evledraar.gmail.com","threadId":"56225","inReplyTo":"YQ6VJW0AwkouDnDe@coredump.intra.peff.net","subject":"Re: [PATCH v2 0/3] detect-compiler: clang updates","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2021-08-07T14:26:33Z","receivedAt":"2021-08-07T14:31:05Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Sat, Aug 07 2021, Jeff King wrote:\n\n> On Sat, Aug 07, 2021 at 04:56:04AM +0200, Ævar Arnfjörð Bjarmason wrote:\n>\n>> > On Sat, Aug 07, 2021 at 04:02:45AM +0200, Ævar Arnfjörð Bjarmason wrote:\n>> >\n>> >> Perhaps I've missed some obvious reason not to do this, but why are we\n>> >> parsing the --version output of two modern compilers, as opposed to just\n>> >> asking them what type/version they are via their usual macro facilities?\n>> >> I.e. something like the below:\n>> >\n>> > That would probably work OK in practice, but it actually seems more\n>> > complex to me (how do other random compilers react to \"-E -\"?\n>> \n>> We only care about gcc and clang in that script, which I think have\n>> supported that form of \"-E\" on stdin input for any version we're likely\n>> to care about for the purposes of config.mak.dev. It seems unlikely that\n>> we'll care about non-modern compilers in config.mak.dev, so using more\n>> modern features there seems fine (it's all for opting us into even more\n>> modern warning flags and the like...).\n>\n> Yeah, but we don't find out what we have until we run the script in\n> question. I guess it is OK as long as we redirect stderr, ignore the\n> exit code, and only look for a positive outcome in the output (your\n> patch does the latter two already).\n>\n> I also wondered how this might interact with CC=\"ccache gcc\" (where\n> caching might fail to notice version changes). But from some quick\n> testing, it looks like it doesn't cache in this case (neither stdin, nor\n> with -E).\n>\n>> > Is it possible for us to get other output from the preprocessor that\n>> > would confuse an eval?).\n>> \n>> Probably, I just meant that as a POC. We could pipe it into some\n>> awk/grep/cut/perl or whatever that would be more strict.\n>\n> That would probably be better. I would be curious to hear from somebody\n> with a mac if this technique gives more sensible version numbers for the\n> Apple-clang compiler.\n\nIt does, on the gcc304 box on the gccfarm (recent apple M1 Mac Mini):\n\n avar@minimac ~ % uname -a\n Darwin minimac.moose.housegordon.com 20.4.0 Darwin Kernel Version 20.4.0: Thu Apr 22 21:46:41 PDT 2021; root:xnu-7195.101.2~1/RELEASE_ARM64_T8101 arm64 \n avar@minimac ~ % clang --version\n Apple clang version 12.0.5 (clang-1205.0.22.9)\n Target: arm64-apple-darwin20.4.0\n Thread model: posix\n InstalledDir: /Library/Developer/CommandLineTools/usr/bin\n\n avar@minimac ~ % cat >f \n GNUC=__GNUC__\n GNUC_MINOR=__GNUC_MINOR__\n GNUC_PATCHLEVEL=__GNUC_PATCHLEVEL__\n clang=__clang__\n clang_major=__clang_major__\n clang_minor=__clang_minor__\n clang_patchlevel=__clang_patchlevel__\n \n ^C\n\n avar@minimac ~ % clang -E - \"\n # 1 \"\" 1\n # 1 \"\" 3\n # 384 \"\" 3\n # 1 \"\" 1\n # 1 \"\" 2\n # 1 \"\" 2\n GNUC=4\n GNUC_MINOR=2\n GNUC_PATCHLEVEL=1\n clang=1\n clang_major=12\n clang_minor=0\n clang_patchlevel=5\n\nI think nobody who's using clang derivatives is screwing with these\nmacro variables, they're just changing whatever the \"product name\" or\nwhatever is in the --version output.\n"},{"id":"432247","messageId":"YQ6bTm6DxeJLhmeA@coredump.intra.peff.net","threadId":"56225","inReplyTo":"8735rlz5r2.fsf@evledraar.gmail.com","subject":"Re: [PATCH v2 0/3] detect-compiler: clang updates","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2021-08-07T14:40:14Z","receivedAt":"2021-08-07T14:40:19Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Aug 07, 2021 at 04:26:33PM +0200, Ævar Arnfjörð Bjarmason wrote:\n\n> > That would probably be better. I would be curious to hear from somebody\n> > with a mac if this technique gives more sensible version numbers for the\n> > Apple-clang compiler.\n> \n> It does, on the gcc304 box on the gccfarm (recent apple M1 Mac Mini):\n> \n> avar@minimac ~ % uname -a\n> Darwin minimac.moose.housegordon.com 20.4.0 Darwin Kernel Version 20.4.0: Thu Apr 22 21:46:41 PDT 2021; root:xnu-7195.101.2~1/RELEASE_ARM64_T8101 arm64 \n> avar@minimac ~ % clang --version\n> Apple clang version 12.0.5 (clang-1205.0.22.9)\n> Target: arm64-apple-darwin20.4.0\n> Thread model: posix\n> InstalledDir: /Library/Developer/CommandLineTools/usr/bin\n> \n> avar@minimac ~ % cat >f \n> GNUC=__GNUC__\n> GNUC_MINOR=__GNUC_MINOR__\n> GNUC_PATCHLEVEL=__GNUC_PATCHLEVEL__\n> clang=__clang__\n> clang_major=__clang_major__\n> clang_minor=__clang_minor__\n> clang_patchlevel=__clang_patchlevel__\n> \n> ^C\n> \n> avar@minimac ~ % clang -E - # 1 \"\"\n> # 1 \"\" 1\n> # 1 \"\" 3\n> # 384 \"\" 3\n> # 1 \"\" 1\n> # 1 \"\" 2\n> # 1 \"\" 2\n> GNUC=4\n> GNUC_MINOR=2\n> GNUC_PATCHLEVEL=1\n> clang=1\n> clang_major=12\n> clang_minor=0\n> clang_patchlevel=5\n\nHmm, now I'm really confused, though. Is that really clang 12 (for which\nthere is no 12.0.5; 12.0.1 is the latest version, shipped in July)? Or\nis it XCode 12, shipping with LLVM 11, according to the table in:\n\n https://en.wikipedia.org/wiki/Xcode#Xcode_11.x_-_13.x_(since_SwiftUI_framework)\n\n(sorry, there are actually _two_ tables with that same anchor on the\npage; the one you want is the second one, under \"Toolchain versions\").\n\nThe distinction does not matter for our script (where we only care about\n\"clang4\" and up). I guess the most relevant test would be to get XCode\n8.x and see what it says. I expect it to claim \"clang 8.1.0\" or similar,\nbut actually be clang-3. And therefore not support\n-Wtautological-constant-out-of-range-compare.\n\nIf we can't get easily get hold of such a platform, then maybe that is a\ngood indication that this conversation is too academic for now, and we\nshould wait until somebody wants to add a more recent version-specifier\nto config.mak.dev. ;)\n\n-Peff\n"},{"id":"432248","messageId":"87zgttxo3i.fsf@evledraar.gmail.com","threadId":"56225","inReplyTo":"YQ6bTm6DxeJLhmeA@coredump.intra.peff.net","subject":"Re: [PATCH v2 0/3] detect-compiler: clang updates","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2021-08-07T15:36:57Z","receivedAt":"2021-08-07T15:37:50Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Sat, Aug 07 2021, Jeff King wrote:\n\n> On Sat, Aug 07, 2021 at 04:26:33PM +0200, Ævar Arnfjörð Bjarmason wrote:\n>\n>> > That would probably be better. I would be curious to hear from somebody\n>> > with a mac if this technique gives more sensible version numbers for the\n>> > Apple-clang compiler.\n>> \n>> It does, on the gcc304 box on the gccfarm (recent apple M1 Mac Mini):\n>> \n>> avar@minimac ~ % uname -a\n>> Darwin minimac.moose.housegordon.com 20.4.0 Darwin Kernel\n>> Version 20.4.0: Thu Apr 22 21:46:41 PDT 2021;\n>> root:xnu-7195.101.2~1/RELEASE_ARM64_T8101 arm64\n>> avar@minimac ~ % clang --version\n>> Apple clang version 12.0.5 (clang-1205.0.22.9)\n>> Target: arm64-apple-darwin20.4.0\n>> Thread model: posix\n>> InstalledDir: /Library/Developer/CommandLineTools/usr/bin\n>> \n>> avar@minimac ~ % cat >f \n>> GNUC=__GNUC__\n>> GNUC_MINOR=__GNUC_MINOR__\n>> GNUC_PATCHLEVEL=__GNUC_PATCHLEVEL__\n>> clang=__clang__\n>> clang_major=__clang_major__\n>> clang_minor=__clang_minor__\n>> clang_patchlevel=__clang_patchlevel__\n>> \n>> ^C\n>> \n>> avar@minimac ~ % clang -E - > # 1 \"\"\n>> # 1 \"\" 1\n>> # 1 \"\" 3\n>> # 384 \"\" 3\n>> # 1 \"\" 1\n>> # 1 \"\" 2\n>> # 1 \"\" 2\n>> GNUC=4\n>> GNUC_MINOR=2\n>> GNUC_PATCHLEVEL=1\n>> clang=1\n>> clang_major=12\n>> clang_minor=0\n>> clang_patchlevel=5\n>\n> Hmm, now I'm really confused, though. Is that really clang 12 (for which\n> there is no 12.0.5; 12.0.1 is the latest version, shipped in July)? Or\n> is it XCode 12, shipping with LLVM 11, according to the table in:\n>\n> https://en.wikipedia.org/wiki/Xcode#Xcode_11.x_-_13.x_(since_SwiftUI_framework)\n>\n> (sorry, there are actually _two_ tables with that same anchor on the\n> page; the one you want is the second one, under \"Toolchain versions\").\n>\n> The distinction does not matter for our script (where we only care about\n> \"clang4\" and up). I guess the most relevant test would be to get XCode\n> 8.x and see what it says. I expect it to claim \"clang 8.1.0\" or similar,\n> but actually be clang-3. And therefore not support\n> -Wtautological-constant-out-of-range-compare.\n>\n> If we can't get easily get hold of such a platform, then maybe that is a\n> good indication that this conversation is too academic for now, and we\n> should wait until somebody wants to add a more recent version-specifier\n> to config.mak.dev. ;)\n\nI think it's clang 12.0.5, and Apple just takes upstream versions and\nincrements them, e.g. I found this:\nhttps://gist.github.com/yamaya/2924292\n\nSo you can presumably rely on it for having clang 12 features, and we'd\nonly ever care about the clang_major...\n"},{"id":"432262","messageId":"CAPUEsph1ZqE9KtT7ooJEa=jURq+=cG78MXwPxahb7f0YXYHL7g@mail.gmail.com","threadId":"56225","inReplyTo":"YQ6bTm6DxeJLhmeA@coredump.intra.peff.net","subject":"Re: [PATCH v2 0/3] detect-compiler: clang updates","fromName":"Carlo Arenas","fromEmail":"carenas@gmail.com","sentAt":"2021-08-08T00:30:39Z","receivedAt":"2021-08-08T00:30:53Z","isPatch":true,"sender":{"key":"carenas@gmail.com","avatar":"https://avatars.githubusercontent.com/u/76036?v=4"},"body":"On Sat, Aug 7, 2021 at 7:40 AM Jeff King wrote:\n> The distinction does not matter for our script (where we only care about\n> \"clang4\" and up). I guess the most relevant test would be to get XCode\n> 8.x and see what it says. I expect it to claim \"clang 8.1.0\" or similar,\n> but actually be clang-3. And therefore not support\n> -Wtautological-constant-out-of-range-compare.\n\nuses Xcode 7.3 (based on clang 3.8) and either does support that flag\nor ignores it silently\n\n https://www.travis-ci.com/github/carenas/git/builds/234772346\n\nthe same was observed with Xcode 8\n\nboth error later and fail to build because of a valid (but harmless)\n-Wformat-extra-args warning that doesn't trigger in later versions\n\nCarlo\n"},{"id":"432320","messageId":"YRFvOp+3kjfYdi0q@coredump.intra.peff.net","threadId":"56225","inReplyTo":"CAPUEsph1ZqE9KtT7ooJEa=jURq+=cG78MXwPxahb7f0YXYHL7g@mail.gmail.com","subject":"Re: [PATCH v2 0/3] detect-compiler: clang updates","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2021-08-09T18:08:58Z","receivedAt":"2021-08-09T18:09:01Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Aug 07, 2021 at 05:30:39PM -0700, Carlo Arenas wrote:\n\n> On Sat, Aug 7, 2021 at 7:40 AM Jeff King wrote:\n> > The distinction does not matter for our script (where we only care about\n> > \"clang4\" and up). I guess the most relevant test would be to get XCode\n> > 8.x and see what it says. I expect it to claim \"clang 8.1.0\" or similar,\n> > but actually be clang-3. And therefore not support\n> > -Wtautological-constant-out-of-range-compare.\n> \n> uses Xcode 7.3 (based on clang 3.8) and either does support that flag\n> or ignores it silently\n> \n> https://www.travis-ci.com/github/carenas/git/builds/234772346\n> \n> the same was observed with Xcode 8\n> \n> both error later and fail to build because of a valid (but harmless)\n> -Wformat-extra-args warning that doesn't trigger in later versions\n\nThanks for testing. I think I was wrong that clang4 is the limit for\nthat option, though. It comes originally from:\n\n https://lore.kernel.org/git/20180317160832.GB15772@sigill.intra.peff.net/\n\nwhere clang4 just happened to be the oldest thing I had access to at the\ntime, so we used that as a minimum. So probably all of our \"clang4\"\ncould really be \"any clang\" (but it is probably OK to leave it as-is).\n\n-Peff\n"},{"id":"432321","messageId":"YRFvh34fzNdxLOPc@coredump.intra.peff.net","threadId":"56225","inReplyTo":"87zgttxo3i.fsf@evledraar.gmail.com","subject":"Re: [PATCH v2 0/3] detect-compiler: clang updates","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2021-08-09T18:10:15Z","receivedAt":"2021-08-09T18:10:22Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Aug 07, 2021 at 05:36:57PM +0200, Ævar Arnfjörð Bjarmason wrote:\n\n> > Hmm, now I'm really confused, though. Is that really clang 12 (for which\n> > there is no 12.0.5; 12.0.1 is the latest version, shipped in July)? Or\n> > is it XCode 12, shipping with LLVM 11, according to the table in:\n> >\n> > https://en.wikipedia.org/wiki/Xcode#Xcode_11.x_-_13.x_(since_SwiftUI_framework)\n> >\n> > (sorry, there are actually _two_ tables with that same anchor on the\n> > page; the one you want is the second one, under \"Toolchain versions\").\n> >\n> > The distinction does not matter for our script (where we only care about\n> > \"clang4\" and up). I guess the most relevant test would be to get XCode\n> > 8.x and see what it says. I expect it to claim \"clang 8.1.0\" or similar,\n> > but actually be clang-3. And therefore not support\n> > -Wtautological-constant-out-of-range-compare.\n> >\n> > If we can't get easily get hold of such a platform, then maybe that is a\n> > good indication that this conversation is too academic for now, and we\n> > should wait until somebody wants to add a more recent version-specifier\n> > to config.mak.dev. ;)\n> \n> I think it's clang 12.0.5, and Apple just takes upstream versions and\n> increments them, e.g. I found this:\n> https://gist.github.com/yamaya/2924292\n> \n> So you can presumably rely on it for having clang 12 features, and we'd\n> only ever care about the clang_major...\n\nFrom the reading I've done, I'm unconvinced that this is _actually_\nclang 12, and they aren't simply doing funky things with the version\nnumbers. But since we lack an easy test of how the different versions\nbehave (even my suggested clang4 test turned out not to be robust!), it\nprobably doesn't matter much either way.\n\n-Peff\n"}]}