Improve the codegen of type symbols for debugging

[jabraham17]

Improves the codegen of chapel type symbols, especially for debugging.

Key Improvements

• Adds special debug types for bools and enums
• Heavily refactors llvmDebug.cpp to make way for future improvements
• makes codegen of enums for LLVM and C use the same logic
  • this means the C backend no longer relies on the behavior of C enums, a value is always given

This PR also makes a few improvements to sub_test

Makes progress on #27603

• paratest with/without gasnet

Future work

• get the original array motivating case working (resolving the TODO added in this PR about forward decls)
• improve the pretty printers to work with the fixed llvm types
• make the compile unit for types be correct, right now they get put in whatever compile unit is codegened first
• figure out whats going on with the garbage values in this test case. lldb seems to think x and y are garbage, but only if R has no other fields and an explicit init

  class A {
    var x: int;
    var y: real;
  }
  
  record R {
    var a: unmanaged A;
    proc init() {
      this.a = new unmanaged A();
    }
  }
  
  proc main() {
    var cc = new R();
    writeln("cc: ", cc);
    use Debugger; breakpoint;
  }
  

[Reviewed by @DanilaFe ]

[DanilaFe]

Looks good, though I didn't study the details of the seds in the test files, or sanity-check the dwarfdump output.

[DanilaFe]

Double-checking: this changes our generated C code, but you're saying it's acceptable because, even supposing an enum like:

// (Chapel)
enum { a, b = 12, c, d = 5 }

Other transformations convert the above into:

// (Chapel)
enum { a, b = 12, c = 13, d = 5 }

Which was equivalent to the generated C code:

// C++
enum { a, b = 12, c = 13, d = 5 }

Here, C will start number at zero by default, so the new form

enum { a = 0, b = 12, c = 13, d = 5 }

Retains the original behavior?

[jabraham17]

Yes. Put another way: I took the logic we had for generating enums with LLVM (which emulates what the C backend does) and used it for both LLVM and C

[jabraham17]

And if it helps, we have tests like test/types/enum/enumCast.chpl which lock in the integer value based on C semantics, and they still pass with this change

[DanilaFe]

Why remove the FIXME?

[jabraham17]

Because now I have added the INT_FATAL if they are missing. Its an internal error instead of just a comment in the code. Which means if a user hits this in the field (unlikely, if both fts->getLLVMType(); and getTypeLLVM(fts->cname) fail, there are probably other issues beyond debug info), they get an internal error and report it, and we fix it

[jabraham17]

And while debugging, I have yet to actually hit this branch

[DanilaFe]

are my eyes playing tricks on me, or was this all the same code?

[jabraham17]

This was pretty much all the same code. There are some very very subtle differences that I preserved as best I can. Basically the differences stemmed from "pointer to class" vs "class"

[DanilaFe]

Why not skipif these instead of suppressing?

[jabraham17]

Because ideally, one day they work. These are copied from the existing targetVar.suppressif

[bradcray]

With a quick glance at the OP, this feels more like a feature freeze item than a code freeze item…?

[jabraham17]

This was discussed last week in the release round table as a code freeze item. Perhaps it wasn't fully clear the extent of the changes