How to test for things that should not be accepted by the compiler

I am writing a C++ library that has many adapters. It is easy to make an automated test that adapter foo can be applied to type a, just write the code foo and check that it compiles. For extra confidence, you can even check that it works as intended ;) There are many unit test frameworks that assist in this.

But it is just as important that certain things don't compile, for instance foo should not accept type b. Is there common wisdom about testing this in an automated way? One step could be to run the compiler and verify that it returns an error status (or doesn't produce an output file). But that would require one source file per test! Some macro magic could enable the combining of tests into one source file, but it would still require many compilation runs.

I can't believe I am the first person to struggle with this problem. So, what is a good way to organize and run such tests?

(In a previous life I wrote a small compiler that had a command line option -fail 12, which caused the compiler to return an error code unless it encountered an error or line 12. Maybe I should patch GCC to accept something similar.)