Support abstract modifier on classes and methods

[Simn]

This PR adds support for abstract classes.

At syntax-level, we allow abstract as a modifier for both classes and fields. We also allow parsing abstract interface, but both abstract typedef and abstract abstract are parser errors.

During type-loading, there's a bunch of checks for invalid combinations, such as abstract final. See the tests for details.

The abstract property is as follows:

• If a class has a method which is abstract, the class itself must be marked as abstract. We can debate later if we want to keep this mandatory (in fact, we already infer the class to be abstract in order to avoid repeating errors).
• If a method is abstract, it must not have an expression.
• If a class is abstract, both new ThatClass() and ThatClass.new are disallowed.
• If a class extends an abstract class, it must either be made abstract itself or implement all abstract member methods of the extended class and all its parent classes.

That last part is implemented in check_abstract_class. It is implemented with overload support, which lead to the following algorithm:

Given a non-abstract class C extending an abstract class AC:

1. Collect the names of all member methods of AC and all its parent classes.
2. For each such name:
   1. Collect all overloads with that name on AC and all its parent classes.
   2. For each such overload cf:
      1. If the cf isn't marked abstract, ignore it.
      2. Otherwise, if C doesn't implement cf, add it to a missing list
3. If missing isn't empty, emit an appropriate error.

A class is considered to implement an overload cf if it has a method with the same name for which Overloads.same_overload_args is true. That's how we check overload equality in general.

[RealyUniqueName]

I think we should aim to generate native abstract classes where supported. But that could be done later.

[Simn]

Actually, I think we have to do it right away. Otherwise we run into problems if an abstract method has a return type since we can't just generate an empty block for it...

[RealyUniqueName]

Ah, ok

[RealyUniqueName]

Why abstract interface is allowed at syntax level?

[Simn]

For consistency. All other class-specific modifiers are allowed on interfaces as well and only fail during typing, so I figured we should do this for abstract as well.

[RealyUniqueName]

This PR is missing an implementation of the following statement from the proposal:

Abstract class is not required to implement all the methods of interfaces that class implements. Instead missing interface implementations are implicitly treated as abstract methods

[RealyUniqueName]

Also inlining is not treated well. The following sample should emit two errors, but none are emitted:

class Main {
	static function main() {
		var w:Abstr = null;
		inline w.test(); // Missing error: Cannot inline abstract method
	}
}

abstract class Abstr {
	abstract public inline function test():Void; // Missing error: Inline function cannot be abstract
}

[Simn]

This PR is missing an implementation of the following statement from the proposal:

Abstract class is not required to implement all the methods of interfaces that class implements. Instead missing interface implementations are implicitly treated as abstract methods

Yeah, hmm... this might introduce some typing pass concerns if we generate these fields at the time we verify the interface. There might also be some complications once overloads get involved because we have to manage cf_overloads correctly.

Can we hold back on this change for now?

[RealyUniqueName]

Sure. It won't be a breaking change to allow that later.

[Simn]

I've just tried to implement this out of curiosity and indeed ran into the typing pass problem. It seems to work by changing the interface check from PForce to PConnectField, which looks like a sensible change anyway. However, it's hard to tell what consequences this might have, so at the very least I would like to keep it separate for this PR.

So, anything else?

[Simn]

This requires generator updates for HL, hxcpp and PHP.

@RealyUniqueName Could you handle PHP? I'll try to figure out the others.

[RealyUniqueName]

So, anything else?

LGTM

This requires generator updates for HL, hxcpp and PHP.

I mean it's not necessary to be a part of this PR.

[Simn]

I mean it's not necessary to be a part of this PR.

Sorry, by "this" I'm referring to this PR in general. I thought it was passing, but that was only because I was using Void-returning functions and didn't actually test if calls to them succeed.

[Simn]

@hughsando Could you check the gencpp.ml changes here? I've implemented abstract methods to be generated as pure virtual functions, and then had to fiddle around a lot to get the _dyn stuff working and make sure that no code that calls the constructor is generated.

[hughsando]

I don't think this function should be virtual, since internally it will call a virtual function.
Then, it is not needed if the "doDynamic" logic (nonVirtual || not (is_override field ) ) && (reflective class_def field ) is not required. This would be the case when one declared abstract method also exists in a parent class, or it is declared "@:unreflective"

[Simn]

Right, good point. I've changed that in 7010960

[Simn]

Alright, CI is green!

I'll go ahead and merge this now. There are probably some details that can be improved in various generators, but we can do that later.