Missing `js.Boot.__string_rec` from output with `-dce std`

[andyli]

enum E {
    E1;
}

class Test {
    static function main():Void {
        trace(E.E1);
    }
}

JS output (with -dce std, using Haxe 3ab3ad1):

(function () { "use strict";
var $estr = function() { return js.Boot.__string_rec(this,''); };
var E = { __constructs__ : ["E1"] };
E.E1 = ["E1",0];
E.E1.toString = $estr;
E.E1.__enum__ = E;
var Test = function() { };
Test.main = function() {
    console.log(E.E1);
};
Test.main();
})();

[Simn]

I've never really noticed that $estr stuff before. It is generated as soon as an enum type is part of the output and then entails the entire string_rec code. I don't understand why we do all this given that we don't define how enums are represented at runtime anyway.

[andyli]

I didn't notice that either until I was looking at the source code.
Actually both node and chrome can print out the enum object with reasonably useful info, although not in the same format as other targets.

Not really critical, but I think having the same string representation across targets is a good thing.
And I remembered there was some effort being put to trace numbers, Array, and anonymous object in a consistent way. So it is better not to make an exception here?

[Simn]

For explicit String conversion sure, but just tracing it or in fact just having it shouldn't come with the huge string_rec code in my opinion.

[Simn]

I still don't know what to do with this. Should we really keep string_rec as soon as we have an enum in the output?

I was thinking about adding a filter which invokes a custom callback on unification cases. This would allow us to detect the assignment of an enum type to String and then activate some feature which causes string_rec to be kept. This would also help me with #2811.