[clang] [Clang][RISCV] Add preprocessor macros for Zicfilp CFI scheme (PR #109600)

[Ming-Yi Lai via cfe-commits]

================
@@ -238,6 +238,25 @@ void RISCVTargetInfo::getTargetDefines(const LangOptions &Opts,
     else
       Builder.defineMacro("__riscv_32e");
   }
+
+  if (Opts.CFProtectionBranch) {
+    auto Scheme = Opts.getCFBranchLabelScheme();
+    if (Scheme == CFBranchLabelSchemeKind::Default)
+      Scheme = getDefaultCFBranchLabelScheme();
+
+    Builder.defineMacro("__riscv_landing_pad");
+    switch (Scheme) {
+    case CFBranchLabelSchemeKind::Unlabeled:
+      Builder.defineMacro("__riscv_landing_pad_unlabeled");
+      break;
+    case CFBranchLabelSchemeKind::FuncSig:
+      Builder.defineMacro("__riscv_landing_pad_func_sig");
+      break;
----------------
mylai-mtk wrote:

To drop this case I have 2 options, but I think neither is appropriate.

+ Option 1:

```c++
    case CFBranchLabelSchemeKind::FuncSig:
      // TODO: Define macros after the func-sig scheme is implemented
      break;
```

Considering we already accepted `-mcf-branch-label-scheme=func-sig`, if the user uses the flag now, he would get a success program run, but incomplete compilation result, which is also misleading, so it's better to add an error to prevent the case, which leads to Option 2.

+ Option 2:

```c++
    case CFBranchLabelSchemeKind::FuncSig:
      // TODO: Define macros after the func-sig scheme is implemented
      llvm::report_fatal_error("the func-sig scheme is not implemented yet!");
      break;
```

This prevents the misleading results, but it breaks tests in the `main` trunk, so existing tests for the func-sig scheme have to be removed, but I don't think it's worth it to undo the work just to merge this PR.

---

Perhaps we should still pause this PR? This is not really an urgent thing given the concern of misleading users.

https://github.com/llvm/llvm-project/pull/109600