In this line of code:
NSInteger answer = 3; NSString *s = [NSString
stringWithFormat:#"%ld",answer];
In Xcode 10.3, under a debug build there is no error.
Under release builds I get this error:
values of type 'NSInteger' should not be used as format arguments; add
an explicit cast to 'long' instead [-Werror,-Wformat]
I understand the why on the error, that I should also cast answer to (long), and the compiler will complain and fix the issue if I start with #"%d". But when the ld is there the compiler in debug builds keeps quiet, but in release it raises a flag.
Any ideas as to what setting would cause this to happen?
Thanks in advance!
The answer to your question is pretty broad, but I think you should get an idea. Like the above comment there's a whole bunch of factors that filter the changes its going to take when building for debug and building for production release. For performance and compatibility apple is very strict on releases. Thus the default values for some of the build configs in the Build settings is pretty different from Building for debug and release.
Take a look at the images attached below:
Note : Most of them can be customized for your preference but it does effect the building process as well as the delivery!
Related
Is there a lint for Elixir (like for Javascript) which checks that every function has a type specification?
There is an Erlang compiler switch, +warn_missing_spec, which does this, but I'm having trouble getting it to work with Elixir at the moment, I think there is a bug with it's parsing of the ELIXIR_ERL_OPTS environment variable which is converting +warn_missing_spec into -warn_missing_spec which isn't a valid compiler option. I'm going to open an issue on the tracker, but thought you might like to know that this does indeed exist.
EDIT: As José mentioned below, the correct flag is ERL_COMPILER_OPTIONS. You can enable the missing spec warning during compilation by doing the following:
ERL_COMPILER_OPTIONS="warn_missing_spec" mix compile
Keep in mind you may get superfluous warnings from Elixir itself, for functions like __MODULE__. It should still be useful though. One last thing to note, I discovered this morning that there is a problem using this flag with mix compile, and that it's currently only warning about mix.exs. This is being fixed, and may even be fixed by the time you see this, but it's something to be aware of.
Here are my two lines of code:
NSString *frontFilePath = [[NSBundle mainBundle] pathForResource:[self.bookendFileNames objectAtIndex:self.randomIndex] ofType:#"caf"];
NSLog(#"frontFilePath = %#", frontFilePath );
I put a break point on the second line and when there, I try to print it:
(lldb) po frontFilePath
But I get the following error:
error: variable not available
I'm confused because if I step over the NSLog statement, the variable does indeed print to the console.
For what it's worth, I'm trying to debug the first line since sometimes it returns NULL, tho I can't, as of now, figure out why.
This is an artifact of debugging optimized code. When the compiler's optimization is enabled in your build settings, it moves variables between memory and registers as it decides is best. At the point where you're examining the variable in lldb, it may not exist in registers or memory at all -- even though it looks like it should still be available for display.
It's possible it is a shortcoming of the debug information output by the compiler. Sometimes the compiler will copy a variable into a register for its use and only list that register location in the debug information. Later the register is repurposed for other uses; value is still present on the stack but the compiler hasn't told the debugger that the value can be found there.
The only way to really tell whether it's insufficient debug info or if the value genuinely doesn't exist at that particular instruction is to examine the assembly code by hand. As soon as you turn on optimization with the compiler, the source code becomes a weak view into what's actually being executed in any particular order.
Instead of wandering too far into the wacky world of optimized code debugging, I strongly recommend turning off optimization (Optimization Level in your Build Settings) for your build and debugging it that way, if at all possible. If you do need to debug your app with optimization, make sure you're building with the latest Apple LLVM compiler supported by your Xcode -- there is always work being done to improve optimized code debugging and you want to avail yourself of the most up to date tools you can.
The "Address Sanitizer" in the diagnostics seems to make the values of variables unavailable, too.
Schemes > Run > Diagnostics > Address Sanitizer
In Swift, possibly starting with Xcode 9 and still an issue in Xcode 10, this could even come up when code optimization is turned off in the build settings. As #carlos_ms has pointed out here, a temporary solution is to define the variable as mutable, i.e.
Turn
let foo = Bar().string
into
var foo = Bar().string
in order to cause optimization to skip on this variable. Note that this might not work in all instances.
In this case, a good ol' debugPrint() might help you out.
I am trying to convert previously objective C code which is without ARC into ARC. I am fallowing the procedure like in Xcode: File > Edit > Refactor > Convert to ARC.
But I am not able to convert it, because it's generating lots of errors. I searched about this; I am trying to change the build settings in Xcode Target.
The Convert to ARC tool is not a magic bullet that makes your project suddenly ARC ready. What the tool is does is remove all of your calls to things like release & retain, it can also take care of switching some autorelease pools to the new #auto release {} style.
Before it does any of this it runs a pre-flight script to look for stuff that is too complicated for it to figure out and flags them as errors so you can go through each one and make the correct fix.
You need to step through each one of those 84 issues and figure out the solution to each one. Most likely there are half a dozen or so kinds of errors that are in multiple places but each occurrence may have a slightly different solution. Xcode may suggest a few possible fixes for some of the errors (any of the errors that show a stop sign with a white square in it have possible fixes, Xcode just doesn't know which one to use so you need to pick). Some of the issues will be easily solvable with a little help from Google. There will also likely be more errors than that in the end (I converted one project over that each time I fixed errors and tried to convert it reported more).
For the errors that you can't figure out after doing some research you should post questions about here, make sure to be specific as there are many possible things that could cause issues when converting to ARC.
I'm getting a "Compilation exited with code 134" when attempting to use the "LLVM Optimizing Compiler" switch for release iPhone builds, using MonoTouch 4.0.1.
I don't get much information from build output window at all - just:
"Compilation exited with code 134, command:"
MONO_PATH=(snip)/bin/iPhone/Release/LSiOS.app /Developer/MonoTouch/usr/bin/arm-darwin-mono --llvm --aot=mtriple=armv7-darwin,nimt-trampolines=2048,full,static,asmonly,nodebug,llvm-path=/Developer/MonoTouch/LLVM/bin/,outfile=/var/folders/03/033pAAGuHgGkIy4CorbVV++++TI/-Tmp-/tmp38107451.tmp/Newtonsoft.Json.MonoTouch.dll.7.s "(snip)/bin/iPhone/Release/LSiOS.app/Newtonsoft.Json.MonoTouch.dll"
Mono Ahead of Time compiler - compiling assembly (snip)/mscorlib.dll
What is odd is that in earlier command lines, there is a correlation between the DLL mentioned in the arm-darwin-mono command line and what is the compiling, but in this case it says "mscorlib.dll".
Any thoughts?
I have found a few cases (googling and from bugzilla.xamarin.com) where the error code 134 is related to Mono.Linker being too aggressive (removing something that's needed).
This is easy to confirm by turning off the linker, i.e. "Don't link" in Linker Options. If the build works then you can try isolating the assembly where the linker makes a mistake.
E.g. add a "--linkskip=mscorlib" to the mtouch extra parameters and re-enable linking. This will link everything (Link All) or all SDK (Link SDK assemblies) except the assembly you selected (mscorlib in the example). That's only a workaround and a bug report should be filled so the issue can be fixed properly (and get you all the linker advantages).
However be warned that there are other issues sharing the same error code, like:
http://ios.xamarin.com/Documentation/Troubleshoot#Error_134.3a_mtouch_failed_with_the_following_message.3a
YMMV
mtouch does its native builds in parallel so the logs can be confusing, e.g. you can see a bit of assembly X output followed by some assembly Y output.
Reading the full log might help you (or us) to pinpoint the issue.
I was having the exact same problem Scolestock. My app would build fine until I enabled llvm, then it was "Compilation exited with code 134, command" when trying to build the 7s for the app itself.
I'm elated to say that after 2 days of painstakingly whittling my app down to the core problem, I was able to isolate the issue to the usage of embedded dictionaries such as:
Dictionary<enum, Dictionary<enum, value>>
I was able to fix this by defining a class for the embedded dictionary and using that instead:
public class MyDefinition : Dictionary<enum, value>
{
}
...
public Dictionary<enum, MyDefinition>
Not sure if this will help you, but hopefully it'll help some poor soul who decides to use embedded dictionaries and runs into my same problem.
I unintentionally compiled the following statement:
manager.groupName - lastGroupName;
Instead of:
manager.groupName = lastGroupName;
I am trying to understand why the compiler does not even provide a warning for the former statement I unintentionally provided. The statement has no effect, even it if is legal to subtract pointers from one another.
Both groupName and lastGroupName are of type (NSString *).
The groupName property is declared as:
#property (nonatomic, retain) NSString *groupName;
Wondering if I should visit bugreporter or if there is a reason that XCode isn't providing a diagnostic.
This is a legal statement in C and thus also in Objective-C, so the compiler doesn’t have to warn about it. You could add the warning flag -Wunused-value to the compiler settings. This warns about statements without effect like this.
Generally there are lots of flags to tell the compiler what exactly to warn about. Everybody has different ideas what is OK, and what should be warned about. If the compiler emits too many warnings they become useless.
Also note that clang does indeed produce better warning and error messages it doesn’t mean that it will automatically produce more warnings. It also has the same flags for enabling and disabling certain warnings that gcc has.
XCode doesn't have the best syntax checking, although it's supposed to be much better in the version coming out soon (4.0 I believe, in beta now).
Registered developers can download XCode 4 beta which improves syntax checking in the "clang" 2.0 front-end. You can get some of that now by selecting "llvm" with clang 1.5 as your compiler instead of GCC. Apple's current recommendation is the GCC front-end and LLVM 1.5 back-end, but then you'll still be stuck with GCC's awful error messages.
I'd recommend downloading XCode 4 and trying the code out on that. You might find some significant bugs that you can go back and fix in XCode 3 before release.
In addition, periodically doing a "Clean All" and "Compile and Analyze" will find a lot of common mistakes. Highly recommended, especially if you're stuck on something.
This is legal syntax, so no error should be expected. It does seem useless, and a high quality compiler might issue a warning.
At runtime the result is a different matter. Unless I'm misremembering this is undefined behavior unless the two pointers are the same or at least point into the same array.