Fix compiler family detection issue with clang-cl on macOS

[NobodyXu]

Fixed #1327

[NobodyXu]

I can't know for sure if the compiler is clang-cl, so can't apply the workaround reliably.

Alternatively, we could combine cfg(macos) with accept cl flags check.

if both are true then it's likely clang-cl on macOS, which needs workaroud.

[madsmtm]

It is not clear to me why we even support clang-cl on macOS and Linux? cl.exe is not something you'd run on those platforms, so why would you ever run clang-cl? (Not a blocker for fixing this, just something I'd like to understand ;) )

cfg(macos)

That's a bad idea IMO, since this problem is also present on Linux and Windows hosts, just less prominently since their root paths usually start with a lowercase letter (on Linux), or prefixed with the drive letter (on Windows), but that's not a requirement!

Actually, the -- separator seems to be supported by normal Clang too, so why don't we just do this workaround everywhere?

This would also avoid issues if the user did e.g. .file("-l").

[NobodyXu]

It is not clear to me why we even support clang-cl on macOS and Linux? cl.exe is not something you'd run on those platforms, so why would you ever run clang-cl?

Based on the original issue, I believe they are using cargo-xwin to cross compile to msvc windows from a unix environment.

Actually, the -- separator seems to be supported by normal Clang too, so why don't we just do this workaround everywhere?

Does gcc and other compiler support it?

If they mostly do, we can add -- to compiler detection.

This would also avoid issues if the user did e.g. .file("-l").

Good idea

[madsmtm]

Does gcc and other compiler support it?

$ touch foo.c
$ clang -c -- foo.c
$ gcc -c -- foo.c
gcc: error: unrecognized command-line option '--'

Doesn't seem like it?