I find that Swift is quick to mark down changes i make as compiler errors in the side panel, and then when i compile, it decides i am right after all. Is Swift just pessimistic about my code?
Can I get the compiler to wait for me to finish the line before declaring it wrong?
There is nothing pessimistic. Xcode uses the same tool - the compiler - to get the errors. However, it usually compiles only one file, using cached compiled objects for the other files. It also doesn't invoke the compiler after every change in your code, so errors that are already fixed can stay there in the side panel.
Building the project fully forces Xcode to refresh the cache and get the current list of errors from the compiler. I do agree that Xcode has many imperfections and this is one of them. When you can't find an error, just rebuild the project.
Note that IDEs for other languages often rebuild the project automatically to solve such problems. This is currently not an option in Swift because it would take too much time.
Related
I am getting some mysterious compiler type related errors in my ts code. I have another thread addressing them.
But I know there will be no adverse reactions to my code, so I would like to force it to compile and make my js files anyway so I can do some run-time debugging.
I have seen a comment or two about the project compiling despite some build errors. How do I do that? If I use the command line compiler it seems to do this, but apparently I am spoiled VS programmer who wants a to build in one step, not two.
I have VS2013 and TS 1.5.
Thanks, Brad
How do I do that? If I use the command line compiler it seems to do this, but apparently I am spoiled VS programmer who wants a to build in one step, not two.
Make sure that in your csproj you have noEmitOnError set to false.
When compiling a solution with many projects, if I make a compile time error in a project that many other projects use I'll get a flood of errors in the Error List window of visual studio:
Error 80 Metadata file
'C:\trunk\Projects\Libraries\K2DataBaseClient\bin\x64\Debug\CEPCortex.dll'
could not be found C:\trunk\Projects\TradeAiTeacher\CSC
These errors indicate that a project couldn't be built due to another project not being built. These types of errors cascade and don't really tell me anything useful as I know that its all due to a core project failing to build.
These errors often make it harder to find the actual error in the window.
Is there a way to tell visual studio to suppress this type of output and just show me the compile errors in cases like this to make it easy to find what actual code is broken?
Ideally it once the compile error has been fixed we can toggle this hiding off so I see all errors.
I had originally left this version agnostic but visual-studio 2013 is the version I am most concerned with.
No. The C# compiler categorically refuses to consider one error more "important" than another one. It cannot know how important an error can be, it doesn't know enough about the reason it had to produce the error. A missing reference assembly can produce a lot of errors because type definitions are missing. Of course the compiler cannot know the difference between them being undefined because of the missing assembly reference (ignore) or you mistyping a name (don't ignore).
Interpreting the Error List requires a massively parallel computing machine that's capable of high-speed correlation inference and pattern matching. With practical quantum computing still a distant future, you need to use the one that's readily available to any programmer, the one you have between your ears. Start at the top of the list. And work your way down, feeling less inclined to fix them as you progress down the list.
Never hesitate to rebuild before getting to the end of the list when you fixed a gross error. Like a missing assembly reference.
I've found the best way to work with existing the visual studio behavior is to use the advice in this link: and make the compiler stop after the first compile error.
This seems to get as close to solving my problem as you currently can.
So I was trying to add some files to my project and double clicked on library and before I know it the whole entire library was being referenced into my project.
At first I thought, okay no big deal I'll just remove the reference, I did that it took some time, I saved afterword all seem fine, I even added some code.
From here I closed my project, come in the next day open the project and the library is in my project indexing itself. I try removing the reference again and it seems to go away, but now some of my work from the day before isn't there however some of it is, so my program can't run. To top things off Xcode crashes, open up my project again and library is still there, can someone help me with this?
From the Apple Developer Website:
http://developer.apple.com/library/ios/technotes/iOSStaticLibraries/Articles/configuration.html#//apple_ref/doc/uid/TP40012554-CH3-SW1
Select the Build Settings tab in your application target editor. Find the “Other Linker Flags” build setting. Add the flag -ObjC to this build setting’s value if it is not already present. This flag will tell the linker to link all Objective-C classes and categories from static libraries into your application, even if the linker can’t tell that they are used. This is needed because Objective-C is a dynamic language and the linker can’t always tell which classes and categories are used by your application code.
So I recommend to see if this has been done in your project settings and if it has then delete the flag in your build settings.
I have recently converted my project to use ARC (Automatic Reference Counting).
It doesn't really do a very good job of knowing when to actually release an object, and often because I have lots of allocations being performed, my application has excessively high memory usage because the existing objects aren't being deallocated when they're closed from view.
All I need to be able to do is disable ARC for that file, and everything should be OK. I did that, added the release statement, and it worked perfectly. Except of an error.
Whenever the project isn't being built (ie. the error disappears and the build succeeds while building it) it shows an error stating that ARC prohibits the sending of the release message to an object, even though I explicitly added an exception for that file in the Project Settings.
All I really need to do is silence the error, as there is no error (as it builds successfully).
Any help appreciated.
Well, after several builds and cleans, the error has miraculously disappeared.
These problems have been frequent in Xcode 4, I got an unused variable warning from something that was clearly being used.
Here's a different one from the usual confusion over duplicate symbol errors... :-)
I'm working on some legacy Mac code in an Xcode project that has the same global, "trace", defined in several different source files - for instance:
File1.c: SInt32 trace;
File2.c: Boolean trace;
etc. It's clear the original author meant them to have file-specific scope, but just neglected to prefix any of these lines with "static". That's fine, easy enough to fix.
But I'm kind of shocked the linker isn't flagging these! It looks to me like Xcode's linker (I presume gnu ld) only emits duplicate symbol warnings or errors for functions, that are linked into the code segment - but not global variables that are linked into the data segment. Instead, it silently conflates them, which is causing bugs.
So... how do I convince Xcode to emit link errors for duplicate global variables? Or get this information in some other way that can be a routine part of my build?
Well, I thought I'd answered my own question... :-)
I posted earlier:
So if you're using Xcode with LLVM GCC
4.2, go to the build settings dialog, find the "LLVM GCC 4.2 - Code
Generation" section, and check the "No
Common Blocks" checkbox. This enables
the compiler's "-fno-common" option,
and changes the object file generation
so that ld will choke and emit an
error if you have two globals in
different source files with the same
name.
Unfortunately, that doesn't seem to solve all instances. It seems to work fine if all the globals have the same type.
But the example in the question is taken straight from the code, where a variable named "trace" is defined as a global in two different files with two different types. And that's still not caught by the build system when I check that checkbox.