Check for C11 atomics in and around VisitQualType

[chrysn]

This does not help towards the support of C11 atomics, but ensures that
the existing error messages about the trouble with them get shown:

• In VisitQualType at latest, where the source location information is
  already gone so it's not that helpful (but at least it should catch a
  wide range of sources where those types could come from)

• In VisitTypedefNameDecl, where the typedef _Atomic(...) atomic_...;
  declarations of clang's stdatomic.h run through. It's but one of many
  possible callers, but it's the one where one more check can make the
  difference between a usable and a cryptic error for many cases.

  (And there's no point in cluttering everything with checks as we're soon gonna have atomic support anyway, aren't we? ;-) )

Closes: #293

---

Testing procedure: Run the minimal example of the closed issue. Instead of the long errors, there's now a concise:

In file included from test.c:1:
/usr/lib/llvm-10/bin/../lib/clang/10.0.1/include/stdatomic.h:76:37: error: c2rust: C11 Atomics are not supported. Aborting.
typedef _Atomic(_Bool)              atomic_bool;
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^

If it weren't for the front-end check in VisitTypedefNameDecl (and removing that was how I tested the back-end check), the error would be instead:

error: c2rust: C11 Atomics are not supported. No precise location information available. Aborting.

[chrysn]

As with #291, builds pass locally:

$ ./scripts/test_translator.py ./tests
[...]
Test summary:
  unexpected failures: 0
  unexpected successes: 0
  expected failures: 3
  successes: 108

[thedataking]

nit: looks like this could be QT.isAtomicType().

[chrysn]

Nope -- gives error: ‘const class clang::QualType’ has no member named ‘isAtomicType’. (When applied only here, and also for other locations which was what I first tried as TBH the isa<AtomicType> is something I plainly copy-pasted from other locations in this C++ file).

[thedataking]

see previous comment.

[thedataking]

@chrysn thanks for this PR. I fixed the CI so if you push the minor changes I recommend, we should be able to get this tested and merged in.

[chrysn]

Force-pushed with new time stamp to trigger CI rebuild.

[chrysn]

Hm, stuck in CI again. Should I try to get it unstuck where it is, or just rebase onto master and see how things go there?

[fw-immunant]

If you have time to poke at this again, it would be nice to rebase it onto master and make sure everything is green. I've seen our CI being randomly flaky before.

[chrysn]

Rebased, and checked that the copy-pasted idioms are still around the same way at their source location.

After I've discovered that I've always been running with outdated builds (cargo run -- transpile ... isn't enough, it needs to be cargo build && cargo run because c2rust is accessing c2rust-transpile through target).

The original testing procedure is still accurate. If you want to trigger the "No precise location information" case, try C like

void x(_Atomic(char) *c) { }

I'm sure there are places in the code where this could be caught with location information, but I'd say that constructs like the above are rare anyway, and that it's good to have a fallback in case we missed any other location.

[fw-immunant]

This check needs to be moved inside the if (!QT.isNull()) { conditional below; otherwise we get an internal Clang abort doing isa<AtomicType>(QT) when QT has a null inner pointer.

[fw-immunant]

Commented inline about issue causing test failures.

[kkysen]

By the way, the issue with cargo run -- transpile not rebuilding c2rust-transpile and having to do cargo build && cargo run is really annoying and not easy to figure out what's going wrong. Let me see if I can fix that. I had no idea that was happening either.