Fix container types calculation

[pluralia]

Closes #150.

• drops union types from the calculation of container types
• drops sharing of container types over connected components: now the container types are lifted only lifted to the parents
• if one of the children has no container types, the parent also loses container types

Examples:

interface A extends AstNode { $container: E | F | G; strA: string }
interface B extends AstNode { $container: E | F | H; strB: string }
interface C extends A, B { $container: E; strC: string }
interface D extends A, B { $container: F; strC: string }
interface E extends AstNode{ c: C }
interface F extends AstNode{ d: D }
interface G extends AstNode{ a: A }
interface H extends AstNode{ b: B }

X has no container types -- A and B, too

interface A extends AstNode { strA: string }
interface B extends AstNode { strB: string }
interface C extends A, B { $container: E; strC: string }
interface D extends A, B { $container: F; strC: string }
interface X extends A, B { strC: string }
interface E extends AstNode{ c: C }
interface F extends AstNode{ d: D }
interface G extends AstNode{ a: A }
interface H extends AstNode{ b: B }

[spoenemann]

Thanks, it looks mostly good (found only one wrongly computed container in the grammar).

[spoenemann]

This looks wrong: CharacterRange is not the only possible container of Keyword.

[pluralia]

@spoenemann, it's correctly for the current calculation:

• Keyword is used in the assignment in the only one place -- in CharacterRange
• One more usage is the rule PredicatedKeyword that infers Keyword -- 1) the interface PredicatedKeyword will not be generated by the grammar definition, so no its income to container types; 2) if we would have the interface PredicatedKeyword, it would be a child of Keyword -- no income to container type, too, because we don't lift children container types in parents anymore
• Other usages are in type alternatives and are ignored by the new algorithm: AssignableTerminal, CrossRefTerminal, AbstractTerminal

[spoenemann]

There's a rather complex chain of unassigned rule calls here:

Alternatives > ConditionalBranch > UnorderedGroup > Group > AbstractToken > AbstractTokenWithCardinality > AbstractTerminal > Keyword

Alternatives has two possible containers: Group and ParserRule. Keyword should inherit those containers.

I've seen that in simpler examples of unassigned rule calls, the container types are fine. So maybe this is just a special case for which we can create an issue, but we ignore it for now?

[pluralia]

By my understanding it's not an issue, but an expected behaviour for the current algorithm.

The moment is the algorithm is working with inferred / declared types (from the ast.ts, basically) and not with parser rules content. That means, not all information that you can see in the .langium is available for the algorithm. As a result:

1. Most of types with the names from the chain doesn't exist
2. Group and ParserRule contain only AbstractElement and not Alternatives

[spoenemann]

Ok let's ignore the issue for now and get back to it in case it turns out to be a real problem. I created #1063 so we don't forget.

[spoenemann]

Thanks!