有没有办法抑制 Xcode 中的警告？

Posted 2023-03-23

【中文标题】有没有办法抑制 Xcode 中的警告？

【英文标题】：Is there a way to suppress warnings in Xcode?

【发布时间】：2010-09-16 17:13:24

【问题描述】：

例如，我正在调用一个未记录的方法，并且由于该方法不在标头中，因此我在编译时收到警告。我知道我可以将它添加到我的标题以停止警告，但我想知道除了将它添加到标题（这样我可以保持标题清洁和标准）之外是否还有其他方法来抑制警告？编译指示还是什么？

【问题讨论】：

是的，有时你需要告诉编译器不要警告你任何未使用的变量（据他说）但实际上你可能将它用作BOOL ok = [[NSCalendar currentCalendar] rangeOfUnit:NSMonthCalendarUnit startDate:&d interval:NULL forDate:self]; NSAssert1(ok, @"Failed to calculate the first day the month based on %@", self);

【参考方案1】：

要在每个文件的基础上禁用警告，使用 Xcode 3 和 llvm-gcc-4.2，您可以使用：

#pragma GCC diagnostic ignored "-Wwarning-flag"

警告名称是一些 gcc 警告标志。

这会覆盖命令行上的所有警告标志。但它不适用于所有警告。将 -fdiagnostics-show-option 添加到您的 CFLAGS 中，您可以查看可以使用哪个标志来禁用该警告。

【讨论】：

谢谢！正是我需要的！

获取警告代码的简单方法：转到日志导航器 (Command+7)，选择最顶层的构建，展开日志（右侧的“=”按钮），然后滚动到底部。

对于那些关心的人，GCC 警告选项的教育参考：gcc.gnu.org/onlinedocs/gcc/Warning-Options.html

看来#pragma GCC diagnostic ignored "-Wwarning-flag" 已经被删除了

@allenlinli 仍然存在，您只需将warning-flag 替换为gcc.gnu.org/onlinedocs/gcc/Warning-Options.html 中列出的警告之一

【参考方案2】：

有一种更简单的方法可以抑制未使用的变量警告：

#pragma unused(varname)

编辑： 来源：http://www.cocoadev.com/index.pl?XCodePragmas

更新： 我遇到了一个新的解决方案，一个更强大的解决方案

打开项目>编辑活动目标>构建选项卡。 在User-Defined 下：找到（如果没有找到则创建）密钥：GCC_WARN_UNUSED_VARIABLE 将其设置为NO。

EDIT-2 示例：

BOOL ok = YES;
NSAssert1(ok, @"Failed to calculate the first day the month based on %@", self);

编译器显示ok 的未使用变量警告。

解决方案：

BOOL ok = YES;
#pragma unused(ok)
NSAssert1(ok, @"Failed to calculate the first day the month based on %@", self);

PS： 您还可以设置/重置其他警告： GCC_WARN_ABOUT_RETURN_TYPE：YES/NO

【讨论】：

更简单的方法是将__unused放在变量声明之前。

@mark-leonard 应该是一个单独的答案，我已经找了好几天了。我不得不开始阅读 cmets 出于绝望。谢谢。

【参考方案3】：

对于 gcc，你可以使用

#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wshadow-ivar"
// your code
#pragma GCC diagnostic pop

您可以了解 GCC pragma here 并获取警告的警告代码，请转到报告导航器 (Command+9)，选择最顶层的构建，展开日志（右侧的“=”按钮），然后滚动到底部，您的警告代码在方括号内，例如[-Wshadow-ivar]

对于铿锵声，你可以使用

#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Wshadow-ivar"
// your code
#pragma clang diagnostic pop

【讨论】：

Clang 支持 GCC 的 pragma 以与现有源代码兼容。所以你只需要写gcc格式的pragma。

从 Xcode 5.0 开始，Clang 是唯一提供的编译器。所以你现在可能需要使用 clang 格式的 pragma。

【参考方案4】：

为了抑制单个文件的警告，请执行以下操作：

在 xcode 项目中选择文件。 按获取信息 转到带有构建选项的页面 输入 -Wno- 否定警告：

-没有-

例如

-Wno-unused-parameter

如果您查看项目设置，您可以获得警告的名称查看位于构建选项卡页面底部的 GCC 警告，通过单击每个警告，它会告诉您警告参数名称：

例如

每当函数参数出现时发出警告 除了其声明外，未使用。 [GCC_WARN_UNUSED_PARAMETER， -Wunused-参数]

【讨论】：

这是一个很好的解决方案，当您从代码库中包含您不想修改的代码时，碰巧触发编译器警告...

看起来是个不错的方法，但是你知道如何在 XCode 4 中做到这一点

在这里找到我的 XCode 4 解决方案 ***.com/questions/6057192/…

如果您只需要对一个问题发出抑制警告，例如我的：...m:45:69: Incompatible pointer types sending... 我打开构建说明并找到此警告：[-Wincompatible-pointer-types] 我只是将其重命名为 -Wno-incompatible-pointer-types 并添加为标记到我的.m 文件...繁荣没有更多的警告...+10 如果我可以

【参考方案5】：

在 Objective-C 中，一些严重的错误只会以警告的形式出现。我不仅从不禁用警告，而且我通常会打开“将警告视为错误”(-Werror)。

可以通过正确执行操作（通常通过将对象转换为正确类型）或在需要时声明原型来避免代码中的每种类型的警告。

【讨论】：

虽然这是一个很好的一般建议，但它并不能回答问题。并非所有警告都是严重或严重的；许多都是微不足道的。假设一个人被要求使用第三方库并且不能修改它，无论出于何种原因（遗留代码库、旨在由第三方链接的代码、老板规定等）。在这些情况下，抑制特定的琐碎警告是完全可以接受的。

【参考方案6】：

要消除警告：尝试为有问题的对象创建一个类别界面

@interface NSTheClass (MyUndocumentedMethodsForNSTheClass)

-(id)theUndocumentedMethod;
@end
...

@implementation myClass : mySuperclass

-(void) myMethod 
...
   [theObject theUndocumentedMethod];
...

顺便说一句，我强烈建议不要在运输代码中调用未记录的方法。界面可以并且将会改变，这将是你的错。

【讨论】：

我也这样做。我将我的类别称为“Private”并将其放在 .m 文件的顶部...它用作转发声明仅在文件中使用的方法的一种方式。我同意私有头文件会更标准，但是必须不断地在文件之间跳转以获得真正应该完全包含（私有）到实现的东西是烦人的。

所以，事实证明，您可以使用旧的 C 技巧，即在使用该方法之前先实现该方法。然后你就有了一个文件本地方法。我认为它不是私有的，因此其他文件可能会向您以这种方式定义的选择器发送消息。

【参考方案7】：

http://nshipster.com/pragma/#inhibiting-warnings - 跳到禁止警告部分

【参考方案8】：

创建一个名为“Undocumented.h”的新的单独头文件并将其添加到您的项目中。然后为每个要调用未记录函数的类创建一个接口块，并为每个类分配一个“（未记录）”类别。然后只需在您的 PCH 中包含那个头文件。这样，您的原始头文件保持干净，只需要维护一个其他文件，并且您可以注释掉 PCH 中的一行以重新启用所有警告。

我也将此方法用于“Depreciated.h”中类别为“(Depreciated)”的折旧函数。

最好的部分是您可以通过注释或取消注释单个原型来选择性地启用/禁用单个警告。

【参考方案9】：

抑制该特定警告是不安全的。编译器需要知道参数的类型并返回一个方法来生成正确的代码。

例如，如果您正在调用这样的方法

[foo doSomethingWithFloat:1.0];

采用浮点数，并且没有可见的原型，那么编译器会猜测该方法采用双精度，而不是浮点数。这可能会导致崩溃和错误解释的值。在上面的例子中，在像 intel 机器这样的小端机器上，接收器方法会看到 0 通过，而不是 1。

您可以在i386 ABI docs 中了解原因，或者您可以修复您的警告。 :-)

【讨论】：

好建议，但实际上并没有像上面那样回答问题。