Bug? Auto-completion is extremely slow to determine type of instance-variables.. (Swift)
Answered
If i declare var myObject = MyClass() as a local variable in a method the autocomplete directly understands myObject is an instance of MyClass() and provides
correct alternatives. However if i do the same declaration as an instance variable i just get class <Unknown> and AppCode cannot provide any completition. After restarting appcode the <Unknown> turns into MyClass. Reproducable everytime, highly annoying. I am running latest AppCode.
Please sign in to leave a comment.
Hi Markus.
Could you provide a self-sufficient snippet to reproduce (including declaration of MyClass and its parent types)?
By "latest" do you mean AppCode release (2017.1.2) or AppCode 2017.2 EAP?
In this small case it takes 10-20 seconds for AppCode to realize the type, when TestController is more complex in my real project it
doesnt even recognise it when i left the computer on during night..
I am using
AppCode 2017.1.2
Build #OC-171.4249.57, built on May 2, 2017
Subscription is active until June 21, 2017
JRE: 1.8.0_112-release-736-b21 x86_64
JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
Mac OS X 10.12.4
where can i get something more cutting-edge? :)
//Markus
OT: i installed latest EAP but its not usable, it wrongly states that my protocols are not conformed to and then wants to implement already implemented methods to confirm to these protocols that also fails because of double declaration :D
Markus,
Can't really replicate the behavior you're seeing with type inference for 'testObject'. Please try File | Invalidate Caches & Restart and check if the issue is reproducible after that.
If yes, it would help if you provide some more information. Do you have any extensions for UIViewController / MapInfoViewController classes? Is the project pure Swift or mixed Objective-C/Swift? It would be great if you could send us a sample project where you see the problem (any basic project created from scratch).
Regarding false intentions to implement protocol methods: we have some known issues (e.g. OC-15452, OC-15505 ) related to that and we work on them, however, it would be great to see your case (if you could narrow it down to a self-sufficient snippet - that would help a lot).
I invalidated caches and on the first try it actually detected the correct type. I created another variable and the same problem comes back :)
No extensions for UIViewController / MapInfoViewController. Its a Swift project but it uses Objective-C libraries with bridging header.
I can recreate it just by creating a new Swift-project, create a TestViewController.swift-file, instantiate an TestViewController-instance-variable in the default-viewcontroller.. Try to get autocomplete on testObject in ViewController and you get <Unknown>.
This works perfectly fine for me.
What Xcode do you have selected in Preferences | Tools | Xcode? Could you please send us your sample project, anyway? Also please collect logs from Help | Show Log in Finder and send them as well (to appcode-support@jetbrains.com).
Xcode 8.3.2
I have sent the logs and the project to you :)
//Markus
About the protocol bug:
Now i experience this problem even in local functions, this is after a fresh invalidate cache:
( https://github.com/Skyscanner/SkyFloatingLabelTextField )
Markus,
Thanks for the project and logs. I was able to reproduce your issue finally: seems there is, indeed, some delay after creating new variable inside the class & type inference process. FYI, I was able to speed up type inference by commenting/uncommenting some line before variable declaration. That's definitely an issue on our side, we'll investigate that.
I wasn't able to replicate the issue with SkyFloatingLabelTextField though, at least in function scope. Will try again. In the meantime, maybe you'll be able to provide some more details/context on that?
As for the issue with false protocol intention, it's a known one: OC-15380. It's caused by the problem with resolving WKUserContentController and WKScriptMessage types in userContentController() declaration which, in turn, is triggered by a more general issue OC-13434 we're currently working on. Please watch both tickets for progress. Hope we can get done with them soon.
Ok cool.. i never managed to get AppCode realize the type of SkyFloatingLabelTextField at all. Interesting enough though I found a workaround for it. If i subclass SkyFloatingTextField AppCode finds the subclass directly. A detail that might be valuable for you is that the class is included in the project by Carthage (https://github.com/Carthage/Carthage)
Markus,
I've created OC-15560 for the issue with type inference for variables. Please upvote & watch it for progress.
As for the problem with SkyFloatingLabelTextField - could you please point to a specific project & file from Carthage where you noticed that?
Great, thanks! I can try make an example project for you. Now i noticed a new related bug or perhaps it is the same: it sometimes resolve an object not to unknown but Object.Type that hides lots of parameters. For example now i sit with a UITextField() that AppCode recognise as an UITextField.Type and I cannot access normal members of the class like backgroundColor textColor and so on..
here is a field in the class that is working as it should:
i can access lots of things that i need to access here:
now check this textfield that is declared in the exact same way:
nothing much i can use in this object:
bonus wtf, if i change spacer to an UILabel it still recognise it as an UITextField.Type
i hope you get this fixed quick.. i love your products and AppCode was kick ass for OBJ-C but i am sorry to say that the
Swift-support so far feels like it is an alpha i am testing.