flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: Variable Renaming (was Re: [Falcon] Proposal for new ActionScript language feature: Optionally rename an import)
Date Mon, 03 Oct 2016 15:09:45 GMT
Update:  Turns out that FalconJX already calls GCC with
--generate-exports, and methods are being exported in the js-release
version.  What it looks like to me is that for the one case I am debugging
(ReflectionTesterTest), the setUpBeforeClass method is removed by GCC dead
code removal since there is no obvious code path that calls it.  The test
runner sees that setUpBeforeClass is listed as the [BeforeClass] method
but can't find the method and just assigns undefined as the
beforeClassFunc.  The runner then doesn't call any beforeClassFunc so the
test is not set up properly and fails.  The runner could detect this
condition and report an error, but fundamentally, we need to keep certain
methods from being removed.

IOW, using @export doesn't prevent a method from being removed by dead
code removal.  From the GCC doc, if we generated our own function calls to
exportSymbol/exportProperty, it would prevent the method from being
removed.  So, I am now off to teach FalconJX to generate more
exportSymbol/exportProperty calls (FalconJX already generates one
exportSymbol for the class definition).

Again, I do not want to generate exportSymbol for every public property.
I think we want to use @export and allow for dead code removal most of the
time.  My plan is to add an option similar to -keep-as3-metadata.  I am
going to call it -keep-code-with-metadata for now.  Any methods annotated
with a metadata name in that list will have an exportSymbol or
exportProperty generated for it.  A simpler option is to require folks to
add some sort of @dontremove directive or metadata to their code, but that
would be painful to update existing code bases.


On 10/1/16, 10:11 PM, "Alex Harui" <aharui@adobe.com> wrote:

>On 10/1/16, 12:37 PM, "Greg Dove" <greg.dove@gmail.com> wrote:
>>Sorry I did not have time to read up on this yet.
>>If --generate-exports can somehow restore that naming retention for
>>static members annotated with '@export' then that will be a great
>>point as an option to switch this on or off when needed.
>AIUI, the use of @export doesn't do anything until you turn on
>--generate-exports.  But then, it export every public API in the entire
>app, which is probably not what you want.

View raw message