Write out types in topological order

[adriangb]

Sub-piece of #25.

Python in particular needs this for type aliases:

TypeAlias = Foo
class Foo:  pass

Won't work although it is fine in Rust.

As discussed in #20 I think it makes sense to just make this the default for all languages, I don't think it's a con in any language.

Tricky bits:

• Cycles. Python is fine with cycles as long as it's not in type aliases. For now I just let cycles be (no error). We can either leave it like that (which would result in generated Python files with cycles in type aliases that fail to import) or try to do something fancy for the Python implementation specifically that checks if the cycle includes a type alias and gives a nice error message.
• Duplication of RustThing. I essentially duplicated RustThing from parser.rs to rust_types.rs because it made sense for topological sorting. I think this needs some cleanup / further thought.
• Handling of languages like Go that override write_types. I copy pasted logic into the Go implementation (it already has duplicate logic w.r.t mod.rs) although it is not strictly necessary for Go, just to keep things the same across languages.

[adriangb]

@inquisitivepenguin what would you think about making the RustThing in parser.rs public? Then we can add a fn toposorted() -> Vec<RustThing> method to ParsedData.

[snowsignal]

@inquisitivepenguin what would you think about making the RustThing in parser.rs public? Then we can add a fn toposorted() -> Vec<RustThing> method to ParsedData.

I'm hesitant to do so because RustThing is kind of a hack so if we changed this in the future we'd need to do a major version update because this would break backwards compatibility.

[adriangb]

That’s fair. Do you consider it a hack just as it is currently being used in parser.rs or also how I am using it here to iterate over heterogeneous “things” in a topological order?

[snowsignal]

That’s fair. Do you consider it a hack just as it is currently being used in parser.rs or also how I am using it here to iterate over heterogeneous “things” in a topological order?

It was originally introduced to accomplish a hack (so yes, the former option), in this case treating a struct as a type alias. I'm not opposed to have a heterogeneous container type, but since this is going to be a new public type, we could still make a few changes:

1. Rename it to something better (I don't really have any strong opinions on a new name)
2. Make it #[non_exhaustive] so future matching code won't break when we add new parsed data types (which const support #57 is already doing)
3. Figure out if this would work better as a trait (we'd have to downcast to get the data back, so probably not)

[snowsignal]

@adriangb Since this PR is getting kind of stale, I'm going to go ahead and implement the requested changes myself. Let me know if this is conflicting with any work you're doing.

[adriangb]

No problem at all! I've been very distracted from OSS with personal / paid job lately, sorry for dropping the ball.

[snowsignal]

@adriangb No worries at all, thank you for all of your contributions.

[LuminaSapphira]

Everything looks good, just a few nits:

• could the other functions taking mutable vecs in topsort.rs have shims like the topsort impl? It'd reduce extra lines needed around those functions. Doc comments on those would be nice as well. I don't think this is significant enough to block merge though.

[adriangb]

Thank you for taking this over @inquisitivepenguin !