Bugzilla – Full Text Bug Listing
| Summary: | cannot be resolved to type errors with cross-package artifacts | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Stephen Haberman <stephen> |
| Component: | APT | Assignee: | Generic inbox for the JDT-APT component <jdt-apt-inbox> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | eclipse, rnideffer |
| Version: | 3.6 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | stalebug | ||
I can see that it might be a challenge for the typesystem; to scan the public methods of One it needs to know something about ITwo, and if it hasn't generated ITwo yet that'll be an error type. The compiler does figure out dependencies among "normal" types but it doesn't have any way of knowing what types a processor may generate (after all, you could just as easily write a processor that generated ITwo from processing One, and IOne from Two), so there's no way for it to know that it needs to process Two before it can correctly process One. But I'll try to take a look in more detail. Thanks for the clear description! I have (I believe) the same problem. I am referencing a class defined in Project A from a class in Project B, and I have errors on both the import and the usage, however using F3 to open the definition of the class works fine, so obviously part of the tooling is able to resolve the type. (In reply to comment #2) > I have (I believe) the same problem. I am referencing a class defined in > Project A from a class in Project B, and I have errors on both the import and > the usage, however using F3 to open the definition of the class works fine, so > obviously part of the tooling is able to resolve the type. This probably has a simpler explanation. F3 relies on the indexer, which does not trouble itself with whether a type is actually visible in a particular context. You probably have a classpath issue in project B (or else project A is not exporting the class) that is causing the class to not be visible. If you're unable to get it to work on your own, try posting a question to eclipse.tools.jdt and we'll see if we can help you out. Just thinking out loud, but is there a way classes generated by each round could be "batch" compiled at the end of the round? The error I'm getting, "Xxx cannot be resolved to a type", seems like the sort of problem Java can usually compile easily--if class A depends on class B, they can be compiled at the same time as long as they're both on the source path. I'm making a large assumption, but it seems like APT is trying to compile each class as soon as I generate it. If it could group all of the classes generated from each round, and then do one compile at the end of the round, couldn't the class A/class B types then resolve nicely just as they would if they had not been generated? Hm. javac is exhibiting the same behavior. My compile-at-end-of-round idea was wrong. It turns out the error is while I'm generating, say, class A, and it has an "import b.B" and later a method parameter of just "B". In the generated file, I need to know the full time of B, but asking either Eclipse or javac returns an error type. If I don't use an import in class A and just explicitly say "b.B" as the type of the parameter, javac at least (haven't tried Eclipse) will still return an error type but it at least have a toString value of "b.B", which I can put in the generated source code, and then it will later successfully compile at the end of the round. I guess the problem is that "B" -> "b.B" is not just a syntactic thing where it scans the imports, but instead a real type operation, which makes sense as to why it won't work. Shoot. Wow. Even if I generate the dependent class first in the round, and save it via the APT API, then later in the same round javac is still not resolving the generated type. I was trying to do a probing approach where, if I had 5 classes in the round, I would try each in order, unless one of them came across an error type, I'd put it at the end, and then come back to it. Hoping that if one of the other classes in the round resulted in the missing type, things would be cool when I retried it. But, no. Sorry, this isn't even about Eclipse anymore. Shoot. :-) This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. |
Build Identifier: M20090917-0800 I have two generated artifacts, where one depends on the another. Well, its hard to explain, here's the code: package one; import two.ITwo; @GenInterface public class One implements IOne { public ITwo getTwo() { return null; } } package two; @GenInterface public class Two implements ITwo { } @GenInterface is an annotation processor that simply echos a class's public methods into a new interface with the name I<class name>. On a clean build, I get: IOne.java ITwo cannot be resolved to a type One.java: The return type is incompatible with IOne.gwtTwo If I take out "implements IOne", save, the error goes away. If I put "implements IOne" back, it still works. It's only when I do a build clean that the two errors come back and I have to re-take out "implements IOne", save, add it back. If I change the return type of One.getTwo from ITwo to just Two, everything (incremental and full) works. Also, if I move Two into the same package as One, everything (incremental and full) works. It is just something about ITwo being off in another package + "One implements IOne" that is throwing it off. Reproducible: Always Steps to Reproduce: This commit has code to reproduce the bug on a clean build: http://github.com/stephenh/interfacegen/commit/0dccdf0c84b11a247e08852a7d00f424b245383f If you can, just checkout interfacegen (or use the download source button). Load the processor project in a plugin SDK-enabled eclipse, then start a debug instance of Eclipse and import the interfacegen-examples project. I can pretty easily zip both of these projects up and attach it as a zip if you'd like--they're both small and simple.