flycheck或任何其他使用compile_commands.json的linter如何找到标准库的源代码？他们如何确定语言标准？是通过为clang指定的标准标志还是其他方式？我可以在compile_commands.json中更改这个标志吗，比如c11更改为c17，与缺少std：：optional相关的错误就会消失，因为它会把它们拉出来？当然，前提是代码已经编译并且compile_commands文件已经生成！编译器会影响这些源代码吗？也就是说，他的目录中的某个虚幻引擎的clang/clang++编译器是一个经过大量修改的版本，如果我将编译器更改为编译器中的UE源代码编译器，对于一个与UE完全无关并且完全使用第17标准的项目，会发生什么？
1条答案
按热度按时间laawzig21#
我想你误解了文件的作用。该文件不是由编译器生成的，而是由生成工具生成的。这并不意味着编译发生了，也不传递给编译器。
compile_commands.json存储了构建工具在构建过程中将要执行的确切命令。如果传递了相同的标志，则链接器应该执行被调用的编译器所执行的操作。这当然不是小事。有些linters可能只查找特定的标志，有些可能做更多的工作。LLVM工具集与文件非常好地集成在一起- clang-tidy和clangd都大量使用它，并且他们内部知道clang会做什么。但对于大多数链接，我认为重要的标志是包含路径和语言标准。
怎么...找到标准库的来源吗
与编译器的方式相同--存在搜索标准库的系统路径。
他们如何确定语言标准？
从
-std=XXX标志。我可以在compile_commands.json中更改这个标志吗，比如c11更改为c17，与缺少std：：optional相关的错误就会消失，因为它会把它们拉出来？
是的，因为就linter所知，你会在构建过程中使用c++17。
当然，前提是代码已经编译并且compile_commands文件已经生成！编译器会影响这些源代码吗？
不，
compile_commands.json不是由编译器生成的，正如前面解释的那样。该文件可用于调用构建命令。如果我在compile_commands中将编译器更改为UE源代码中的编译器，而该项目与UE完全无关，并且完全使用第17个标准？
然后，linter会认为这是你打算编译你的代码的编译器，不管这是linter关心的是另一回事。