Did something break in the latest EAP builds to do with protocols? I’m getting some very weird behaviour now (`1.9.4-eap3-2020.2` ) - namely cursive tries to import
protocols instead of requiring them.
when cursive imports the protocol, it looks like:
(:import (foo.bar.baz ISomething))
as if it was a java interface
eg:
however, when imported like this, intelliJ does provide gutter hints, which doesn’t happen with require
etc.
So in that case, you would normally either :require
/`:refer` that protocol, or refer to it qualified with an alias, like component/Lifecycle
. Protocols are tricky in Clojure because they actually do define an interface, and in this case it’s probably what you want, although there are probably subtleties there that I’m not aware of.
I've seen this too.
getting some code warnings on valid destructuring of a method arg too
going to downgrade to 1.9.3
this is valid, right?
the :or
clause, specifically
Yes
well, that’s a bug in 1.9.3
as well then, and the import
behaviour happens there too
thank for sanity check @kenny
Thanks for the report, I’ll check those cases out.
With the protocol issue, what does the protocol reference look like in your code when Cursive is trying to import it?
There’s actually an additional problem where Cursive tries to resolve the symbol at the protocol definition itself, I think that’s an IntelliJ 2020 problem.
It seems to only happen in some namespaces.
That namespace is .clj
Doesn't appear to happen in the 3 cljs namespaces I tested (though, they're all from the same IntelliJ module)
Right, that’s at the definition - that I think is new in IntelliJ 2020, I had to fix a bunch of similar cases for vars.
Hmm, yeah, protocols are treated differently by Cursive in clj and cljs, since in clj they create an interface and in cljs they’re more like a var.
I got the impression that @dazld was talking about referring to them from another namespace, though.
Oh, okay. That's the issue I've had. Not sure if @dazld's issue is different.
I’ll fix that one now.
Just noticed this one too @cfleming
Yeah, I think that’s all the same case. I’ve just fixed it, it is indeed new in the new EAP, I can’t blame IntelliJ 2020 for this one.