[jdt-core-dev] Re: Bug 8134

[Philippe_Mulet@xxxxxxx]

No problem, good will is all which matter here. I'll be technical first,
and if you don't follow me, then just ask what you are missing and we will
dig into it.

1. Can you get Eclipse in Eclipse ? i.e. setup a workspace which contains
Eclipse development projects ?
      Alternatively, you can use the plug-in importer, and start from
there.

      Download a SDK Eclipse build (suggest 20020312)
      Launch it onto a new workspace
      Use File>Import>Plugins and point at your SDK Install directory so as
to suck in some plugins,
            take them all in binary form (no need to expand sources at this
point).
      In the repository view, add a connection to dev.eclipse.org, so as to
grab the source for the JDT/Core project:
            host  dev.eclipse.org
            login anonymous         // this gives you read-only access, but
this is all you need for now
            repo  /home/eclipse
      Grab project 'org.eclipse.jdt.core' and version tagged 'v_231' (this
is the last integration one)

      From there on, you should have an Eclipse in Eclipse workspace, which
contains one source project: JDT/Core.
      You can run this dev Eclipse using the 'Runtime Workbench' launcher,
to prove you didn't break anything.

2. Now you have the sources, you need to know a few things:
      - the compiler proceeds as follows:
            - it parses sources into an AST (tree of parse nodes,
representing the program constructs)
            - the parse tree is iterated several times to decorate it with
appropriate information for code generation,
                  and discover programming errors
            - first iteration is name resolution (#resolveType), during
which all name reference is bound to a binding
                  representing its target element (field, local, type,
method).
            - second iteration is flow analysis (#analyzeCode), during
which we check all initialization rules, and
                  perform the innerclass emulation (some references need
extra support at runtime, like synthetic
                  access methods, etc...).
            - last iteration is the code generation (#generateCode) during
which the classfile bytes are built.
                  it interacts with a CodeStream which is responsible for
producing the actual bytecode values.

Typically, what you would need to do, is for a SingleNameReference which
occurs to be a field one (at code gen time, it knows this), you need to
find out you are inside a loop, and request the loop to allocate a local
variable to indirect through. This information is available during the
stage right before the code gen, the flow analysis (#analyzeCode(...)).
Then if this extra variable is allocated, the field reference would now to
use it instead of the original one at code gen time.



                                                                                                            
                      "shmuel siegel"                                                                       
                      <shmuels@hotmail         To:      <Philippe_Mulet@xxxxxxx>                            
                      .com>                    cc:                                                          
                                               Subject: Bug 8134                                            
                      03/12/2002 11:01                                                                      
                      PM                                                                                    
                                                                                                            
                                                                                                            



I'll be glad to help if you give me a little guidance. I am not a compiler
writer but I do understand what is wanted for the output.

Shmuel