Func ty

[Y-Nak]

Please start reviewing this PR after #931

This PR integrates a function definition into Fe type system. For example, When fn foo<T>(t: T) is defined, then foo(1i32) would conceptually be TyApp(FuncDef(foo), i32)); this representation will allow us to check all type level check (e.g., the trait bound check and a kind check) in the same way with ADT types.

The other changes are

Method Collector

The method collector collects all methods implemented for all types and performs a conflict check. In our new type system, we can use an impl block for HKT, e.g.,

impl Option {
    pub fn foo<A>(self: Self<A>) {...}
}

Method collector reason foo method is implemented for type Option<A>, this means foo method will conflict if there is another implementation like the one below.

impl<T> Option<T> {
    pub fn foo(self) {...}
}

Trait method bound strictness check

This check verifies if the implemented method doesn't have a stricter constraint than the one that the corresponding trait method definition has. e.g.,

trait Foo {
    fn foo<T: Clone>(self, t:  T) {}
}

impl Foo {
    // Error!
    // fn foo<T: Clone + Copy>(self, t: T) {}
    // But a weaker constraint is ok.
    fn foo<T>(self, t: T) {}
}

Trait method's argument label integrity check

This check verifies if the implemented method has the same labels as the trait method definition. Since labels are part of the public interface of the trait, we need to ensure the same labels are used. On the other hand, argument names don't need to follow the rule.

Misc

• Check if all the required methods are implemented
• Check if the argument name is not duplicated
• Check if the generic parameter is not conflicted with the parent item's generic parameter
• Allow to specify the self type explicitly(which is necessary, especially for HKT), and check for the consistency of the self type(specified self type should start with the same type as Self).

Discussion

The current implementation tentatively allows for the function argument label to be duplicated, which is the same rule as Swift. I think this would be useful when a function is commutative and a user wants to emphasize that property.