Tolerate RISC-V vector types

[chrysn]

Closes: #692

Note that I have no clue how these vector types would be used -- I don't even have a processor that supports them, but their mere presence in LLVM's builtins caused the above-mentioned issue.

This follows along the paths of existing vector types, reusing the code already established for SVE. As this produces a Float16 rather than a Half builtin down the road, support for that is added by mapping to Half. That seems to be OK because, unlike C's int size mess, half is commonly understood to mean an IEEE 16-bit float.

[chrysn]

The CI failures indicate that the "|| it's one of the riscv vector types" will needs its own ifdef around it.

Before I start digging into LLVM to find the precise version to test for, is the PR in general acceptable? (there's already half a day's work in it, I'd prefer not to add more without a rough thumbs-up-or-thumbs-down.)

[kkysen]

Thanks for the PR! I think it's generally good. We added similar code in #441 to handle the SVE types, so if it follows that, it should be generally good.

[chrysn]

Now it seems to pass everything that doesn't need extra secrets.

Do you want commits neatly packed into the two it semantically is, or would you squash on merge anyway?

[thedataking]

Given the size of this chang, I think a squash merge is fine – but if you have the time to clean up the commit history, that would be nice too. I noticed you have some commented out code in there – can we get rid of that before merging?

[chrysn]

Oups, thanks for spotting that, sorry this slipped in.

Squashing...

[kkysen]

Some small changes I suggested, but generally it looks very good.

[kkysen]

Do you want commits neatly packed into the two it semantically is, or would you squash on merge anyway?

I think rebasing to 2 semantic commits would be nice, plus possibly this one (#693 (comment)) as a 3rd.

[chrysn]

Has the Darwin pipeline been updated subtly? One failed job shows

  * Closing connection 1
  /Users/runner/work/1/s/c2rust-ast-exporter/src/AstExporter.cpp:2280:52: error: no member named 'Ascii' in 'clang::StringLiteral::StringKind'
              case clang::StringLiteral::StringKind::Ascii:
                   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^
  1 error generated.

which is the symptom of #676 (indicating that the image is using LLVM 15 already).

[kkysen]

Has the Darwin pipeline been updated subtly?

#677 is not merged yet, so I don't think so. Darwin CI is solely based on azure-pipelines.yml, unlike the others which are based on Docker images and have to be updated separately from GitHub. azure-pipelines.yml does say it uses macOS-latest, so perhaps that's been updated? @thedataking, thoughts?

[chrysn]

azure-pipelines.yml does say it uses macOS-latest, so perhaps that's been updated?

Rerunning the GitHub actions on the master branch might be helpful here.

[edit: They already show that the same failed with the same error]

[kkysen]

You're right; I missed that master just started failing.

This is weird: 7e79f91 was the first to fail, starting at 11:06 pm, but then ec2c291 right after succeeded, starting at 11:12 pm.

[kkysen]

LLVM 15 was indeed used in the failing Darwin CI run. I can't tell what the successful Darwin CI run used, though, as the log on error wasn't printed, but I assume it wasn't LLVM 15. Nothing should be different between those commits, so I'm guessing it's an Azure macOS-latest issue.

@thedataking, help?

[kkysen]

I think it looks all good now. The Darwin CI failure appears to be totally separate and a coincidence.