I have setup UnitTests for some of the logic of my iphone app, I followed apple's guide for UnitTests in XCode, however when some of the assertions fail - instead of highlighting the place directly in code like a regular compilation error - XCode just displays the number of errors in the bottom-right corner and I have to look up the errors in the output log. Does anyone know what additional steps one has to take to make XCode highlight assertion failures in UnitTests like regular errors in code?
This is a known bug in Xcode. I don't think it has worked for at least as long as version 3.2.x but it might have broken earlier. I filed a bug report with Apple back in march but it got closed as a duplicate so they are aware of the problem. I don't imagine it will get fixed in the 3.X incarnation since Xcode 4 is on its way.
Related
I am using Unity as a library for SwiftUI quite a while now. However when updating to the newest iOS version (16.1) it stopped working. Compiling runs without a problem but during runtime I get an error when Unity is starting:
in:
I even started a completely new project with Unity included to SwiftUI and get the same error. As this is some kind of assembler code and I certainly do not know how to read it I don't really know where I have to start searching.
In the console I get: "warning: UnityFramework was compiled with optimization - stepping may behave oddly; variables may not be available." I tried several ways to turn off optimization as described in related questions which did not work. When unchecking "Debug" in the scheme options the project starts normally
A similar thing happened to me. I'm not entirely sure if it's the same problem but in the console, I got a message saying UnityFramework is running optimized and may behave oddly. Unfortunately, I've tried a couple of ways to disable optimization but I've yet to find a solution.
For now, I'm able to bypass this error by disabling the debugger entirely. In order to do this, you have to go to Product -> Scheme -> Edit Scheme and uncheck debug executable.
I'm not sure if this will work for you but I figured it'd be worth a shot!
I am having trouble with Xcode and identifying the source of the error. It will flag an error, but no longer identifies the specific line of code that is the problem. It used to, but it no longer does. An example is included.
example of what I see when i get an error. none of the x marks id's the line of code with the problem
As a newcomer, it would help tremendously for me to understand the line of the code that is the source of the issue. This was a feature previously available, but it no longer is for me. This feels like a simple settings issue, but I can not solve it. Any insights would be appreciated. I am running Xcode 13, Swift 5; the MacOS is Big Sur 11.6 (note this problem has been ongoing - i've just reached my frustration level tonight).
Sorry to post this again. But I really got lost in solving this bug in my Xcode. I am using Xcode Version 8.0 swift 3 , I have got this error when building the project:
Command failed due to signal: Segmentation fault: 11, and it shows me in the storyboards the code in black color for a while. Also, there is a notification says An internal error occurred, Source editor functionality is limited, attempting to restore, Report a Bug.
I have searched a lot and most things I found about building, cleaning, reopening the project. Also, I tried to uncheck and recheck the Automatically managed signing for my project.
I hope to hear from you the best solution for my problem
waiting for your replay greatest coders
I had this same issue. I went to the 'Debug Session' window and saw I had type conversion issues. I was trying to determine is an object was a Set and needed to evaluate it as a Set<String>.
Not sure if that'll help you, but check out the 'Debug Session' window to see which view controller class has the issue and what it is.
Having updated Swift + ObjC project to Xcode 8 (Swift 2.3) I found 50% or more of the time Xcode does a full rebuild of the project instead of an incremental build.
The changes made are adding simple print statements. There seems to be no logic as to when it performs a full rebuild.
It appears in the "Check dependencies" phase it decides this. On Xcode 7 this did not seem to be a problem.
Has anyone else encountered this?
I have found this works consistently, it will however compile swift files if you modify a header included in the bridging header. It will also do full compile if you switch git branches back and forth.
Firstly make sure optimization level for debug is set to None (Not whole module optimization)
Then, according to https://forums.developer.apple.com/thread/62737 Apple Staff (ddunbar):
We believe that setting:
HEADERMAP_USES_VFS = YES
to true in your project (or for all your targets) may be an effective workaround > for many people. This is not guaranteed to work (which is the reason it isn't > already on by default), but it should work for most projects.
This should be added through "Add user-defined setting" under your target Build Settings.
.
Ok, here's an answer to why it's happening, but I don't know the solution. If you use the "Other Swift Flag" -driver-show-incremental Xcode will output what it decides it needs to compile based upon it's dependancies. You'll see things like:
Queuing EditProfileViewController.swift because of dependencies discovered later
Queuing ChangePasswordViewController.swift because of dependencies discovered later
Queuing JoinViewController.swift because of dependencies discovered later
Queuing JoinProfileViewController.swift because of dependencies discovered later
Queuing FormViewBuildable.swift because of dependencies discovered later
Queuing RadioTextFormView.swift because of dependencies discovered later
Queuing TextFieldFormView.swift because of dependencies discovered later
Queuing AccountProfileViewController.swift because of dependencies discovered later
I'm wondering if this is a swift 3 problem, because I wasn't having this issue before converting. I made a little example project where
FileA inclues a thing from FileB includes a thing from FileC
and even adding a file private change to FileC that's not used anywhere causes FileA, FileB, and FileC to be queued for compilation due to dependencies. I'm going to be testing this example in Xcode 7 later today to see what happens.
So it looks like swift 3's dependency resolution isn't working very well. I've tested this on 2 other swift 3 projects at work, and the same holds true. Make any change in any file, and every file gets compiled. It doesn't feel slow until you start getting to projects with about 15,000 lines of code or so, which may be why nobody is talking much about this. Unless you have a somewhat medium sized swift 3 app, you probably won't even notice that incremental complication isn't working quite right. I'll update if I learn anything more.
Apple released new beta version of Xcode yesterday (Nov 14)
Xcode 8.2 beta 2
And this issue has been marked as resolved in the release note.
Build System
• Xcode will not rebuild an entire target when only small
changes have occurred. (28892475)
It is working for me. The build speed came back as usual.
Everybody who is facing this issue, should give it a try!
https://developer.apple.com/download/
Unchecking "Find Implicit Dependencies" in Edit Scheme > "Scheme" > Build tab fixed it for me for project files. "Copy swift standard libraries" still takes forever..
After upgrading to the 4.1 iOS SDK my unit test bundles always return with the following two errors and one warning:
An internal error occurred when handling command output: -[XCBuildLogCommandInvocationSection setTestsPassedString:]: unrecognized selector sent to instance
An internal error occurred when handling command output: -[XCBuildLogCommandInvocationSectionRecorder endmarker:]: unrecognized selector sent to instance
Run unit tests for architecture 'i386' (GC OFF) did not finish
I get these errors despite it reporting that all X out of X tests passed. I read about a similar bug in an older version of XCode that also occurred immediately after it was released (something about a bug in a regular expression for time) that could be mitigated by setting your time zone to Pacific Time, but I can't say for sure it's a regression to there specifically.
Is anyone else having this problem?
There is a fix available on the apple dev forums,
https://devforums.apple.com/thread/68687
it's a date parsing problem. The fix is quick, it requires including one .m added to your test bundle. The fix is available above or from:
http://gist.github.com/586296
It does seem to be a regression with some part of the reporting code not respecting timezone issues. The output is tagged as ending before it began, so gets very confused and chokes.
One work-around, that I found somewhere on Google, is to change the Run Script stage of the target.
Change
"${SYSTEM_DEVELOPER_DIR}/Tools/RunUnitTests"
to
"${SYSTEM_DEVELOPER_DIR}/Tools/RunUnitTests" 1> /tmp/RunUnitTests.out
It’s working round the issue, rather than solving it, but does work.
This is a confirmed bug in Xcode 3.2.4/4.1 SDK. It has been reported to Apple.
Upgrading to Xcode 3.2.5/4.2 beta SDK solves the problem. I don't know if access to beta SDK:s is open, or if you need to be a registered developer, though.
I'm getting the same issue too.
Oddly enough, I can get the unit tests to complete properly by running them through the debugger as per http://www.grokkingcocoa.com/how_to_debug_iphone_unit_te.html
So it looks like something wrong with the XCode interface to otest...
I really don't want to set my timezone to PST which this post seems to be indicating as I'm in the UK...