Only allow the Checked C extension flag for C.

[dtarditi]

This change only allows the -fcheckedc-extension flag to be used for C programs
in clang. The clang driver will reject the use of -fcheckedc-extension for
other C family languages supported by clang, including C++, Objective
C, OpenCL, and CUDA. This addresses issue #9 in the checked-clang Github repo.

We are currently not modifying clang to support these other languages, which
is why need to disallow using the extension with them.

Testing:

• Add 4 new tests to clang. They test that use of the extension flag is
  rejected for C++, Objective C, CUDA, and OpenCL.
• As recommended by the clang documentation, I placed the tests in with
  other similar tests in the test tree.
• I updated the testing baselines to reflect the new tests. I also updated
  the documentation to reflect the fact that we have Checked C specific tests
  in clang. We need to take the new tests into account when updating to new
  versions of the clang/LLVM sources.

[msftclas]

Hi @dtarditi, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!

It looks like you're a Microsoft contributor (David Tarditi). If you're full-time, we DON'T require a Contribution License Agreement. If you are a vendor, please DO sign the electronic Contribution License Agreement. It will take 2 minutes and there's no faxing! https://cla.microsoft.com.

TTYL, MSBOT;

[reubeno]

I saw your updated instructions for keeping this .md file up to date, but I just get the sense that it's going to get out-of-sync. (And if it stays in sync, I'm wondering if it's going to be unnecessary developer burden for each change that adds a new test.)

I know it's important to keep in agreement on which failures are expected (because they show up in the base line) and agree we should keep that updated--but do we need to update the counts of tests we've added? I'm not sure how much we'll get from that...

[dtarditi]

Agreed. Updating precise counts will likely become a developer burden. We only need to track 'Unexpected failures' in the baseline branch. We don't particularly need to track the counts. I'll update the md files in the pull request to reflect that.

I did have some concerns that people will add tests incorrectly and not notice they aren't running. However, this seems pretty unlikely given the way that the LLVM test infrastructure works. It will produce an error for tests that are lacking RUN lines. The only requirement during code reviews to make sure that tests will run is to make sure they are placed within test suite directories.

[reubeno]

Finished taking a pass over this; my main question is around the overhead to maintain the expected test counts for tests we add. Apart from that, this looks good. (And thanks for putting in the effort to add those test cases!)

[dtarditi]

I've updated the documentation so that we will not maintain expected passing test counts, which could add overhead. Instead we'll just make sure that there are no unexpected test failures. I addressed your other comments and updated the issue9 branch. One neat thing: we're now checking that clang-cl understands the -fcheckedc-extension flag when it is passed using the -Xclang option to clang-cl.