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: https://github.com/immunant/c2rust/issues/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]

@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.

[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.