Bug 93298 - [1.5][compiler] nested statics and templates compilation error
Summary: [1.5][compiler] nested statics and templates compilation error
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.1   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 3.1 M7   Edit
Assignee: Philipe Mulet CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-04-29 13:40 EDT by Ross Judson CLA
Modified: 2005-05-11 13:34 EDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ross Judson CLA 2005-04-29 13:40:02 EDT
Strange error message when compiling static classes nested inside abstract when
type parameters are present.  This appears to be a new problem in the compiler.
 It's occuring for me with I20050426-1700.  The error:

"Cannot make a static reference to the type parameter IndexedIter", at "return
new IndexedIter();"


/*
 * Created on Apr 29, 2005
 *
 */
package com.soletta.stream;

import java.util.Iterator;

abstract public class Isolate<T> implements Iterable<T>
{
   final Iterable<T> source;

   protected Isolate(Iterable<T> source) {
      this.source = source;
   }

   public static class Indexed<OUT> 
   {
      Iterable<OUT> source;
      final int from, to;

      protected Indexed(Iterable<OUT> source, int from, int to) {
         this.source = source;
         this.from = from;
         this.to = to;
      }

      public Iterator<OUT> iterator() {
         return new IndexedIter();
      }

      class IndexedIter implements Iterator<OUT>
      {
         Iterator<OUT> src = source.iterator();
         int           n   = from;
         int           c   = from;

         IndexedIter() {
         }

         private void drop() {
            while (n > 0 && src.hasNext()) {
               src.next();
               n--;
            }
         }

         public boolean hasNext() {
            if (n > 0)
               drop();
            return (to < 0 || c < to) && src.hasNext();
         }

         public OUT next() {
            if (n > 0)
               drop();
            if (to >= 0 && c >= to) {
               throw new IndexOutOfBoundsException();
            }
            c++;
            return src.next();
         }

         public void remove() {
            if (n > 0)
               drop();
            if (to >= 0 && c >= to) {
               throw new IndexOutOfBoundsException();
            }
            src.remove();
         }

      }

   }
}
Comment 1 Ross Judson CLA 2005-04-29 13:47:30 EDT
Note that if the inner static class "Indexed" is moved into its own file,
everything is fine (IndexedIter is then still an inner class for Indexed, but
Indexed is no longer "inside" the outer static class.
Comment 2 Philipe Mulet CLA 2005-04-29 15:42:41 EDT
Reproduced
Comment 3 Ross Judson CLA 2005-04-29 19:27:12 EDT
I would be happy to share the source for the entire library this snippet comes
from with the Eclipse compiler team.  It beats up the compiler pretty
thoroughly, as it uses a lot of this kind of thing, trying to do a kind of
virtual typing for stream composition.  I end up having to do quite a few Clean
operations on Eclipse projects while I'm working with the code and it is in an
uncompilable state, although once the code is syntactically correct I usually
don't have to resort to clean.

public interface Stream<IN, OUT, OP extends Stream<?, OUT, OP>> 
   extends 
      Iterable<OUT>, 
      StreamInternal<IN, OUT, OP>,
      Begin<IN, OP>
{
   /** Dump the contents of the stream to the display, with a 
    * header on each element.  This is a pull-through operation, 
    * causing contributing streams to be pulled.
    * 
    * @return
    */
   OP dump(String header);

....
Comment 4 Philipe Mulet CLA 2005-04-30 04:02:42 EDT
Sounds a neat testcase. FYI, we addressed today a problem in our incremental
compiler which wouldn't notice type parameter changes (by accident) until now.
These should now be watched, and consequently you shouldn't need to trigger
clean build any longer. Now, if you still find some issues, please enter a
separate defect.
Comment 5 Philipe Mulet CLA 2005-04-30 04:11:12 EDT
Added GenericTypeTest#test635
Comment 6 Philipe Mulet CLA 2005-05-02 04:51:07 EDT
Fixed by moving the updating of insideStaticContext flag after member type lookup.
Comment 7 Philipe Mulet CLA 2005-05-02 04:52:52 EDT
Maxime - pls try to get a hold on sample code mentionned in comment#3 to check
whether issue can still be reproduced.
Comment 8 Maxime Daniel CLA 2005-05-02 12:19:06 EDT
(In reply to comment #3)
> I would be happy to share the source for the entire library this snippet 
comes
> from with the Eclipse compiler team.
Ross, we'd be more than interested. Could you please let us know your preferred
way of doing so?
Comment 9 Ross Judson CLA 2005-05-03 10:30:55 EDT
(In reply to comment #8)
> (In reply to comment #3)
> > I would be happy to share the source for the entire library this snippet 
> comes
> > from with the Eclipse compiler team.
> Ross, we'd be more than interested. Could you please let us know your preferred
> way of doing so?

Have sent email to Maxime with the library attached.  
Comment 10 Maxime Daniel CLA 2005-05-03 12:08:36 EDT
Got source tree, thx.
Comment 11 Olivier Thomann CLA 2005-05-11 13:34:18 EDT
Verified in I20050510-0010