Incorrect properties lifting to the parent node

[pluralia]

Rules AssignmentExpression, OrExpression and AndExpression have a common property operator and inherit BinaryExpression, so the BinaryExpression in the generated AST interface has to contain a property operator: 'Or' | 'And' | ':'. However, type of the operator is 'Or' | 'And', because it omits an operator of the AssignmentExpression rule.

entry Model:
    elements+=OrAndAssignmentExpression*;

OrAndAssignmentExpression infers Expression:
    OrExpression ({infer AssignmentExpression.left=current} operator=':' right=OrExpression)*;

// Dummy rule to make AssignmentExpression inherit from BinaryExpression
AssignmentExpression infers BinaryExpression:
    {infer AssignmentExpression} left=ID operator=':' right=OrExpression;

OrExpression infers Expression:
	AndExpression ({infer BinaryExpression.left=current} operator='Or' right=AndExpression)*;

AndExpression infers Expression:
	ValueExpression ({infer BinaryExpression.left=current} operator='And' right=ValueExpression)*;

ValueExpression infers Expression:
	{infer BoolValue} value=BOOL | {infer IDValue} value=ID;

terminal ID:				   /\$?[_a-zA-Z][\w_]*/;
terminal BOOL returns boolean: /(true)|(false)/;

Langium version: 0.5.0 Package name: langium-cli

Steps To Reproduce

1. Generate an AST with the grammar above
2. Check out the BinaryExpression rule in the AST

The current behavior

Type of operator from BinaryExpression doesn't contain ':'.

export interface BinaryExpression extends Expression {
    operator: 'Or' | 'And'
    ...
}

The expected behavior

Type of operator from BinaryExpression contain ':'.

export interface BinaryExpression extends Expression {
    operator: 'Or' | 'And' | ':'
    ...
}

[montymxb]

I'll jump on this one :octocat:

[pluralia]

Can be resolved by types declaration. Depends on #510.

[msujew]

@pluralia In what way is #510 related to property lifting? It doesn't change anything about meta model generation.

[pluralia]

@msujew The problem in the example appears in the dummy rule -- we could try to replace it with declared types and solve the problem. Declared types with validation implemented in #510 are more suitable for this goal.

We also should investigate the need to solve the problem for the case where similar constructions are not used as a dummy rule, but I think it would be good to open a new issue with better example for this case.

[montymxb]

There's also a problem w/ formal reasoning about what makes a rule valid, until 510 is added. Currently we can't assume that a rule returning some type (inferred or declared) will be valid if it satisfies the properties stated by the type, because we can't validate the inheritance that is used to build that type. Normally we could duplicate the property in the child type to fix this, but that's disallowed, and puts us in a bit of a quandary.