search

scala / bug

Scala 2 bug reports only. Please, no questions — proper bug reports only.
https://scala-lang.org
232 stars 21 forks source link

Plugin reports errors not generated by compiler #1887

Closed scabug closed 13 years ago

scabug commented 15 years ago

Within Eclipse, the Scala plugin (either the latest nightly, for every value of nightly in several weeks, perhaps months, preceding this date, or the previous official releases of the plugin) reports a number of "Scala errors" that are not generated by the compiler when it builds. Lately, I have taken to filtering out Scala errors since they are incorrect and distracting, and only check after an update to see if it has been fixed.

I double-checked my .classpath and .project files to be sure that they are as recommended; I checked to be sure that I was not mixing nightly and previous-release versions of the compiler; I tried cleaning the project, refresh, and manual deletion of offending files, and the problem persists.

Platform is MacOS 10.5.6, Java 1.6, Eclipse 3.4.1 and 3.4.2, and in the case of 3.4.2, a fresh install with fresh installation of plugins. This bug is VERY ROBUST FOR ME; it does not depend upon a particular release of this or that.

In the first attachment, you will see some of the errors. There is actually a sub-error, which is that the Scala plugin is playing dumb -- it claims not to know the location of the error, yet when I double-click on it, I go directly there (this window is the result of double-clicking the first error, with the file not previously open).

Note that the first error reported is not the first error in the file -- the "Unknown" location messes up the sort.

The first error in the file is at [https://projectfortress.sun.com/Projects/Community/browser/trunk/ProjectFortress/src/com/sun/fortress/scala_src/typechecker/ExportChecker.scala?rev=3633#L379 line 379 of ExportChecker.scala]

reference to AnyType is ambiguous;
it is imported twice in the same scope by
import com.sun.fortress.nodes._
and import com.sun.fortress.scala_src.nodes._

This error is NOT reported by the compiler, run from within Ant. I tried also upgrading the version of that compiler to the latest by editing build.xml, and it persists in not being reported by the compiler.

The imports (also visible by following the link above):

package com.sun.fortress.scala_src.typechecker

import _root_.java.util.ArrayList
import _root_.java.util.{List => JavaList}
import _root_.java.util.{Set => JavaSet}
import edu.rice.cs.plt.collect.CollectUtil
import edu.rice.cs.plt.collect.Relation
import edu.rice.cs.plt.tuple.{Option => JavaOption}

import com.sun.fortress.compiler.GlobalEnvironment
import com.sun.fortress.compiler.index.ApiIndex
import com.sun.fortress.compiler.index.ComponentIndex
import com.sun.fortress.compiler.index.ParametricOperator
import com.sun.fortress.compiler.index.{Constructor => JavaConstructor}
import com.sun.fortress.compiler.index.{DeclaredFunction => JavaDeclaredFunction}
import com.sun.fortress.compiler.index.{DeclaredVariable => JavaDeclaredVariable}
import com.sun.fortress.compiler.index.{Dimension => JavaDimension}
import com.sun.fortress.compiler.index.{Function => JavaFunction}
import com.sun.fortress.compiler.index.{FunctionalMethod => JavaFunctionalMethod}
import com.sun.fortress.compiler.index.{ParamVariable => JavaParamVariable}
import com.sun.fortress.compiler.index.{SingletonVariable => JavaSingletonVariable}
import com.sun.fortress.compiler.index.{TypeAliasIndex => JavaTypeAliasIndex}
import com.sun.fortress.compiler.index.{Unit => JavaUnit}
import com.sun.fortress.exceptions.InterpreterBug
import com.sun.fortress.exceptions.StaticError
import com.sun.fortress.exceptions.TypeError
import com.sun.fortress.repository.FortressRepository
import com.sun.fortress.scala_src.nodes._
import com.sun.fortress.scala_src.useful._
import com.sun.fortress.scala_src.useful.Lists._
import com.sun.fortress.scala_src.useful.Options._
import com.sun.fortress.scala_src.useful.Sets._
import com.sun.fortress.nodes._
import com.sun.fortress.nodes_util.Modifiers
import com.sun.fortress.nodes_util.NodeFactory
import com.sun.fortress.nodes_util.NodeUtil
import com.sun.fortress.nodes_util.Span
import com.sun.fortress.parser_util.IdentifierUtil
import com.sun.fortress.useful.HasAt
    def equalTypes(left: Type, right: Type): Boolean =
        (left, right) match {
            case (AnyType(_), AnyType(_)) => true

AnyType is defined in a generated Java file (AnyType.java) and in a generated Scala file (FortressAst.java). The relevant parts of FortressAst.java appear to be:

/* THIS FILE WAS AUTOMATICALLY GENERATED BY
   com.sun.fortress.astgen.ScalaAstGenerator FROM Fortress.ast */

package com.sun.fortress.scala_src.nodes
import com.sun.fortress.scala_src.useful._
import com.sun.fortress.nodes_util._
import com.sun.fortress.useful.HasAt
import _root_.scala.collection.mutable.ListBuffer
import _root_.java.math.BigInteger
import com.sun.fortress.scala_src.useful.ASTGenHelper._
...
object AnyType {
   def unapply(node:com.sun.fortress.nodes.AnyType) = 
      Some((scalaify(node.getInfo()).asInstanceOf[com.sun.fortress.nodes.TypeInfo]))
   def apply(getInfo:com.sun.fortress.nodes.TypeInfo) = 
      new com.sun.fortress.nodes.AnyType(javaify(getInfo).asInstanceOf[com.sun.fortress.nodes.TypeInfo])
}
...
object Type {
   def unapply(node:com.sun.fortress.nodes.Type) = 
      Some((scalaify(node.getInfo()).asInstanceOf[com.sun.fortress.nodes.TypeInfo]))
}

The generated Java files look like so:

public class AnyType extends BaseType {
...
public abstract class BaseType extends Type {
...
public abstract class Type extends AbstractNode {
...
public abstract class AbstractNode extends UIDObject implements ASTNode {

I don't know enough Scala to make additional guesses about what is going on. I get the impression (this, from previously believing the error message and attempting to correct it by hand) that it has something to do with the definition of "Type"; that the plugin is not getting this correct, which then causes it to perceive an ambiguity where there is none.

I have spent quite a few hours trying to narrow this bug down; our project ([https://projectfortress.sun.com/Projects/Community Project Fortress]) previously was pretty easy to work on in Eclipse, and now it isn't. Because of this apparent bug in the plugin (and if it is not a bug in the plugin, it is a bug in the documentation, or something, because I cannot figure out what the heck is wrong) we no longer recommend Eclipse to Fortress users, though we do provide instructions, including instructions for filtering out the bogus and distracting "errors" reported by the Scala plugin.

scabug commented 15 years ago

Imported From: https://issues.scala-lang.org/browse/SI-1887?orig=1 Reporter: David Chase (dr2chase) Attachments:

scabug commented 15 years ago

David Chase (dr2chase) said: Whoops, files too big to attach (you want pictures of bad plugin behavior, you'll need to accommodate the pictures of what they do).

I put them up on the web, here:

The first shows the "first bug reported", and how a click on the bug with "Unknown" location actual gets you to a known source location. You'll notice lots of red marks, which tend to follow from instances of the first bug in the file. [http://homepage.mac.com/dr2chase/images/ScalaBug1.png]

This shows the first bug in the file, textually. [http://homepage.mac.com/dr2chase/images/ScalaBug3.png]

scabug commented 15 years ago

@milessabin said: It sounds like you're using the Scala IDE from trunk (which includes the trunk compiler and standard libraries) along with command line tools from an earlier release.

Whilst we try and avoid regressions on trunk, transient issues are inevitable as part of ongoing development.

In any case, I don't recommend mixing releases in this way. I suggest you switch to the just release 2.7.4.RC1 for both the command line tools and the Scala IDE.

I'm also puzzled to hear that you expect Fortess users to have the Scala IDE installed. Surely this is only required for Fortress developers? In which case, seeing as you say you're particularly familiar with Scala, it might be helpful to work with whoever is doing Fortress development with Scala to diagnose and/or resolve the Eclipse issues.

scabug commented 15 years ago

David Chase (dr2chase) said: No, no, you have it backwards. I have tried the following:

1) compiling from ant, using 2.7.2 Scala, our stuff. Works great.

2) compiling from ant, using 2.8.nightly Scala, our stuff. Works great.

3) compiling within Eclipse, using 2.7.3? plugin, our stuff. Spurious errors.

4) compiling withing Eclipse, using 2.8.nightly plugin, our stuff. Spurious errors.

What I've been trying to do, is see if the result comes from weird combinations of compiler/library versions that I am accidentally mixing, and to the best of my ability to separate them, it does not. I've also checked that I followed the Scala instructions for configuring projects, and to the best of my ability to follow and check my work, I have followed those instructions.

I am NOT, NOT, NOT at all skilled with Scala. (3 "nots" = "not", right?)

This is NOT, NOT, NOT a transient error. It is persistent, across versions of Scala, releases of the plugin, versions of Eclipse, and changes to our source base.

We don't require that our users install the Scala plugin, but those of us who work on Fortress from within Eclipse, are thinking about not using Eclipse anymore. It seemed to reasonable to complain for a while before quitting.

Another possible cause -- Eclipse is running under 1.5, the project is hosted under 1.6. Problem?

scabug commented 15 years ago

@milessabin said: There are no differences between the compiler and libraries in version x.y.z of the command line tools and version x.y.z of the Scala IDE.

So I you're not seeing those errors with the command line build then I think it must be a misconfiguration of your Eclipse environment.

Things to check ...

One final thing. You're describing the problem as though you don't have very much to do with the Scala side of things but are the innocent victim of an bad interaction between whoever does and the Scala IDE.

If that's the case, then I'd strongly recommend that you get that person to help deal with the issues ... esp. the scalac options and inter project references points above.

If, for whatever reason, that person doesn't want to have anything to do with Eclipse (crazy, I know, but it happens ;-) then I think you really should reconsider the choice of Eclipse at least for the Scala components.

And as I mentioned before: If you are able to extract out a minimal, reproducible test case, please pass it my way. As a PL developer yourself, I'm sure you appreciate that it's next to impossible to debug secondary issues in large established projects with complex setup requirements and many dependencies.

scabug commented 15 years ago

David Chase (dr2chase) said: A picture of the Scala compiler properties associated with this bug

scabug commented 15 years ago

David Chase (dr2chase) said: There are no interproject references, so that is not a problem.

You generally need to be more specific about the scalac options configured for Scala projects. Perhaps you are unaware of this, but the Eclipse UI is a maze of twisty passages, aka the Winchester Mystery UI (a house in Silicon Valley, continuously enhanced by the heir to the Winchester rifle fortune). I will look in the usual places, but I would not bet money that I had found all the knobs.

If there is a standard pile of information that you need for debugging problems, you ought to add a button for generating it in an easy to select/copy/paste form, or a standard file that people could attach. Eclipse, at least on a Mac, has not quite reached the current millennium in its implementation of select/copy/paste, so often, the most efficient way to get information out is to take "pictures" of windows. "Most efficient" is still plenty cumbersome, especially when the pictures exceed your attachment size limit.

I checked right-click-Project > Properties > Scala Compiler Properties to get. Looks like defaults to me.

[[Image(ScalaSettings.png)]]

I checked build.xml (also available at [https://projectfortress.sun.com/Projects/Community/browser/trunk/ProjectFortress/build.xml build.xml] ) , and it looks very ordinary to me, too:

  <target name="compileAll" depends="compileCommon, makeAST, parser, operatorsGen"
          description="Compile all Fortress code.">
    <scalac
        srcdir="${src}"
        destdir="${build}"
        classpathref="compile.classpath"
        deprecation="yes">
      <include name="**/*.java"/>
      <include name="**/*.scala"/>
      <exclude name="${usefulPackage}/*.java"/>
      <exclude name="${unicodePackage}/*.java"/>
    </scalac>
    <javac
        srcdir="${src}"
        destdir="${build}"
        debug="true"
        includeantruntime="false"
        fork="true"
        memorymaximumsize="${junitMem}">
      <!-- Uncomment the following line to print unchecked warnings
           (here and in the 'compileCommon' target. -->
      <!-- <compilerarg value="-Xlint:unchecked"/> -->
      <classpath refid="compile.classpath"/>
      <include name="**/*.java"/>
      <exclude name="${usefulPackage}/*.java"/>
      <exclude name="${unicodePackage}/*.java"/>
    </javac>
  </target>

And the Eclipse error log, would that be workspace/.metadata/.log ? I triggered a rebuild (Project > Clean...) and no new entries appeared.

I have a minor theory, and it is that there is something different about the search paths or scope being used to compile within Eclipse, vs outside. Superficially, the errors being reported are in fact correct, but they are not reported by the compiler, presumably because it has some additional disambiguating context (I am NOT a Scala expert). Is there any way to get at that information?

And barring that, are there any Scala plugins for any other IDEs that might work better?

scabug commented 15 years ago

@milessabin said: So it's a single scala project with no external dependencies?

scabug commented 15 years ago

David Chase (dr2chase) said: Yes. There are jar files and stuff, but no project dependencies.

Alternately, maybe you could download a prebuilt zip, and then try importing that into Eclipse.

[https://projectfortress.sun.com/Projects/Community/downloads/8 About 35 megabytes]

scabug commented 15 years ago

@milessabin said: I've checked out the trunk of your project from SVN into a fresh Scala IDE 2.7.4.RC1 with Eclipse 3.4.2. The Eclipse build does show errors.

However, once I'd removed the hard-coded reference to the 2.7.2 Scala compiler and libraries which are embedded in your project (see line 78 of ProjectFortress/build.xml pointing at the jars in ProjectFortress/third_party/scala) the command-line build fails in exactly the same way as the incremental build. This indicates that this is a scalac regression since 2.7.2 and not a Scala IDE problem.

As a workaround remove the "java.lang" prefixes from the uses of "java.lang.Object" in the Java source files indicated in the output from the command line build. Please use this as the basis for a minimal reproducible test case and attach it to a fresh ticket assigned to the Scala compiler component.

scabug commented 15 years ago

David Chase (dr2chase) said: Can you provide a few more breadcrumbs as to what you did, because I thought that I tried the experiment you describe (changing build.xml to refer to the plugin versions of the jars) and did not see what you say you saw. If I take the references to scala out of build.xml, it won't work -- I have to put something in its place, and what would that be?

And also:

"remove the "java.lang" prefixes from the uses of "java.lang.Object" in the Java source files indicated in the output from the command line build."

By this, do you mean the command line build that I will get once I make the changes to build.xml, as soon as I can figure out what changes you had in mind?

Just curious, but why do you think it is the best use of every one's time for ME to ineptly explain the problem that YOU understand to the Scala compiler team? Is this just a test to see if I think the problem is important enough to be worth reporting, and if I don't, then it must not be worth fixing? Because I am also a busy person, and I have already spent a fair amount of time on this, and I do not have any more time to spend this week, or even this weekend, and I am thinking about taking some vacation next week.

scabug commented 15 years ago

@milessabin said: Do a command line build with 2.7.4.RC1. If you do you'll see that if fails.

I really shouldn't have to tell you how to edit your own build files, but if you look you'll see that I even told you the line number you need to change.

scabug commented 15 years ago

David Chase (dr2chase) said: Interesting, but note that I am using plugin 2.8.0, and you are asking me to test against 2.7.4.

The problems that 2.7.4 generates, I do not see reported by the 2.8.0 plugin, anywhere in the list.

I did see them with past versions of the plugin, but that is one reason that I changed to the nightlies, to get away from that particular error (which seemed to cause more pervasive problems when attempting to run and/or refactor within Eclipse).

I recall that I was once-upon-a-time able to use the plugin versions of compiler and library to build our system, and did not see the errors there (so I recall); however, when I attempted to test this again, both with the current nightly plugin, and with a recent version of scala 2.8.0, ant failed quickly, like so:

BUILD FAILED
/Users/dr2chase/workspace/PFC/ProjectFortress/build.xml:192: The following error occurred while executing this line:
jar:file:/Users/dr2chase/workspace/PFC/ProjectFortress/third_party/scala/scala-compiler-2.8.0.jar!/scala/tools/ant/antlib.xml:5: taskdef A class needed by class scala.tools.ant.FastScalac cannot be found: scala/ScalaObject

I would like to again test a command line compilation against the 2.8.0 version of Scalac and library, so that I may do an actual apples-to-apples comparison of plugin and compiler. I would not want to waste the time of the compiler team having them fix a bug that does not matter to me.

Do you have any advice for how to run the 2.8.0 scalac as an ant task?

I am using these lines to do it so far, and that produces the error above:

  <property name="scala-compiler.jar"
            value="${basedir}/third_party/scala/scala-compiler-2.8.0.jar"/>
  <property name="scala-library.jar"
            value="${basedir}/third_party/scala/scala.library-2.8.0.jar"/>

And ant version

Apache Ant version 1.7.1 compiled on June 27 2008
scabug commented 15 years ago

David Chase (dr2chase) said: I did some additional research, and after replacing occurrences of java.lang.Object with Object (note that these are generated files, so this is not necessarily a fix that will stick) I successfully compiled the project from ant, using 2.7.4rc1.

However, when I cleaned the project within Eclipse (this should delete all the class files, and then recompile them, but not cause a regeneration of the generated files), the bugs remained on the Eclipse side.

I tried this twice, and obtained a workspace that would build clean from ant, but after multiple cleans and refreshes within Eclipse, still failed in the way described above.

I therefore think that this bug is not yet resolved. I am working on figuring out how to run 2.8.0 under ant, so that I may do an apples to apples comparison of command-line versus plugin.

scabug commented 15 years ago

David Chase (dr2chase) said: Kindly justify the reclosing. I did the research, your hypothesis for the bug cause did not seem to work.

scabug commented 15 years ago

@milessabin said: Don't reopen this ticket again. If you're not satisfied with what you've been given already then please feel free to use NetBeans.

scabug commented 15 years ago

David Chase (dr2chase) said: But the bug remains. I tested your hypothesis, and it did not work. The compiler errors were removed, but the plugin errors remained. Why should this bug not remain open?

scabug commented 15 years ago

David Chase (dr2chase) said: The bug is caused by the 2.8.0 release of the compiler, though I honestly cannot say if it is a compiler regression or a newly enforced rule. When I did get the 2.8.0 compiler running from the command line, it reproduced exactly the bugs I found in Eclipse. So, it is correct to close the bug for the reasons that you state -- except I am unwilling to commit that this is a bug in the compiler, until I can get someone who knows Scala well to look at the offending code.

The anomalous difficulty in running 2.8.0 within ant is caused by two things:

So, sloppily switching between 2.7.2 and 2.7.4 worked ok, and masked the two-files screwup, but half-switching to 2.8.0 did not. (that resolves that question.)

The behavior you observed with 2.7.4RC1 is apparently regarded as a feature, and is somehow triggered by us compiling things within the com.sun package, or so I am told by our Scala aficionados. However, this is not causing the problems that I observed within Eclipse. (that resolves THAT question.)

I am slightly sorry for my snarky tone; however the fact remains that just as bug reports should contain as much useful information as possible, responses to bug reports should be as unambiguous as possible, and I spent the earlier part of this week reporting bugs against Eclipse, and Eclipse does not make it especially easy to collect information for bug reports (did you know that it crashes every time I update the Scala plugin? Did you know that the dialog window presented with the crash contains a non-selectable picture of the text telling the non-standard location of the log file? You got pictures in your bug report, because that is the only way to get some of this information out of Eclipse.). In particular, if there's settings I need to look at, you need to tell me (and the next guy to report a bug) how to navigate to those settings, and if that is all the settings (you may notice, that after I complained about the lack of this information, I included a description of how I got to the data that I presented, on the off chance that I went to the wrong place). This is life with Eclipse. Ideally Eclipse would have a button I could push that would snapshot all the information into a complete and compact form for bug reporting, but they do not.

If you will note, I began with links, pictures, and all the information that seemed relevant to me, and pointers to specific files with specific revisions. If you think that my problem is pilot error, the last thing you want to give me is vague instructions as to how to proceed next. You know Scala and the plugin, I do not. If you speak in shorthand, I am likely to get it wrong, and that wastes everyone's time.

Thanks for your time.