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 @U083D6HK9

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 @U3ZUC5M0R was talking about referring to them from another namespace, though.

Oh, okay. That's the issue I've had. Not sure if @U3ZUC5M0R's issue is different.

I’ll fix that one now.

Just noticed this one too @U0567Q30W

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.

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.