#1000235
- Created on2011-02-10 09:59
- Reported by
- Worked hours2.0 hours
- StatusInvalid
- PriorityNormal (3)
- Assigned to
- Milestone
- Plan Level-
- Due Date-
Malicious Scala problem 'not found: type' for references to static protected inner classes defined in a parent class
When you inherit from a class that defines a protected static inner class and reference it as an argument type in a method defined in a derived type you get a Malicious Scala problem 'not found: type'.
To reproduce it open the attached project or follow the following steps:
0) create a Scala project (Java project with Scala nature, but you can also directly use create scala project)
1) create a base class (e.g.: test.innerclasses.Base)
2) create a protected static inner class (e.g.: test.innerclasses.Base.Innerclass)
3) create a derived class in another package (e.g.: test.innerclasses.concreet.Concreet) that extends your base class (e.g.: test.innerclasses.Base)
4) add a method foo() to the derived class that has an argument of the inner class defined in the base class (e.g.: test.innerclasses.concreet.Concreet.foo(Innerclass))
-> You get a Scala problem : Not found: type Innerclass -> this error isn't expected
Problem also occurs in Eclipse 3.5 and also with latest development snapshot of Scala plugins
To reproduce it open the attached project or follow the following steps:
0) create a Scala project (Java project with Scala nature, but you can also directly use create scala project)
1) create a base class (e.g.: test.innerclasses.Base)
2) create a protected static inner class (e.g.: test.innerclasses.Base.Innerclass)
3) create a derived class in another package (e.g.: test.innerclasses.concreet.Concreet) that extends your base class (e.g.: test.innerclasses.Base)
4) add a method foo() to the derived class that has an argument of the inner class defined in the base class (e.g.: test.innerclasses.concreet.Concreet.foo(Innerclass))
-> You get a Scala problem : Not found: type Innerclass -> this error isn't expected
Problem also occurs in Eclipse 3.5 and also with latest development snapshot of Scala plugins
Leave a comment
This is a generic Scala issue, you can reproduce it outside Eclipse using command line scalac.
Hmm, strange I can compile the project using scalac followed by javac in ant because scalac doesn't complain about the java source files.
Output of scalac called from ant:
foo:
[scalac] Compiling 0 scala and 2 java source files to c:\tmp
[javac] Compiling 2 source files to c:\tmp
BUILD SUCCESSFUL
Total time: 2 seconds
Output of scalac called from ant:
foo:
[scalac] Compiling 0 scala and 2 java source files to c:\tmp
[javac] Compiling 2 source files to c:\tmp
BUILD SUCCESSFUL
Total time: 2 seconds
on 2011-02-10 10:41 *
By
"Compiling 0 scala and 2 java source files to c:\tmp"? ... you're not actually compiling any Scala sources apparently.
Thank you very much for the quick responses.
But that's just the point. In the real project we have a lot of pure java classes that aren't toughed by scala. In a dozen of those pure java classes we get scala errors (which aren't used in scala).
We can't split up the project because most new development is in scala, some parts are also being rewritten in scala (before they were java). So it is a real hybrid project, and there are references in both directions (scala to/ and from java).
And the main problem is that it seems like the java compiler in eclipse bails out compiling due to the maliciouserrors reported by scala. I have to build everything using ant constantly, which is a pain.
Other people are working in InteliJ and they don't have any problems...
One work around would be, if I could add exclude patterns for the classes that have those problems (they aren't used in scala), but I don't think you are able to specify scala specific excludes...
But that's just the point. In the real project we have a lot of pure java classes that aren't toughed by scala. In a dozen of those pure java classes we get scala errors (which aren't used in scala).
We can't split up the project because most new development is in scala, some parts are also being rewritten in scala (before they were java). So it is a real hybrid project, and there are references in both directions (scala to/ and from java).
And the main problem is that it seems like the java compiler in eclipse bails out compiling due to the maliciouserrors reported by scala. I have to build everything using ant constantly, which is a pain.
Other people are working in InteliJ and they don't have any problems...
One work around would be, if I could add exclude patterns for the classes that have those problems (they aren't used in scala), but I don't think you are able to specify scala specific excludes...
on 2011-02-10 13:16 *
By
I understand the problem (and I'd like to see the issue resolved too), but you're reporting it in the wrong place ... this is a general Scala compiler bug, not something specific to the Scala tooling for Eclipse.
on 2011-02-10 13:41 *
By David Bernard
Assigned to changed from login to David Bernard
Status changed from New to Accepted
Work remaining changed from 0.0 to 2.0
I'll try to provide a workaround in wip_exp_backport : "option to not reporting error related to *.java"
on 2011-02-10 21:04 *
By David Bernard
(In revision:fb512823c3971a912790c4b6704509445a76e538) add options to not reporting scala compiler error detected into java files see #1000235
Branch:wip_exp_backport
Branch:wip_exp_backport
You can try the workaround (seems to work with the sample project you provide (thanks))
with the wip_exp_backport version (run on Galileo and Helios, update-site listed at http://download.scala-ide.org since 2011-02-11 (tonight nightly))
with the wip_exp_backport version (run on Galileo and Helios, update-site listed at http://download.scala-ide.org since 2011-02-11 (tonight nightly))
on 2011-02-11 10:11 *
By Iulian Dragos
@miles, this is not a scalac issue. There is not a single Scala source file there. In fact, I tried to pass those java source to scalac and they all pass with no error (2.8.1 and trunk, in all combinations possible -- all sources, or just one of them).
Moreover, it is not a presentation compiler issue either. The presentation compiler does not get any work item, it is completely silent. All you see is a confused JDT. Try completion and hyperlinking, they all work, and they come from the JDT. It may be some of the project properties that somehow confuse the JDT.
Moreover, removing the Scala nature does not fix this problem. Any ideas?
Moreover, it is not a presentation compiler issue either. The presentation compiler does not get any work item, it is completely silent. All you see is a confused JDT. Try completion and hyperlinking, they all work, and they come from the JDT. It may be some of the project properties that somehow confuse the JDT.
Moreover, removing the Scala nature does not fix this problem. Any ideas?
on 2011-02-11 10:33 *
By David Bernard
@Iulian
from the workaround I push yesterday, the error is reported by RefinedBuildManager.
from the workaround I push yesterday, the error is reported by RefinedBuildManager.
on 2011-02-11 10:39 *
By
@Iulian I'm pretty sure it is a scalac issue ... it might only reproducible via the refined build manager however.
on 2011-02-11 15:27 *
By Iulian Dragos
Miles, David, it's all clear now, thanks! It's indeed the build manager that's forcing those symbols.
on 2011-02-11 15:51 *
By Iulian Dragos
Here's a relevant link:
http://www.scala-lang.org/node/1381
And here's the ticket: http://lampsvn.epfl.ch/trac/scala/ticket/1806 (won't fix). Martin was vehemently against fixing this, so I'm afraid this is not going to be solved any time soon.
In the new light, masking such errors coming from Java sources seems the right way, but I'm afraid it won't help much once you have Scala sources trying to use that class.
http://www.scala-lang.org/node/1381
And here's the ticket: http://lampsvn.epfl.ch/trac/scala/ticket/1806 (won't fix). Martin was vehemently against fixing this, so I'm afraid this is not going to be solved any time soon.
In the new light, masking such errors coming from Java sources seems the right way, but I'm afraid it won't help much once you have Scala sources trying to use that class.
Hi David,
Thank you for the fix. I have quite positive news, all but one error is gone now. The only error that still exists in my real project is now reported on the project level with an unknown location (type: scala problem), and it reads:
Error in Scala compiler: assertion failed: fatal: Scope has owner constructor XBLBindings$ConcreteBinding, but a class owner is required
It is also in a pure Java file, but I have no clue what the error means. My scala knowledge is currently quite limited and I'm not sure if and how I can make work around this problem by maybe changing the source code.
Thank you for the fix. I have quite positive news, all but one error is gone now. The only error that still exists in my real project is now reported on the project level with an unknown location (type: scala problem), and it reads:
Error in Scala compiler: assertion failed: fatal: Scope has owner constructor XBLBindings$ConcreteBinding, but a class owner is required
It is also in a pure Java file, but I have no clue what the error means. My scala knowledge is currently quite limited and I'm not sure if and how I can make work around this problem by maybe changing the source code.
Updating tickets (#1000199, #1000200, #1000201, #1000204, #1000205, #1000209, #1000210, #1000211, #1000212, #1000215, #1000217, #1000218, #1000220, #1000222, #1000226, #1000227, #1000228, #1000230, #1000231, #1000232, #1000233, #1000235, #1000236, #1000237, #1000239, #1000240, #1000241, #1000242, #1000243, #1000244, #1000248, #1000249, #1000252, #1000253, #1000254, #1000255, #1000256, #1000258, #1000259, #1000032, #1000059, #1000062, #1000163, #1000197, #1000216, #1000221, #1000224, #1000121, #1000175, #1000219, #1000251, #1000069, #1000195, #1000213, #1000223, #1000006, #1000021, #1000038, #1000048, #1000051, #1000052, #1000075, #1000103, #1000109, #1000115, #1000119, #1000156, #1000186, #1000207, #1000238, #1000262, #1000263, #380, #389, #683, #1238, #1331, #1635, #1645, #1715, #1729, #1744, #1783, #1839, #1869, #1885, #1890, #1902, #1918, #1919, #1924, #1925, #1946, #1964, #1991, #2131, #2233, #2342, #2348, #2408)
