Open agocke opened 2 years ago
We should go the rewrite route.
Interesting problem with that is that we might need to introduce tokens for things that didn't exist in the source assembly (e.g. apps don't normally refer to System.Private.CoreLib).
I think we will want to split off TokenBasedBasedNode into a base class that doesn't have a source token - i.e. we will have a base type that participates in writing (it has WriteInternal and BuildTokens), but doesn't have a metadata handle in the source assembly. We would need to figure out how to sort those. It should be easy enough for AssemblyRefs because we just sort alphabetically. These new tokens will show up differently in the tokenmap also. I don't have super clear design for it in my head yet. Maybe tokenmap doesn't even need to remember their exact token values; the node can remember it.
If we want to support "Copy" assemblies, then we also have to deal with type forwarders. This doesn't prevent rewriting typerefs, it just means that typerefs in copy assemblies can't be rewritten and thus we need to be able to preserve the type forwarders they may point to.
Just want to understand this a bit more:
So what if we:
Makes sense?
Yes, that could work. The "somehow sorted and assigned tokens" could be maybe done naturally, by:
Looks like we're not marking type forwards, and also not rewriting the typerefs. One of those has to change