理解和解析来自 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
。
file1
、file2
、file3
或 file4
)?
另外,为什么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 7,-Wimplicit-fallthrough 警告,以及清除它们的便携方式?