New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Plugin reports errors not generated by compiler #1887
Comments
Imported From: https://issues.scala-lang.org/browse/SI-1887?orig=1
|
David Chase (dr2chase) said: 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. This shows the first bug in the file, textually. |
@milessabin said: 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. |
David Chase (dr2chase) said:
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? |
@milessabin said: 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. |
David Chase (dr2chase) said: |
David Chase (dr2chase) said: 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? |
@milessabin said: |
David Chase (dr2chase) said: 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] |
@milessabin said: 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. |
David Chase (dr2chase) said: 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. |
@milessabin said: 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. |
David Chase (dr2chase) said: 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 |
David Chase (dr2chase) said: 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. |
David Chase (dr2chase) said: |
@milessabin said: |
David Chase (dr2chase) said: |
David Chase (dr2chase) said: 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. |
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]
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):
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:
The generated Java files look like so:
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.
The text was updated successfully, but these errors were encountered: