Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Function type as return type not supported #656

Open
derRaab opened this issue Jul 28, 2017 · 3 comments
Open

Function type as return type not supported #656

derRaab opened this issue Jul 28, 2017 · 3 comments

Comments

@derRaab
Copy link

derRaab commented Jul 28, 2017

Hi - first of all - thanks for this great plugin! While writing some externs I discovered that the plugin doesn't support a function type as return type. I created a valid code example on https://try.haxe.org/#e1A50 which I paste here:

class Test {
    static function main() {
        // a is fine
        var a : Any -> Any -> Any =
        function ( any : Any, any2 : Any ) : Any {
            trace( "a()" );
            return any;
        };

        // b is fine as well
        var b : (Void -> Void) -> Void =
        function ( func : Void -> Void ) : Void {
            trace( "b()" );
        };

        // c isn't:
        var c : Void -> (Void -> Void) =
        function () : Void -> Void {
            trace( "c()" );
            return function() : Void {
                trace( "d()" );
            }
        };

        a( "any", "any");
        b( function() { trace( "b(())" ); } );
        var d = c();
        d();
    }
}

And here a little shot of the error displayed in IntelliJ IDEA:

bildschirmfoto 2017-07-28 um 16 21 39

Looks not that bad in this code example, but on a different setup it avoids autocompletion, imports validation and stuff like that:

bildschirmfoto 2017-07-28 um 15 58 19

@EricBishton
Copy link
Member

Same base issue as #293 and #575: The parser has trouble with nested function type arguments.

We may be able to keep the parser from giving up when the type isn't parsed correctly (using better recovery rules?). Fixing the nested function types would be better, but it's probably going to take a week's worth of work. (Which is why it's still an outstanding issue after two people have already taken a crack at it.)

See #294 for Boyan's first attempt at fixing it. See grammar/haxe.bnf for a commented correct set of parsing rules. The real work is in the Psi and Models.

@derRaab
Copy link
Author

derRaab commented Jul 28, 2017

Ok. Sorry - I was having a hard time searching for it and in the end I didn't search on Github.

@EricBishton
Copy link
Member

No Problem. The example is still helpful.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants