@something is expanded as a @file even when it's a value to another argument

[glandium]

The typical example is a command line like:
clang -install_name @executable_path/foo.dylib

While that also ends up being a linkage command, and thus won't be cached anyways, sccache shouldn't even try to consider @executable_path/foo.dylib as a @file.

The current behavior results in log noise like:
DEBUG:sccache::compiler::gcc: failed to read @-file /home/worker/workspace/build/src/obj-firefox/memory/replace/logalloc/executable_path/liblogalloc.dylib: No such file or directory (os error 2)

[glandium]

Oh man, the behavior of @ is even worse than how it's described in https://github.com/mozilla/sccache/blob/master/src/compiler/gcc.rs#L381

Some examples:

$ echo a > a.c
$ echo b > b.c
$ echo c > c.c
$ echo a.c b.c > d.c
$ gcc -E -include @d # equivalent to `gcc -E include a.c b.c`, ok
# 1 "b.c"
# 1 "<built-in>"
# 1 "<command-line>"
# 31 "<command-line>"
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 32 "<command-line>" 2
# 1 "./a.c" 1
a
# 32 "<command-line>" 2
# 1 "b.c"
b
$ gcc -E -include@d # equivalent to `gcc -E -includea.c b.c`?
gcc: fatal error: no input files
compilation terminated.
$ # huh?
$ gcc -E -includea.c b.c # it *is* supposed to work
# 1 "b.c"
# 1 "<built-in>"
# 1 "<command-line>"
# 31 "<command-line>"
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 32 "<command-line>" 2
# 1 "./a.c" 1
a
# 32 "<command-line>" 2
# 1 "b.c"
b
$ gcc -E -include@d c.c # there was no input files, so let's give one
cc1: error: too many filenames given.  Type cc1 --help for usage
# 1 "b.c"
$ clang -E -include@d # what about clang?
clang: error: no input files
$ clang -E -include@d c.c # at least they agreed, what about this?
# 1 "b.c"
# 1 "<built-in>" 1
# 1 "<built-in>" 3
# 317 "<built-in>" 3
# 1 "<command line>" 1
# 1 "./a.c" 1
a
# 2 "<command line>" 2
# 1 "<built-in>" 2
# 1 "b.c" 2
b
fatal error: error in backend: IO failure on output stream.
$ # huh

In case you wonder, things like a.c or a.c -include b.c in d do work with -include@d.

Now, back to the original reason I opened this issue, it turns out that clang also does try to open the file as a list of options, so sccache is right to do that...