Some of my Scala files have lines marked as errors despite being valid Scala code
Migrated from http://lampsvn.epfl.ch/trac/scala/ticket/2767
Reporter newhoggy
To reproduce, please install Scala plugin and subclipse plugin and import the source code from https://asn1gen.googlecode.com/svn/trunk/asn1gen as an eclipse project.
Then open the file asn1gen/src/org.asn1gen.parsing.asn1.Asn1ParserBase.scala
Here, I get a lot of "not found" and "not a member" errors.
This is despite the fact that whole project builds fine and the corresponding unit tests at https://asn1gen.googlecode.com/svn/trunk/asn1gentest all pass.
Reporter newhoggy
To reproduce, please install Scala plugin and subclipse plugin and import the source code from https://asn1gen.googlecode.com/svn/trunk/asn1gen as an eclipse project.
Then open the file asn1gen/src/org.asn1gen.parsing.asn1.Asn1ParserBase.scala
Here, I get a lot of "not found" and "not a member" errors.
This is despite the fact that whole project builds fine and the corresponding unit tests at https://asn1gen.googlecode.com/svn/trunk/asn1gentest all pass.
Leave a comment
on 2009-12-05 20:44 *
By tracImporter
Trac author: spiros
CC Change: sptz45@…
Which version of the plug-in are you using?
If you are using 2.7.x, is this bug the same as #1277?
CC Change: sptz45@…
Which version of the plug-in are you using?
If you are using 2.7.x, is this bug the same as #1277?
on 2009-12-06 00:57 *
By tracImporter
Trac author: newhoggy
I was using a nightly build downloaded about the same time I made this ticket.
I was using a nightly build downloaded about the same time I made this ticket.
on 2009-12-06 01:16 *
By tracImporter
Trac author: newhoggy
Scala Eclipse Plugin 2.8.0.r19928-b20091129034731 ch.epfl.lamp.sdt.feature.group
Scala Eclipse Plugin 2.8.0.r19928-b20091129034731 ch.epfl.lamp.sdt.feature.group
on 2009-12-06 13:03 *
By tracImporter
Trac author: spiros
I just did a svn checkout of you project and I see no errors in the file Asn1ParserBase.scala. Do those errors appear after a Clean and auto-build? If this is the case then this is probably a duplicate of #2689.
BTW thank you for you interest in improving SDT by submitting a bug report. Bug reports are always helpful, but they are more helpful if they provide a specific way to reproduce the bug using a small self-contained code example. For example see #2689, the code provided is minimal and has no dependencies so the developers can easily see the problem or use the provided code in a test case.
It would be extremely helpful, if this bug is not a duplicate of #2689, if you could find the smallest example that reproduces the misbehavior that you have observed.
I just did a svn checkout of you project and I see no errors in the file Asn1ParserBase.scala. Do those errors appear after a Clean and auto-build? If this is the case then this is probably a duplicate of #2689.
BTW thank you for you interest in improving SDT by submitting a bug report. Bug reports are always helpful, but they are more helpful if they provide a specific way to reproduce the bug using a small self-contained code example. For example see #2689, the code provided is minimal and has no dependencies so the developers can easily see the problem or use the provided code in a test case.
It would be extremely helpful, if this bug is not a duplicate of #2689, if you could find the smallest example that reproduces the misbehavior that you have observed.
on 2009-12-07 07:59 *
By tracImporter
Trac author: newhoggy
The errors go away if I simplify it too much.
I've got a screencast showing the errors I am getting with a slightly more simplified class, but I think it must be part of the project.
http://www.screencast.com/users/newhoggy/folders/Jing/media/cc7e1259-b0af-4175-9e5b-857a0a3d53f0 Let me know if there is anything else I can provide to help diagnose the problem.
The errors go away if I simplify it too much.
I've got a screencast showing the errors I am getting with a slightly more simplified class, but I think it must be part of the project.
http://www.screencast.com/users/newhoggy/folders/Jing/media/cc7e1259-b0af-4175-9e5b-857a0a3d53f0 Let me know if there is anything else I can provide to help diagnose the problem.
on 2009-12-07 11:40 *
By tracImporter
on 2009-12-07 12:47 *
By tracImporter
Trac author: newhoggy
Yes, it does appear after a clean operation. I didn't notice it had to do with the clean operation because clean & build is how I've been working for a while now. I find clean & build is more stable and avoid the automatic build because the atomic build occasionally gets into a 100% cpu state and wastes away my battery while I'm working on the train.
Yes, it does appear after a clean operation. I didn't notice it had to do with the clean operation because clean & build is how I've been working for a while now. I find clean & build is more stable and avoid the automatic build because the atomic build occasionally gets into a 100% cpu state and wastes away my battery while I'm working on the train.
on 2010-01-09 23:45 *
By
I'd be very grateful if someone could review this ticket against the current state of trunk.
on 2010-01-10 02:08 *
By tracImporter
Trac author: newhoggy
I must say, you did an excellent job of it. I don't see any erroneous errors anymore.
I must say, you did an excellent job of it. I don't see any erroneous errors anymore.
on 2010-01-10 03:49 *
By tracImporter
Trac author: spiros
Unfortunately I still see bogus error messages when I do a Clean&Build in some of my projects.
Unfortunately I still see bogus error messages when I do a Clean&Build in some of my projects.
on 2010-01-10 03:50 *
By tracImporter
Trac author: spiros
BTW I am using r20428.
BTW I am using r20428.
on 2010-01-10 10:19 *
By tracImporter
Trac author: newhoggy
You're right. I still get some, but way fewer than before.
For some reason, it doesn't like:
case NULL => {
NULL and ValueReference.
case lexical.Operator(
case lexical.CommentLit(n) => n
I'm using r20423
You're right. I still get some, but way fewer than before.
For some reason, it doesn't like:
case NULL => {
NULL and ValueReference.
case lexical.Operator(
chars) => Operator(chars)case lexical.CommentLit(n) => n
I'm using r20423
on 2010-01-10 10:58 *
By
Small self-contained examples would be very helpful (though I would expect it will take more than one source file to exhibit any problems).
on 2010-01-11 01:33 *
By tracImporter
Trac author: spiros
See also: #2889.
See also: #2889.
on 2010-01-14 16:43 *
By tracImporter
Trac author: spiros
Hi Miles,
any compiler related fix is more than welcome, I am looking forward to test the next nightly.
Replying to milessabin:
#2889 is now fixed, so I'd be grateful for another review of this ticket ... unfortunately I'm not expecting this one to be fixed.
Hi Miles,
any compiler related fix is more than welcome, I am looking forward to test the next nightly.
Replying to milessabin:
#2889 is now fixed, so I'd be grateful for another review of this ticket ... unfortunately I'm not expecting this one to be fixed.
on 2010-01-15 15:28 *
By tracImporter
Trac author: spiros
I tried to find a small example that reproduces this bug but unfortunately I cannot reproduce it in a small project. This bug is still valid (using r20518) but appears less frequently.
I tried to find a small example that reproduces this bug but unfortunately I cannot reproduce it in a small project. This bug is still valid (using r20518) but appears less frequently.
on 2010-01-15 17:44 *
By
Well, I guess that's progress of a sort. Thanks for your efforts, and if you do come up with any more reproducible examples they'd be extremely welcome.
on 2010-01-16 13:29 *
By tracImporter
Trac author: spiros
Hi Miles,
the below code gives a bogus error message in the Scala editor:
Sorry for the external dependency to JPA but this does not work if the annotation and the enum are defined in the same project as the User class (maybe due to a compiler bug, I'll file another bug report).
Hi Miles,
the below code gives a bogus error message in the Scala editor:
package test
import javax.persistence._
class User {
@Temporal(TemporalType.TIMESTAMP)
var lastLogin: java.util.Date = _
}Sorry for the external dependency to JPA but this does not work if the annotation and the enum are defined in the same project as the User class (maybe due to a compiler bug, I'll file another bug report).
on 2010-01-16 13:55 *
By tracImporter
Trac author: spiros
Thanks for the heads up! I was just writing a duplicate bug report of #2764.
If the Java annotation, Java enum and the Scala class are in the same project then we get the compiler bug and Eclipse correctly reports this error in both the editor and the problems view (Eclipse does not know that the compiler has a bug).
In the case that I wrote in my comment the code compiles and runs so the error is bogus since compilation completed successfully. The problem with Eclipse here is that an error that produced during compilation and was later (during compilation) removed is shown in the Scala editor.
Thanks for the heads up! I was just writing a duplicate bug report of #2764.
If the Java annotation, Java enum and the Scala class are in the same project then we get the compiler bug and Eclipse correctly reports this error in both the editor and the problems view (Eclipse does not know that the compiler has a bug).
In the case that I wrote in my comment the code compiles and runs so the error is bogus since compilation completed successfully. The problem with Eclipse here is that an error that produced during compilation and was later (during compilation) removed is shown in the Scala editor.
on 2010-01-16 14:01 *
By tracImporter
Trac author: spiros
Your message in the scala-tools mailing list is my guide for researching this issue. You said:
...or where early compilation failures have prevented otherwise good code
from being built which then has knock on effects on code which depends on
it (sounds like what you're experiencing).
and I believe that since the code gets compiled this might be an instance of this behavior.
Your message in the scala-tools mailing list is my guide for researching this issue. You said:
...or where early compilation failures have prevented otherwise good code
from being built which then has knock on effects on code which depends on
it (sounds like what you're experiencing).
and I believe that since the code gets compiled this might be an instance of this behavior.
on 2010-01-16 14:04 *
By tracImporter
Trac author: spiros
From #2764 "it works when compiling against the compiled java files" which is the case in my submitted example (since the annotation and the enum are in the JPA jar).
From #2764 "it works when compiling against the compiled java files" which is the case in my submitted example (since the annotation and the enum are in the JPA jar).
on 2010-01-16 14:32 *
By
Do you have a source attachment for the JPA jar? If you do, could you remove it and then try reproducing the bogus error.
on 2010-01-16 14:45 *
By tracImporter
Trac author: spiros
I can reproduce this in a Maven project with the JPA sources attached and in a plain Scala project without the sources attached. There is no difference. Do you have any problem reproducing the error?
I can reproduce this in a Maven project with the JPA sources attached and in a plain Scala project without the sources attached. There is no difference. Do you have any problem reproducing the error?
on 2010-01-16 15:32 *
By tracImporter
Trac author: spiros
The code gets compiled so I do not expect to see any error messages. Also the error message appears in the Scala editor but not in the Problems View (which is a sign that the error message is bogus).
The code gets compiled so I do not expect to see any error messages. Also the error message appears in the Scala editor but not in the Problems View (which is a sign that the error message is bogus).
on 2010-01-16 16:13 *
By tracImporter
Trac author: spiros
On bug #2764 The creator of the bug said that the attached Scala file (which is the same as the example that I used in my comment) produces a compilation error but the code runs (so it compiles). I believe that he was seeing a bogus message (not reported in the Problems View). The message must be bogus since the he said that the code runs. If we get a compilation error we cannot run the code.
Then when you tried to minimize the dependencies of the example code you found the real bug with the code that you wrote in your first comment. In this comment the annotation, enum and Scala class are defined (and hence compiled) in the same project so the compiler bug get triggered (Eclipse here correctly reports the compilation error which is result of the bug since it does not know that the compiler has a bug). In this case you cannot run the code and hence the compilation error in valid (although the result of a compiler bug).
I expect the code that uses the JPA annotations not to produce any errors because as rytz said in a later comment of #2764 "it works when compiling against the compiled java files" which is the case with JPA since the annotation and the enum are compiled in the JPA jar. Also when we compile from the command line we do not get any compiler messages.
On bug #2764 The creator of the bug said that the attached Scala file (which is the same as the example that I used in my comment) produces a compilation error but the code runs (so it compiles). I believe that he was seeing a bogus message (not reported in the Problems View). The message must be bogus since the he said that the code runs. If we get a compilation error we cannot run the code.
Then when you tried to minimize the dependencies of the example code you found the real bug with the code that you wrote in your first comment. In this comment the annotation, enum and Scala class are defined (and hence compiled) in the same project so the compiler bug get triggered (Eclipse here correctly reports the compilation error which is result of the bug since it does not know that the compiler has a bug). In this case you cannot run the code and hence the compilation error in valid (although the result of a compiler bug).
I expect the code that uses the JPA annotations not to produce any errors because as rytz said in a later comment of #2764 "it works when compiling against the compiled java files" which is the case with JPA since the annotation and the enum are compiled in the JPA jar. Also when we compile from the command line we do not get any compiler messages.
on 2010-01-16 17:05 *
By
Understood. But I still don't see the Eclipse issue here: the difference in behaviour is due to the presentation compiler using source if available whereas the build compiler only ever uses the binaries and the compiler bug only affecting the source path. I think that if the compiler bug is fixed the issue in this particular example goes away.
The foregoing is assuming that you do have source in this case ... hence my earlier question about source attachments.
The foregoing is assuming that you do have source in this case ... hence my earlier question about source attachments.
on 2010-01-16 18:11 *
By tracImporter
Trac author: spiros
Why the error only appears in the Scala editor and not in the Problems View?
Why the error only appears in the Scala editor and not in the Problems View?
on 2010-01-17 08:07 *
By tracImporter
Trac author: spiros
OK understood, but as I've said in an earlier comment I get the same behavior in a project that does not have the JPA sources attached. How does #2767 gets triggered by the presentation compiler in this case?
OK understood, but as I've said in an earlier comment I get the same behavior in a project that does not have the JPA sources attached. How does #2767 gets triggered by the presentation compiler in this case?
on 2010-01-18 05:36 *
By tracImporter
Trac author: shaberman
CC Change: stephen@…
CC Change: stephen@…
on 2010-01-18 07:57 *
By tracImporter
Trac author: newhoggy
This is actually quite challenging to reproduce in a small project.
This is actually quite challenging to reproduce in a small project.
on 2010-01-18 12:27 *
By tracImporter
Trac author: spiros
Another example where consistently the presentation compiler reports bogus errors is for classes that have been defined in files with names that differ from their class names.
When I use those classes, in other files, I get a lot of "not found type: MyClass" messages.
I see this in almost every project but unfortunately I have not being able to reproduce it in a trivial (1-5 files) project.
Another example where consistently the presentation compiler reports bogus errors is for classes that have been defined in files with names that differ from their class names.
When I use those classes, in other files, I get a lot of "not found type: MyClass" messages.
I see this in almost every project but unfortunately I have not being able to reproduce it in a trivial (1-5 files) project.
on 2010-01-18 12:38 *
By
Do those bogus errors go away if you have the source file containing the type the error is reported against open?
on 2010-01-18 12:47 *
By tracImporter
Trac author: spiros
No
No
on 2010-01-18 12:49 *
By tracImporter
Trac author: spiros
To remove the message I have to rename the file that defines the class and then go to the file that uses the class do an edit and save it to compile.
To remove the message I have to rename the file that defines the class and then go to the file that uses the class do an edit and save it to compile.
on 2010-01-19 20:57 *
By tracImporter
Trac author: ijuma
CC Change: mlists@…
CC Change: mlists@…
on 2010-01-20 16:45 *
By tracImporter
Trac author: razie
Attachment: file:ScalaFail.zip
sample of error described in forum http://old.nabble.com/It's-fast-now!-It's-fast-now!-td27230437.html#a27244656
Attachment: file:ScalaFail.zip
sample of error described in forum http://old.nabble.com/It's-fast-now!-It's-fast-now!-td27230437.html#a27244656
on 2010-01-22 17:57 *
By
I'd very much appreciate people checking their problematic projects and confirm or deny my suspicion that almost all of the spurious errors they're seeing relate to (incorrectly reported non-definition of) case classes/objects or the very immediate consequences thereof.
If you could do that both before and after [20634] that would be extremely helpful ... post [20634] things are looking pretty good to me (although not yet perfect).
If you could do that both before and after [20634] that would be extremely helpful ... post [20634] things are looking pretty good to me (although not yet perfect).
on 2010-01-23 14:25 *
By tracImporter
Trac author: spiros
I am using r20638 and I still see bogus errors when I am using classes that have been defined in files with names that differ from their class names.
I am using r20638 and I still see bogus errors when I am using classes that have been defined in files with names that differ from their class names.
on 2010-01-24 02:04 *
By tracImporter
Trac author: newhoggy
Attachment: file:Screen_shot_2010-01-24_at_1.00.00_PM.png
Screen capture of some errors in r0638
Attachment: file:Screen_shot_2010-01-24_at_1.00.00_PM.png
Screen capture of some errors in r0638
on 2010-01-24 02:10 *
By tracImporter
Trac author: newhoggy
Attachment: file:Screen_shot_2010-01-24_at_1.09.39_PM.png
Screen capture of some errors in r0638
Attachment: file:Screen_shot_2010-01-24_at_1.09.39_PM.png
Screen capture of some errors in r0638
on 2010-01-25 08:49 *
By
Do you have Project => Build Automatically enabled? If not, could you enable it and let me know if that reduces the number of bogus errors you're seeing.
on 2010-01-25 17:06 *
By tracImporter
Trac author: spiros
Replying to milessabin:
Do you have Project => Build Automatically enabled? If not, could you enable it and let me know if that reduces the number of bogus errors you're seeing.
When this bug was first opened the only way to trigger it was to do clean with a subsequent build. Also the bogus errors wouldn't go away with any form of compilation. You needed to close and reopen your projects (and sometimes even then they persisted) in order to have them removed.
During the last couple of weeks things have changed and we also get bogus error messages after incremental compilation (via save). Those error messages disappear after an incremental compilation and they appear again after a clean&build or they might appear again after an incremental build.
For example in a non trivial project we might have a file called exceptions.scala that has the BadInputException defined. When in another file we use the BadInputException and save it to compile we will get a bogus error messages saying: "not found: type BadInputException". If we edit that file and save it again the bogus error message will disappear. Subsequent incremental recompilations of that file might trigger the bug again and make the bogus error message appear but this does not happen 100% of the time. What always triggers this bug is a Clean&Build, if we do a Clean&Build the bogus error message always appears.
Replying to milessabin:
Do you have Project => Build Automatically enabled? If not, could you enable it and let me know if that reduces the number of bogus errors you're seeing.
When this bug was first opened the only way to trigger it was to do clean with a subsequent build. Also the bogus errors wouldn't go away with any form of compilation. You needed to close and reopen your projects (and sometimes even then they persisted) in order to have them removed.
During the last couple of weeks things have changed and we also get bogus error messages after incremental compilation (via save). Those error messages disappear after an incremental compilation and they appear again after a clean&build or they might appear again after an incremental build.
For example in a non trivial project we might have a file called exceptions.scala that has the BadInputException defined. When in another file we use the BadInputException and save it to compile we will get a bogus error messages saying: "not found: type BadInputException". If we edit that file and save it again the bogus error message will disappear. Subsequent incremental recompilations of that file might trigger the bug again and make the bogus error message appear but this does not happen 100% of the time. What always triggers this bug is a Clean&Build, if we do a Clean&Build the bogus error message always appears.
on 2010-01-25 17:34 *
By
Thanks, but that doesn't answer my question ;-)
I suspect that the fix for #2931 will have improved the situation for this ticket as well, but there are still likely to be issues in the presentation compiler with types which are contained in source files which aren't named for the type.
If automatic building is enabled, then the class file generated for such a type will provide a reference back to the source file it was built from irrespective of the source file name. But if there's no class file there's no way (currently) for the presentation compiler to locate the source file for a given type (unless it already knows about it because that type's source file is open in an editor).
Hopefully that gives you some context for my previous request ...
I suspect that the fix for #2931 will have improved the situation for this ticket as well, but there are still likely to be issues in the presentation compiler with types which are contained in source files which aren't named for the type.
If automatic building is enabled, then the class file generated for such a type will provide a reference back to the source file it was built from irrespective of the source file name. But if there's no class file there's no way (currently) for the presentation compiler to locate the source file for a given type (unless it already knows about it because that type's source file is open in an editor).
Hopefully that gives you some context for my previous request ...
on 2010-01-25 17:56 *
By tracImporter
Trac author: spiros
I always have automatic building enabled.
I always have automatic building enabled.
on 2010-01-25 18:19 *
By tracImporter
Trac author: spiros
Replying to milessabin:
OK, thanks. If you could let me know if [20660] has improved things for you that would be very helpful.
Of course I will!
I just hope that the nightly build won't be broken again so I can update tomorrow morning (last success was 2 days 17 hr ago).
Replying to milessabin:
OK, thanks. If you could let me know if [20660] has improved things for you that would be very helpful.
Of course I will!
I just hope that the nightly build won't be broken again so I can update tomorrow morning (last success was 2 days 17 hr ago).
on 2010-01-25 18:22 *
By
There shouldn't be anything wrong with the nightlies. Do you run Eclipse with the -clean option? Either way, try uninstalling and reinstalling.
on 2010-01-25 18:23 *
By tracImporter
Trac author: ijuma
There is a stability error (see scala-internals) and that's why we haven't had nightlies for the last few days.
There is a stability error (see scala-internals) and that's why we haven't had nightlies for the last few days.
on 2010-01-25 18:32 *
By tracImporter
Trac author: spiros
Replying to ijuma:
There is a stability error (see scala-internals) and that's why we haven't had nightlies for the last few days.
Yeap! If I am correct there are some scaladoc errors that prevent the build to succeed so the update site does not get updated.
Replying to ijuma:
There is a stability error (see scala-internals) and that's why we haven't had nightlies for the last few days.
Yeap! If I am correct there are some scaladoc errors that prevent the build to succeed so the update site does not get updated.
on 2010-01-25 18:58 *
By tracImporter
Trac author: ijuma
I am not aware of scaladoc problems, but the stability issue has been fixed by Martin just now (by "stability", I the test.stability ant target).
I am not aware of scaladoc problems, but the stability issue has been fixed by Martin just now (by "stability", I the test.stability ant target).
on 2010-01-25 19:32 *
By tracImporter
Trac author: spiros
Replying to ijuma:
I am not aware of scaladoc problems, but the stability issue has been fixed by Martin just now (by "stability", I the test.stability ant target).
Sorry my mistake :-(
I quickly saw the console output from hudson and thought it was a scaladoc problem. Good to know that the problem is fixed.
Replying to ijuma:
I am not aware of scaladoc problems, but the stability issue has been fixed by Martin just now (by "stability", I the test.stability ant target).
Sorry my mistake :-(
I quickly saw the console output from hudson and thought it was a scaladoc problem. Good to know that the problem is fixed.
on 2010-01-26 10:53 *
By tracImporter
Trac author: spiros
I've tested this with r20669 and unfortunately the bug is still valid. So far I've seen exactly the same behavior.
I've tested this with r20669 and unfortunately the bug is still valid. So far I've seen exactly the same behavior.
on 2010-01-26 12:30 *
By
I now have a minimal reproducer ...
A.scala
Note that in the both the error and the non-error case the presentation compiler might need a little nudge to exhibit the behaviour as described (e.g to make the incorrect error go away by opening A.scala you might also need to make a single character edit to B.scala; to make the error reappear you might need to reinstantiate the presentation compiler by doing a clean).
I think that this example probably covers all the remaining cases of this ticket, so if you're seeing incorrect behaviour which is clearly different from the incorrect behaviour I've just described, then please let me know.
A.scala
object Misnamedobject B {
val a = Misnamed
}- A.scala is open in an editor
- There is a class file for object Misnamed
Note that in the both the error and the non-error case the presentation compiler might need a little nudge to exhibit the behaviour as described (e.g to make the incorrect error go away by opening A.scala you might also need to make a single character edit to B.scala; to make the error reappear you might need to reinstantiate the presentation compiler by doing a clean).
I think that this example probably covers all the remaining cases of this ticket, so if you're seeing incorrect behaviour which is clearly different from the incorrect behaviour I've just described, then please let me know.
on 2010-01-26 13:25 *
By tracImporter
Trac author: spiros
I see a different behavior.
I have a small 58 file project. In that project almost all of the classes are placed in files that correspond to their class names except for one exception which is placed in a file called exceptions.scala. In that project when I do a Clean&Build I get the bogus errors despite exceptions.scala being open and .class file being present in the hard disk. Closing the file and reopening it does not remove the errors. To remove them I have to edit the file and save it.
From my testing so far, what appears to have changed in the recent nightly is that we don't longer get bogus error messages for incremental compilation. Now to trigger the bug we need to do a clean.
BTW I can privately share two projects that have this behavior. They are 25 and 58 files and they only depend on JUnit. I've tried to trimmed them down to a 5 files project but the errors disappear. If you want I can send them via email.
I see a different behavior.
I have a small 58 file project. In that project almost all of the classes are placed in files that correspond to their class names except for one exception which is placed in a file called exceptions.scala. In that project when I do a Clean&Build I get the bogus errors despite exceptions.scala being open and .class file being present in the hard disk. Closing the file and reopening it does not remove the errors. To remove them I have to edit the file and save it.
From my testing so far, what appears to have changed in the recent nightly is that we don't longer get bogus error messages for incremental compilation. Now to trigger the bug we need to do a clean.
BTW I can privately share two projects that have this behavior. They are 25 and 58 files and they only depend on JUnit. I've tried to trimmed them down to a 5 files project but the errors disappear. If you want I can send them via email.
on 2010-01-26 13:31 *
By
Yes, if you could send me the smaller of the two projects that would be very helpful.
on 2010-01-27 15:18 *
By tracImporter
Trac author: spiros
BTW the bug #2710 might be related to this bug.
BTW the bug #2710 might be related to this bug.
on 2010-01-27 16:22 *
By
I must be missing some connection that you see ... why do you think they're related?
on 2010-01-27 16:47 *
By tracImporter
Trac author: spiros
You are right, I didn't mean to imply that there in a common underlining cause for the two bugs. My reasoning is that since they both happen after a clean and since (if I am correct) the task items are added by the presentation compiler there might be various inconsistencies that happen in the state of the presentation compiler after a clean operation.
Related in my previous comment meant that the fix for #2710 and the fix this bug might be in the same area so #2710 might be a good bug to tackle after this one.
You are right, I didn't mean to imply that there in a common underlining cause for the two bugs. My reasoning is that since they both happen after a clean and since (if I am correct) the task items are added by the presentation compiler there might be various inconsistencies that happen in the state of the presentation compiler after a clean operation.
Related in my previous comment meant that the fix for #2710 and the fix this bug might be in the same area so #2710 might be a good bug to tackle after this one.
on 2010-01-27 17:05 *
By
Actually, task items are added by the build compiler.
on 2010-01-27 17:50 *
By tracImporter
Trac author: spiros
I am obviously wrong, sorry for the noise.
I am obviously wrong, sorry for the noise.
on 2010-02-01 00:38 *
By tracImporter
Trac author: bjackman
CC Change: ben@…
CC Change: ben@…
on 2010-02-09 00:48 *
By
I finally have a fix for this ... a little tidying up to do before I commit, but it'll be going in tomorrow.
Fixed in [20835] and [20839].
The IDE now maintains a map from top-level symbols to source files, and uses this to add additional compilation units to the presentation compiler run to resolve symbols which can't be resolved via the Java source naming convention.
Building the map requires parsing the sources to extract top-level symbols. This adds a (small) one-time overhead the first time a project is touched after a restart or a clean, and a (very small) overhead on each source file save. I think this overhead is acceptable (4s for the initial whole-project scan for the scala project, 10s of ms for single file scans), but if that turns out not to be the case it should be possible to persist some or all of the map across restarts and cleans.
I believe that this fixes all of the issues mentioned in this ticket so far. However, there might be further cases where the presentation compiler reports spurious errors. Please use your judgement when deciding whether to reopen this ticket or create a fresh one: if you have a very specific, easily reproducible example, then a fresh ticket would be appropriate.
The IDE now maintains a map from top-level symbols to source files, and uses this to add additional compilation units to the presentation compiler run to resolve symbols which can't be resolved via the Java source naming convention.
Building the map requires parsing the sources to extract top-level symbols. This adds a (small) one-time overhead the first time a project is touched after a restart or a clean, and a (very small) overhead on each source file save. I think this overhead is acceptable (4s for the initial whole-project scan for the scala project, 10s of ms for single file scans), but if that turns out not to be the case it should be possible to persist some or all of the map across restarts and cleans.
I believe that this fixes all of the issues mentioned in this ticket so far. However, there might be further cases where the presentation compiler reports spurious errors. Please use your judgement when deciding whether to reopen this ticket or create a fresh one: if you have a very specific, easily reproducible example, then a fresh ticket would be appropriate.
Trac author: spiros
I am using r20847 and I still see spurious errors :-(
From my testing so far the errors are greatly reduced but they still exist. At first I thought that the errors were only for packages and package objects but I also saw an error for an object. I will investigate this further and try to report specific ways to reproduce.
All the errors are for Scala top level elements that are defined in files that do not correspond to their qualified names that is why I reopen this issue instead of a new one.
I am using r20847 and I still see spurious errors :-(
From my testing so far the errors are greatly reduced but they still exist. At first I thought that the errors were only for packages and package objects but I also saw an error for an object. I will investigate this further and try to report specific ways to reproduce.
All the errors are for Scala top level elements that are defined in files that do not correspond to their qualified names that is why I reopen this issue instead of a new one.
on 2010-02-19 21:31 *
By
Have you had any luck finding new reproducible examples of this? I'm not seeing anything ...
on 2010-02-19 22:16 *
By tracImporter
Trac author: spiros
I sent you via email instructions on how to reproduce this error using the second project that I've emailed you in past. Have you tried using those instructions?
I am using r20879 and I definitely see spurious errors. If you cannot reproduce this bug using the instructions in my email please let me know and I'll try to come up with another example.
I sent you via email instructions on how to reproduce this error using the second project that I've emailed you in past. Have you tried using those instructions?
I am using r20879 and I definitely see spurious errors. If you cannot reproduce this bug using the instructions in my email please let me know and I'll try to come up with another example.
on 2010-02-23 22:01 *
By tracImporter
Closed As: fixed