Do we need an isBridge check in the reflection API?

[Eugene Burmako]

Hi folks,

Do I have to add api.Symbol.isBridge to the API, or there's some other
way of detecting whether a symbol is a bridge?

Also what about VBRIDGE? Why doesn't internals.Symbol.isBridge include
VBRIDGE?

Cheers,
Eugene

[Paul Phillips]

On Thu, Aug 9, 2012 at 4:25 PM, Eugene Burmako <eugene....@epfl.ch> wrote:

Do I have to add api.Symbol.isBridge to the API, or there's some other
way of detecting whether a symbol is a bridge?

I don't know, but you should more likely add isHidden.

Also what about VBRIDGE? Why doesn't internals.Symbol.isBridge include
VBRIDGE?

I don't know, but isHidden covers both bridge flags.

[martin odersky]

BRIDGE/isBridge is an erasure bridge. VBRIDGE was the attempt to maintain some semblance of binary compatibility in 2.9.1. It's generated from methods marked @bridge. In fact, we should remove all those methods in 2.10. 

Cheers

 - Martin

[Eugene Burmako]

From this I infer that isBridge and isVbridge is unnecessary. Thanks!

[Eugene Burmako]

How does HIDDEN compare with SYNTHETIC?

[Paul Phillips]

On Fri, Aug 10, 2012 at 3:59 AM, Eugene Burmako <eugene....@epfl.ch> wrote:

How does HIDDEN compare with SYNTHETIC?

% git log --grep=HIDDEN

commit b68d57210abe536ee43a8a1c4ec4b4629145ccc2 (refs/pull/949/head)

Author: Paul Phillips <pa...@improving.org>

Date:   3 weeks ago

    Expanded use of HIDDEN flag.

    

    Like the comment says:

    

      /** Symbols which are marked HIDDEN. (Expand this list?)

       *

       *  - $outer fields and accessors

       *  - super accessors

       *  - protected accessors

       *  - lazy local accessors

       *  - bridge methods

       *  - default argument getters

       *  - evaluation-order preserving locals for right-associative and out-of-order named arguments

       *  - catch-expression storing vals

       *  - anything else which feels a setFlag(HIDDEN)

       */

    

    I also changed a few safe-appearing locations to check isHidden

    rather than isSynthetic.  Review by @dragos, @odersky.

commit 456d76d7f038891ffbd571eef06cf9d38425dc74 (refs/pull/851/head)

Author: Paul Phillips <pa...@improving.org>

Date:   5 weeks ago

    Added a HIDDEN flag.

    

    [Still not a fan of the massive overlap between GenJVM and GenASM. I do

    not think such duplication should be allowed into master at all, neither

    in experimental backends nor anywhere else. Putting us in the position

    that we have to actually switch to stop incurring the duplication is

    engineering-by-prayer.]

    

    The SYNTHETIC flag was long ago discovered to be inadequately specific

    to allow for emitting ACC_SYNTHETIC in bytecode. In this commit is born

    a HIDDEN flag, which signals the flagged symbol as implementation detail

    which should not be considered during typechecking, and which will

    receive ACC_SYNTHETIC during code generation.

    

    Unsure what should be hidden, I conservatively marked a few things which

    seem safely hidable.

    

     - $outer fields and accessors

     - classes whose classfile has the jvm Synthetic attribute

       (not to be confused with the SYNTHETIC flag)

    

    I leave additional choices to those who have a better idea how

    this will materialize (i.e. IDE guys.)

    

    It is easy to selectively introduce this flag; but the SYNTHETIC flag

    is set or checked for in so many places, it is very difficult to alter

    the logic around it (either by setting it less, or checking for HIDDEN

    only) with much confidence. So right now HIDDEN is only used to help

    ACC_SYNTHETIC make it into bytecode - it is only set in conjunction with

    SYNTHETIC, and it doesn't help anyone hide from the typechecker.

    

    Review by @dragos, @odersky.