Implement trait

[Bromeon]

Parses traits, largely reusing the impl implementation. I added code to parse_impl.rs, didn't have a new good name for the file, so I left it for now...

Unfortunately this introduces a breaking change, because existing TyDefinition did not account for : Bounds and optional = initializer. In general, we should probably mark everything #[non_exhaustive] to at least have the option to add fields in non-breaking ways.

But no urgency from my side for any release, just thought I'd implement this while I'm in the flow 😉

[PoignardAzur]

My first instinct would be to avoid adding #[non_exhaustive] to structs unless we also give them constructors.

[Bromeon]

My first instinct would be to avoid adding #[non_exhaustive] to structs unless we also give them constructors.

Good point. I would expect the typical usage is to read those structs (from a parsed result), but there may be use cases where people create them (for testing, or local manipulation).

I removed #[non_exhaustive] from TyDefinition. I guess it's OK to have small breaking API changes every now and then, as we're still in 0.x.

[PoignardAzur]

LGTM.

[PoignardAzur]

I would also add a test for something like:

trait Foo {
    type X = i32;
    const N: i32 = 42;
}

Eg a trait declaration which is semantically invalid but syntactically valid.

[Bromeon]

Don't we already test those, with SHORT_NAME and TypeWithDefault?

const LONG_NAME: &'static str;
const SHORT_NAME: char = 'T';

type AssocType: Bound;
type TypeWithDefault = Rc<RefCell<MyStruct>>;

[PoignardAzur]

It might be more expressive to add a test where those are in a trait body, to show the range of accepted syntax?

Eh, it doesn't really matter. The types are orthogonal enough that you can probably assume that if some construct parses in one context, it parses in another.