I want the build to error out on trailing_whitespace. I have added trailing_whitespace: error to my .swiftlint.yml but it's still just showing up as a warning.
I've seen How to force error on SwiftLint instead of warnings? but that's about treating all warnings as errors, I want just selectively treat some rules as errors.
This works in your .swiftlint.yml file:
trailing_whitespace:
severity: error
I have two short files located in the same directory. The contents of each are shown below.
File test.cpp contains:
int main()
{
#include <test.h>
}
File test.h contains:
syntax_error
Upon compiling test.cpp with either g++ or clang++, I get an error which is expected.
test.cpp:3:11: error: 'test.h' file not found with <angled> include; use
"quotes" instead
#include <test.h>
^~~~~~~~
"test.h"
However, I also get a second error which seems to contradict the first error.
In file included from test.cpp:3:
./test.h:1:1: error: use of undeclared identifier 'syntax_error'
syntax_error
^
Essentially, the first error reports that the compiler cannot find the file test.h, and the second reports a syntax error in the file that the compiler reported it could not find.
These are the only two errors generated.
I understand why the compiler reports the first error and that I should use quotes with #include in this case. Why, though, does the compiler say it cannot find the file when it clearly has found it? And, why would it continue to report errors in the "unfound" file?
This is a feature, not a bug.
The idea is that if the error is trivial (like a missing semicolon), then the compiler will try to continue compiling as if you had already fixed the error. This enables you to fix multiple errors in one go. This is especially useful when compiling your code takes a long time.
Imagine fixing a missing semicolon, recompiling for five hours, just so that the compiler finds another missing semicolon. And then you have to recompile again. That would be very frustrating, no?
Basically, the compiler will try to recover from any errors as far as it is able to, to be able to report as much errors as possible. Most compilers have a flag for this.
Why, though, does the compiler say it cannot find the file when it clearly has found it?
The compiler found the file yes, that's why it gave you a hint to use "" instead of <>. If it hadn't, it might not have given you the hint. Still, the compiler is not allowed to compile your code correctly, because your code is ill-formed.
As an analogy, just because the compiler found a missing semicolon, that doesn't mean that it can just compile the code with that missing character (if it tries to be Standards compliant). It will however recover and try to find other errors, if any.
I have a __forceinline function that cannot be inlined when compiled as CLI (probably due to the specific restrictions to inlining that apply with .NET).
In debug, it is a warning and does not prevent me from building. But in release, it comes up as an error:
error C4714: function '...' marked as __forceinline not inlined
In the project configuration, Treat Warnings As Errors is set to No (/WX-), Treat Specific Warnings As Errors is empty (no value and no inherited value) and there is no /We option in the Command Line of the C/C++ section.
Thus, I don't understand why this warning comes up as an error.
And as it is an error it prevents me from building the project in release.
Do you have any clue on why this comes up as an error?
Any idea of how I could get rid of it, considering I cannot change the function nor its use (it comes from a library I'm using and I'd like not to alter)?
Thank you very much!
I have a program with many files and right now I have a huge bunch of compiler errors which I have a hard time understanding. The only line references I get are references to C++ libraries, such as algorithm or utility.
My question is: how am I supposed to know where the compiler error is? Some line in my code obviously generated an error in a C++ library, but where was it generated? Is there any way to get more info about the compiler errors? It's not like I can debug it, since it's in compile time.
EDIT: I realize this could be difficult to understand. Here are some examples of errors which I have modified for simplicity reasons.
(1) Here the error is on a line which includes std::string and I have no idea where it tries to do something with ClassY.
In file included from [my path]/ClassX.cpp:1:
In file included from [my path]/ClassX.h:4:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/string:439:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/algorithm:2123:24:
error: invalid operands to binary expression ('my project::ClassY *' and 'const my project::ClassY')
EDIT 2: problem solved. There were in total 31 error lines and note lines. I thought these had nothing to do with the above. However, they were all connected to one single line, which was referenced further down in the error messages:
myvec.erase(std::remove(myvec.begin(), myvec.end(), item), myvec.end());
Oracle version - 10.2.0.1.0
Pro*C/C++: Release 10.2.0.1.0
AIX version - 5.3
I cannot compile with the following errors.
Syntax error at line 135, column 2, file /usr/include/standards.h:
Error at line 135, column 2 in file /usr/include/standards.h
#warning The -qdfp option is required to process DFP code in headers.
.1
PCC-S-02014, Encountered the symbol "warning" when expecting one of the following:
a numeric constant, newline, define, elif, else, endif,
error, if, ifdef, ifndef, include, line, pragma, undef,
an immediate preprocessor command, a C token,
The symbol "newline," was substituted for "warning" to continue.
Syntax error at line 382, column 3, file mydb.h:
Error at line 382, column 3 in file mydb.h
time_t timestamp;
..1
PCC-S-02201, Encountered the symbol "time_t" when expecting one of the following
:
} char, const, double, enum, float, int, long, ulong_varchar,
OCIBFileLocator OCIBlobLocator, OCIClobLocator, OCIDateTime,
OCIExtProcContext, OCIInterval, OCIRowid, OCIDate, OCINumber,
OCIRaw, OCIString, short, signed, sql_context, sql_cursor,
struct, union, unsigned, utext, uvarchar, varchar, void,
volatile, a typedef name,
The symbol "enum," was substituted for "time_t" to continue.
Error at line 0, column 0 in file my_db.pc
PCC-F-02102, Fatal error while doing C preprocessing
make: *** [libdb.a] Error 1
Any solution?
pcscfg.cfg
sys_include=(/usr/include)
CODE=ANSI_C
parse=partial
sqlcheck=full
sys_include=/usr/include
sys_include=/usr/include/sys
sys_include=/usr/include/linux
include=$(ORACLE_HOME)/precomp/public
include=$(ORACLE_HOME)/precomp/include
include=$(ORACLE_HOME)/oracore/include
include=$(ORACLE_HOME)/oracore/public
include=$(ORACLE_HOME)/rdbms/include
include=$(ORACLE_HOME)/rdbms/public
include=$(ORACLE_HOME)/rdbms/demo
ltype=short
define=__64BIT__
define=_IBM_C
define=_LONG_LONG
The exactly same code is fine in AIX 5.2. The problem is occurred in AIX 5.3.
The first error reported, PCC-S-02014, is actually the important one. The Pro*C precompiler ignores some C preprocessor directives, but not #warning - it doesn't understand it, and doesn't think warning is a valid thing to have after a #.
You can use the ORA_PROC macro to avoid problematic header files being included at this stage. Assuming the location given in a previous answer is right, you can 'hide' the #include from the preprocessor like this:
#ifndef ORA_PROC
#include <standards.h>
#endif
Of course you may not be including that file directly, so you might have to work out the heirarchy to see which file you really need to exclude in your source file. In your case it looks like you could maybe hide mydb.h within your my_db.pc file, but that seems excessive; it might be better to hide standard.h within your mydb.h file - basically exclude the minimum amount of code you can. I'm speculating from the error messages though, you may have more layers.
This is covered in the advanced topics section of the Pro*C/C++ documentation.
This is easier than copying and editing the system header file, and much safer than editing the original. It also allows you to add comments explaining what's happening, of course.
This problem is usually occurred in AIX 5.3 and above. The /usr/include/standards.h is different from older version and I think PCC is somehow not able to compile.
To fix that issue, you have to change the followings in standards.h.
FROM
---
#if defined(__IBM_PP_WARNING)
#warning The -qdfp option is required to process DFP code in headers.
#else
#error The -qdfp option is required to process DFP code in headers.
TO
--
//#if defined(__IBM_PP_WARNING)
//#warning The -qdfp option is required to process DFP code in headers.
//#else
#if !defined(__IBM_PP_WARNING)
#error The -qdfp option is required to process DFP code in headers.
I suggest not to change the system include file. So, copy standards.h file into your project directory, fix and use it.