理解和解析来自 gcc 的警告

Posted

技术标签:

【中文标题】理解和解析来自 gcc 的警告【英文标题】:Understanding and parsing warnings from gcc 【发布时间】:2012-10-09 19:12:48 【问题描述】:

当通过M-x compile(运行文件夹的 Makefile)从 Emacs 编译 .cpp 文件时,我在编译缓冲区中看到以下内容(以编译模式显示):

In file included from: /path/to/file1:60,
  from /path/to/file2.h:15,
  from /path/to/file3.cpp:16: 

/path/to/file4.h:28:2: #warning 此文件包含至少一个已弃用或过时的标头,可以在没有 日后另行通知。请使用未弃用的接口 而是具有等效功能。更换清单 头和接口,请查阅文件backward_warning.h。到 禁用此警告使用-Wno-deprecated

除了实际的警告信息,我应该如何理解这个踪迹?即哪个文件产生了警告? (file1file2file3file4)? 另外,为什么file2行后面有一个逗号,file3行后面有一个冒号,file4行后面有两个用两个冒号隔开的数字?

我正在使用 Emacs 24.2.1,与 gcc-4.4.5-x86_64

【问题讨论】:

【参考方案1】:

实际触发警告的构造(在本例中为#warning 预处理器指令)在file4 中。上面的内容是#include 堆栈的踪迹,最里面但首先是一个:在这种情况下,file3 包括file2,其中包括file1,其中包括file4

当 gcc 知道触发诊断的构造的列号时,它会打印文件名、冒号、行号、另一个冒号和列号,正如您在 file4 行上看到的那样。第一个数字是行号(28),第二个数字是列号(在这种情况下,您会发现#warning# 在第2 列中)。当 gcc 知道列号时,它只打印文件名、冒号和行号。 #include 堆栈就是这种情况,因为它不需要记录 #include 指令的确切列。 Emacs 的编译模式理解如何解析这两种语法:你会发现如果你使用 C-x  ` 来翻阅诊断,当有可用的列号时,Emacs 会将光标放在适当的列。

这些报告末尾的冒号和逗号只是为了符合英文标点符号约定;它们没有任何意义。

【讨论】:

【参考方案2】:

    警告是在 file4.h 的第 28 行生成的。

    逗号是因为您在列表的中间,冒号表示列表的结尾。这两个数字是行号和列号。

【讨论】:

谢谢!为什么会有清单? “gcc”是否足够聪明,知道我从三个单独的文件中包含了file4.h? (file1, file2, file3)? 另外,为什么file3 的条目和file4 的条目之间有一个冒号(而不是逗号)? @user0000001:我修正了你的格式,以便更清楚为什么会有一个列表。您将获得完整的包含列表跟踪。【参考方案3】:

实际显示它的编译路径是这样说的:

in column 2 of line 28 of file4.h
that included from file1.h(line 60)
that included from file2.h(line 15)
that included from file3.cpp(line 16)
there was a warning ...

每个编译器都应该保持这个跟踪,它与 GCC 是否聪明或什么无关!! 由于您的编译器仅编译 file3.cpp,而其他所有文件都只会作为包含在该文件中的结果进行解析。

【讨论】:

以上是关于理解和解析来自 gcc 的警告的主要内容,如果未能解决你的问题,请参考以下文章

禁用所有 gcc 警告

为啥gcc会有一个long long的警告?

GCC 7,-Wimplicit-fallthrough 警告,以及清除它们的便携方式?

指定初始化器:GCC 警告消息:接近初始化和其他警告消息

DataTables 警告:无法解析来自服务器的 JSON 数据。这是由 JSON 格式错误引起的

如何在mingw-w64 gcc 7.1中无需警告地打印size_t?