I know there are many compiler flags and how to use them. At times while seeing a third-party code we encounter a new flag and fail to understand why the hell this flag is used? How no warnings are shown even though there is retain-cycle in an existing code.
So I tried to find if I can find all the compiler flags with description. That would help to understand about its usage and other flags to replace it.
Please provide me some link or list of all the flags.
The list of compiler flags I found it in Clang Compiler User Manual.
This link may get broken some day but surely it will be there with the Compiler User Manaul.
Command Line Options
This section is generally an index into other sections. It does not go
into depth on the ones that are covered by other sections. However,
the first part introduces the language selection and other high level
options like -c, -g, etc.
Options to Control Error and Warning Messages
-Werror Turn warnings into errors.
-Werror=foo
Turn warning “foo” into an error.
-Wno-error=foo Turn warning “foo” into an warning even if -Werror is specified.
-Wfoo Enable warning “foo”.
-Wno-foo Disable warning “foo”.
-w Disable all diagnostics.
-Weverything Enable all diagnostics.
-pedantic Warn on language extensions.
-pedantic-errors
.....Continued
Related
I'm using Clang 3.8 to compile one file that comes from a different source in a project. This is a temporary crutch, as this file is an addition to a library that I also use, and the code it has will be part of that library's next release. However, these people develop with less stringent warning flags than I do.
I'm not interested in these warnings as they're benign, I don't maintain that file, and it'll go away within a few months. Of course, I can selectively remove a warning or two, but I think that it makes more sense in this case to disable all and every warnings that it generates because I could change the warning settings of my project later and more occurrences could come out of it.
I've tried #pragma clang diagnostic ignored "-Weverything", but Clang warns that -Weverything is an unknown warning group.
How can I ask Clang to not generate any warnings for that file?
Indeed, the "-Weverything" is not a group of warnings, but just a special option passed to the compiler. Here is code that handles this case: lib/Basic/Warnings.cpp:118
You still can compile your problematic source file using slightly different rules/flags as you use for others sources:
clang -Wno-everything foo.c
However, I'd recommend to disable each warning explicitly using #pragma.
In case you disable all warnings, and then upgrade your compiler, then you may miss some new warnings, which could be important (e.g. undefined behaviour checks, security checks, etc).
Also, imagine what happens if the file is not gone after three months, but stays in the project forever.
If you need your compiler flags to be consistent between GCC and Clang, they both have the -w flag:
$ clang --help | grep -i suppress
-w Suppress all warnings
I am having no luck the last few days since Xcode 5.1 came out.
I keep getting this error on an old project that supports iOS 6.0:
ERROR:
clang: error: unknown argument: '-fno-obj-arc' [-Wunused-command-line-argument-hard-error-in-future]
clang: note: this will be a hard error (cannot be downgraded to a warning) in the future
Command /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang failed with exit code 1
There are not many posts about this on the internet and some suggestions seem to be to change your CFLAGS but I have no idea how to do that in Xcode.
Apple suggests this from their documents:
Compiler
As of Apple LLVM compiler version 5.1 (clang-502) and later, the
optimization level -O4 no longer implies link time optimization (LTO).
In order to build with LTO explicitly use the -flto option in addition
to the optimization level flag. (15633276) The Apple LLVM compiler in
Xcode 5.1 treats unrecognized command-line options as errors. This
issue has been seen when building both Python native extensions and
Ruby Gems, where some invalid compiler options are currently
specified. Projects using invalid compiler options will need to be
changed to remove those options. To help ease that transition, the
compiler will temporarily accept an option to downgrade the error to a
warning:
-Wno-error=unused-command-line-argument-hard-error-in-future
Note: This option will not be supported in the future. To workaround
this issue, set the ARCHFLAGS environment variable to downgrade the
error to a warning. For example, you can install a Python native
extension with:
$ARCHFLAGS=-Wno-error=unused-command-line-argument-hard-error-in-future easy_install ExtensionName
Similarly, you can install a Ruby Gem with:
$ARCHFLAGS=-Wno-error=unused-command-line-argument-hard-error-in-future gem install GemName 16214764 updated
How do I get this workaround? Obviously Apple has messed up because it should only be presenting me with a warning and not an error according to their documents.
Any help would be greatly appreciated. I can not build my app until this issue is rectified.
There is no such thing as -fno-obj-arc. This never was working correctly; you just weren't seeing the warnings. The correct form is -fno-objc-arc.
EDIT (appended info drawn from my comments below): This is not a clang error. It is an error in the project; clang is merely reporting it. The project itself wrongly contains the -fno-obj-arc argument, probably in the Compile Sources build phase of the target (as described here: How can I disable ARC for a single file in a project?). It is easy to type the setting incorrectly; what has changed in Xcode 5.1 is merely that clang is now calling the problem to your attention. Thus, as I said before, this never was working correctly; you presumably intended to turn off ARC for certain files, but you were failing to do so, as the build argument was incorrectly entered.
Update to xcode now throws unknown compiler flags as hard errors rather than warnings. Found this to be helpful:
https://langui.sh/2014/03/10/wunused-command-line-argument-hard-error-in-future-is-a-harsh-mistress/
I figured out with a small bit of help from matt.
I was trying to figure out where to change the -fno-obj-arc and NO ONE answered that question.
I found this link to be helpful...
http://blog.evanmulawski.com/?p=36
Once you select build phases and compile sources, you can look next to the files in your project and change their build flags.
Thanks for the attempt guys.
export ARCHFLAGS="-Wno-error=unused-command-line-argument-hard-error-in-future"
You need to change -fno-obj-arc to -fno-objc-arc.
Select project -> targets -> build phases ..see picture
I am intentionally using a category to override a method that I know is already implemented on a primary class. I know this is typically a sign of weak design-- please, no lectures-- but I can't subclass cleanly in this case. I know swizzling may also be an option.
But for right now, how can I suppress this warning? llvm throws a compiler warning that I can disable (diagnostic ignored "-Wobjc-protocol-method-implementation"). But then the linker also complains.
This asks a similar question but was looking for a different answer. How can I tell the linker not to complain?
Thanks.
Unfortunately, there's no good answer.
The only linker-based solution is to pass -Wl,-w at link time; that is, tell Clang to pass the -w option through to the linker. This will suppress all linker warnings, potentially including ones you'd still like to see.
A higher-level workaround is to pipe the linker's output through grep -v. The details of that solution would tend to depend heavily on your shell and your build system.
I use a C++ library for an iOS app. With Apple LLVM 3.1 compiler configured (default), I get a lot of warnings for this C++ code, most of them saying:
... is a GNU extension
The introduction of clang's user manual says:
The Clang driver and language features are intentionally designed to be as compatible with the GNU GCC compiler as reasonably possible, easing migration from GCC to Clang. In most cases, code "just works".
So, is it save to just look for a switch to disable this warnings (btw. how to?) or should I better get this lib rid of all GNU extensions?
You can suppress the warnings using compiler flags. Clang tells you which compiler flag to use for each warning. After a build, choose View > Navigators > Show Log Navigator. Then choose the latest build log from the log navigator. Find a file with a warning and click the disclosure button at the right end of its status line. Xcode will show you the compiler command line and output for that file. Each warning should include the compiler flag that enables the warning. Example:
In my example, the warning flag is -Wpointer-arith. So the warning can be disabled by -Wno-pointer-arith. So I could add that flag to the “Other Warning Flags” build setting:
I have a chunk of code that crashes unless I build with optimizations off. I'm building with LLVM compiler 2.0
I would like to turn off optimizations by wrapping the offending code with a #pragma compiler directive; or turn off optimizations for an entire file.
I've been digging in the clang manual and code; but nothing jumps out at me.
Does anyone know how to change the optimizations for a single CU (as opposed to for the entire app)?
You can set per-file compiler flags in Xcode. In Xcode 4 (which I assume you're using because of the LLVM 2.0 reference), first select the project in the left-hand project browser. Go to the Build Phases tab and expand the Compile Sources build phase.
In there, you can set per-file compiler flags, so you could try going to the offending file and entering in -O0 as a flag to try and disable optimizations for just that file.
GCC has some attributes you can set for this, as pointed out by Johannes in his answer here, but these might not be in LLVM. Also, from the comments there, it appears that these are not even in Apple's customized GCC used for building iOS applications.