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

Metadata cannot be extracted from fields and statics #50

Closed
anissen opened this issue Jun 4, 2014 · 7 comments
Closed

Metadata cannot be extracted from fields and statics #50

anissen opened this issue Jun 4, 2014 · 7 comments

Comments

@anissen
Copy link

anissen commented Jun 4, 2014

I have the following sample (from http://haxe.org/manual/lf-metadata.html, slightly modified)

import haxe.rtti.Meta;

@author("Nicolas")
@debug
class MyClass {
    @author("Nicolas")
    @range(1, 8)
    var value:Int;

    @broken
    @:noCompletion
    static function method() { }
}

class Test {
    static public function main() {
        trace(Meta.getType(MyClass)); // { author : ["Nicolas"], debug : null }
        trace(Meta.getFields(MyClass)); // [1,8]
        trace(Meta.getStatics(MyClass)); // { broken: null }
    }
}

Compiling with Haxe to JavaScript and running with Node gives the following output:

{ author: [ 'Nicolas' ], debug: null }
{ value: { author: [ 'Nicolas' ], range: [ 1, 8 ] } }
{ method: { broken: null } }

Similarly, compiling with Haxe and running with Neko gives the following output:

Test.hx:17: { debug => null, author => [Nicolas] }
Test.hx:18: { value => { range => [1,8], author => [Nicolas] } }
Test.hx:19: { method => { broken => null } }

On try.haxe.org running the code (http://try.haxe.org/#8cFb8) gives the following output:

Object {author: Array[1], debug: null}
Object {}
Object {} 

That is, the result from Meta.getType(MyClass) is correct but the result from Meta.getFields(MyClass) and Meta.getStatics(MyClass) is incorrect.

@clemos
Copy link
Owner

clemos commented Jun 6, 2014

It's weird, looks like a bug in the compiler ?
Try-haxe compiles with -dce full
but I can't reproduce locally...

@clemos
Copy link
Owner

clemos commented Jun 6, 2014

Ok I've managed to reproduce, it's due to -dce full...

clemos added a commit to clemos/haxe-sublime-bundle that referenced this issue Jun 6, 2014
@clemos
Copy link
Owner

clemos commented Jun 6, 2014

Best option would be to expose the dce flag in the GUI,
but it's not planned right now :S

@anissen
Copy link
Author

anissen commented Jun 6, 2014

A-ha, that's seems to be a clue! Compiling locally w. -dce full gives an empty result on both Neko and JavaScript.

I've updated the sample to use the previously unused fields:

import haxe.rtti.Meta;

@author("Nicolas")
@debug
class MyClass {
    @author("Nicolas")
    @range(1, 8)
    var value:Int;

    public function new(v) { value = v; }

    @broken
    @:noCompletion
    public static function method() { }
}

class Test {
    static public function main() {
        var c = new MyClass(42);
        MyClass.method();

        trace("Type");
        trace(Meta.getType(MyClass)); // { author : ["Nicolas"], debug : null }
        trace("Fields");
        trace(Meta.getFields(MyClass)); // [1,8]
        trace("Statics");
        trace(Meta.getStatics(MyClass)); // { broken: null }
    }
}

... and then the output is as expected:
myscreenshotname 2014-06-06 at 12 04 17 pm

It might be a "feature" rather than a "bug" but it's still pretty confusing. Maybe using haxe.rtti.Meta should an error/warning when fields are being removed due to dead code elimination. Or better yet; make the given fields not be removed by DCE - although that might be impossible to determine if reflection is involved...

@clemos
Copy link
Owner

clemos commented Jun 6, 2014

In any case, it's an haxe compiler issue now ;)

@clemos
Copy link
Owner

clemos commented Jun 6, 2014

Closing the issue, feel free to reopen if needed

@clemos clemos closed this as completed Jun 6, 2014
@anissen
Copy link
Author

anissen commented Jun 6, 2014

Yeah, I agree that it's a compiler issue.

It might be nice to simply list the compiler flags somewhere on try.haxe for information. I could have reproduced the problem immediately in the haxe compiler if I had known that the -dce full flag was used.

Dunno, this instance might be a very edge-case-issue. Anyhow, thanks for your help :)

@clemos clemos mentioned this issue Nov 15, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants