Peter Goodman

To be more precise, I don't want to end up exactly where we are with LLVM, just with more control-flow structure. I think typedefs carry a lot of semantic value,...

I keep bringing up the lowering stuff because I know that not everything is in SourceIR; some stuff will only happen through lowering (destructors, etc.).

An addendum to this issue is that lowering to LLVM IR should also implement some kind of overridable callback mechanism that asks the user to convert a high-level name to...

I suspect this unit test would repro the issue: https://github.com/trailofbits/vast/blob/6668ec5b7ea8f2e054cbf305be23d7f8137c8aba/test/vast/Transform/HL/LowerTypes/fn-ptr-a.c#L4 The difference is that we're not using the ASTConsumer interface, and instead we're doing codegen by visiting a `TranslationUnitDecl`.

@lkorenc this is an important issue. What would help catch these types of issues sooner is if VAST would add a testing harness/mechanism that doesn't use the ASTConsumer interface, and...

An addendum is that there should also be APIs to find predecessors, e.g. to `LabelDeclOp`s (or maybe `LabelStmt`?). Ditto for cases.

> Since in high level we do not have blocks, what is the ideal returned value? Next operation to be executed? Yes, the next operation to execute would be the...

Similar mappings can be implemented, e.g. mapping `clang::Type *`s to the corresponding high level dialect types.

I just noticed that the mechanism used to resolve mangled names implements a caching layer relying on the canonical declaration. This probably obviates the performance issue.

If #464 is implemented then I will not require this feature.