Consider replacing the declaration context in GetTypeAsString
and associated methods with a proper context enum
#238
Labels
Area-OutputGeneration
Issues concerning the process of generating output from Biohazrd
Concept-ApiClarity
Issues for improving the clarity of the Biohazrd API
TechDebt
Historically we've had the declaration associated with the type being written available in the context of getting a type as a string.
This is somewhat problematic because it doesn't actually tell us what the context we're emitting to is. For instance, a temporary local being written for a
in T
parameter should be written asref readonly T
but we have no way to know that inByRefTypeReference
. Another weird case is writing the implicit parameters for functions, which are associated with the function its self since no actual parameter exists.We also actually rarely use it for context beyond debugging, it'd be better to only use it for debugging, remove it from public API locations like
ICustomCSharpTypeReference
, and replace it with anEmitContext
enum.Additionally it's actually somewhat annoying to determine in some situations. For instance, we have to do a lot of extra work in
Trampoline
for very little gain in order to figure out which parameter is indirectly associated with an adapter.The text was updated successfully, but these errors were encountered: