When the unresolvable declaration quick fix can't determine type have it prompt to quick fix those.

[Justin Julicher]

In you example video you have the example of the login method.

login(sessionId, authUser.getUsername(), SESSION_TIMOUT);

you demo that if you were to quick fix the login method before ‘authUser.getUserName()’ and ‘SESSION_TIMEOUT’ they would resolve to generic Objects and you should quick fix them first (order matters).

Could you make it so that if IC detect generic Object references it asks to fix them first?

They way I would see this process working is:

1. User selects quick fix for login.
2. IC jumps (right to left) to SESSION_TIMEOUT and prompts the quick fix for that.
3. IC jumps to authUser.getUserName() and prompts the quick fix for that.
4. IC then quick fixes the login method.

Does that make sense? Is that possible - I’m thinking you probably already thought of that but wasn’t able to implement it…..

‌

Maybe it’ll be just a place cursor at beginning of line and IC prompts to ‘Quick Fix All on line’ iterating right to left?

[Scott Wells]

So I decided to look at how JetBrains does this for Java. I pretty much walked through the exact same code in Java that I did in Apex (changing out UserInfo.getUserName() for another existing class method that returns a String).

For the specific instance that drives this enhancement request, IntelliJ IDEA doesn't actually offer any quick fixes for login until all of its arguments are resolvable. It's still flagged as unresolvable declaration, but the IDE won't generate it for you until it can successfully infer actual data types for the arguments.

That basically accomplishes what you're wanting, but if you use F2 to cycle through the errors and then press Alt/Opt+Enter on each, you'll still stop on login but just won't be able to do anything. That's a bit different than what you're requesting. I'll need to think about this a bit. Generally a code intention/quick fix activated on one reported issue doesn't apply to other reported issues. I agree that it might make sense in this case in terms of a smoother workflow...I just need to figure out what that might look like.

Interestingly there were other differences where I think things actually work a bit better in IC/Apex than in IJ/Java (though it's going to be VERY rare that I can say that!), For example, when I got to SessionType.SHORT_LIVED, it only offered to create a top-level enum and not an inner enum. That seems strange since inner enums are completely legit in Java. I might report that to JetBrains as a potential bug.

Anyway, let me get to the other side of the work I'm doing now on Change Method Signature/Introduce Parameter/Create Parameter and I'll take a closer look at this.