Standard approach to imitate compiler codegen?

[B1Z0N]

I need a way to visit all the compiler generated sugar, like the one when you do using-dispose, or try-catch, or interpolated-string-handler-implicit-use, or class-generation-from-record, or others.

I frequently find myself looking for something like that because we don't have direct support for that nowhere. When I'm in SyntaxWalker - plain syntax, in Symbol's - entities (although it solves the problem with records), in Operation's - more abstract stuff, and it's useful, but it's not like it copies the behavior of compiler sugar.

Maybe I don't understand something, but I feel like this useful functionality is missing, and language infra developers end up rewriting that over and over again. This includes right classes, and methods resolutions. Right ifs to fully copy the behavior of compiler frontend. And if this something changes - doing it all over again.

Metaphorically speaking, I understand that you are most interested in maintaining interfaces for the common "public", but maybe we could have some "protected" ones for tool developers too?

[CyrusNajmabadi]

There isn't an API for this. But we haven't seen a need for such an API. Why do you need it? Thanks!

[B1Z0N]

We are writing an SCA tool, and we need to track all the calls in C# between functions. So as calls to IDisposable, IEnumerator and so on are implicitly generated in using, foreach respectively, we need to generate it ourselves. Moreover, the thing as DefaultInterpolatedStringHandler, that generates in some cases when you use interpolated strings, requires a lot of code generation to be done by tool developers. I know this because I did this same thing in two SCA companies. I can provide more use cases.

I know that you guys are always busy with a lot of stuff. Do you think it's reasonable to think about this API? Because I guess it won't be backward compatible, since not all sugar is guaranteed.

[333fred]

The control flow graph api will give you a lot of the same lowering the compiler does. However, we're very leary of exposing anything further than that. It creates a lot of api surface area that would need to have compatibility maintained (even the shape of some of these nodes changes occasionally), and there's also many questions on what level consumers will actually want. After basic transformations? After lambdas are rewritten? What about async? Do you want to see sequence points? Etc, etc. Imo, these scenarios are best addressed by looking at IL with a static analysis tool, rather than C#. It is harder to map back, true, but there's no sugar at that point and not many instructions to handle.

[B1Z0N]

Something like sharplab.io uses ILSpy for decompiling back to C# without sugar, right? Then it should be sufficient.