Get rid of the vendor suffix patch for clang.

[dim]

Summary

Get rid of the vendor suffix patch for clang, since it is very unlikely
that anyone has ever used the suffix (which was mostly the approximate
datetime stamp of the import from the vendor area). This changes the
first line of "clang -v" output (in -current) from:

FreeBSD clang version 3.7.0 (tags/RELEASE_370/final 246257) 20150906

to:

FreeBSD clang version 3.7.0 (tags/RELEASE_370/final 246257) (based on LLVM 3.7.0)

Test Plan

There no functional change, this is purely cosmetic.

[emaste]

This is fine with me. It's very useful for us to have the FreeBSD vendor string in there to differentiate our Clang from an unmodified 3.7.0, but the extra date string probably buys us very little.

[emaste]

LGTM but allow some time for others to comment.

[emaste]

Oh, the "based on" text is only added if CLANG_VENDOR is set - I didn't pay attention to that at first. It seems odd in this case that we report Clang 3.7.0 based on LLVM 3.7.0. Of course it is.

We do want to indicate that our build may be modified from stock upstream Clang (with backported patches etc.), but I'm not sure that the "based on" text adds anything useful.

[dim]

In D3909#81373, @emaste wrote:

Oh, the "based on" text is only added if CLANG_VENDOR is set - I didn't pay attention to that at first. It seems odd in this case that we report Clang 3.7.0 based on LLVM 3.7.0. Of course it is.

We do want to indicate that our build may be modified from stock upstream Clang (with backported patches etc.), but I'm not sure that the "based on" text adds anything useful.

No, in my opinion it doesn't add anything, but this is just how the stock upstream code looks. If we want to change that to something else, maybe we should suggest it upstream?

In any case, the "FreeBSD Clang" already indicates that it is 'our' build. We can also #define the BACKEND_PACKAGE_STRING in clang's config.h to something different, but it will always be printed in the form:

(based on %s)

[emaste]

If we want to change that to something else, maybe we should suggest it upstream?

Yeah, I think we should try to get whatever support we want upstream.

[dim]

This was already done in the clang380-import branch, which will land in head soon.