<@U06A03HV1> <@U0N6C2Q9F> I’ve noticed that the tw...
# development
a
@witty-crayon-22786 @fast-nail-55400 I’ve noticed that the two following Java compiler errors are both regular enough to automatically parse, and actionable enough, and I’m wondering whether they should become an (optional) part of our dep inference pipeline:
1:
Copy code
core/test/com/googlecode/guice/bundle/OSGiTestActivator.java:545: error: cannot access Stage
    Injector injector = Guice.createInjector(new TestModule(bundle));
                             ^
  class file for com.google.inject.Stage not found
2:
Copy code
core/test/com/googlecode/guice/Jsr330Test.java:464: error: cannot find symbol
        Key<T> key, final com.google.inject.Provider<T> unscoped) {
                                           ^
  symbol:   class Provider
  location: package com.google.inject
These tend to only show up once other errors are resolved, but I feel like we have enough information to feed a failed compilation run back into the dependency resolver and re-try compilation, perhaps with a big warning telling users how to amend their build file
w
parsing compiler errors is feasible, but it’s a whole other ball game from inference
because it requires making a first attempt at compilation before you have information.
the suggestion i made yesterday re: “exports” likely applies here too: https://pantsbuild.slack.com/archives/C0D7TNJHL/p1636391530334700?thread_ts=1636391254.333800&amp;cid=C0D7TNJHL
a
Probably not in this case
w
i.e., types used in some positions should automatically be exported by inference
a
a parser without knowledge of the structure of returned types wouldn’t have enough information to do inference
w
your case 2 is the same as the Matcher case, isn’t it?
@ancient-vegetable-10556: the class that defines the method would export, not the consumer
there is enough information in that context.
a
#2 is a totally different thing again
It looks like I picked examples that are distracting you from what I’m actually talking about
One Moment
w
“class file for X not found” is a good example. and i’m pretty sure exports apply
a
OK, let me go digging
w
i’ll open a ticket explaining exports. i think that they’ll be important.
a
Oh, I know they’re important
but please go ahead with the ticket
@witty-crayon-22786 I was thinking it was a case like this one:
Copy code
core/test/com/googlecode/guice/Jsr330Test.java:86: error: cannot access Named
                bind(B.class).annotatedWith(Names.named("jodie")).toInstance(b);
but that may well just be another more complicated instance of #13525
w
yea, i think so.