I'm trying to run clang-tidy on my IAR project, but I would like to ignore system header files. I tried the solutions provided here but they didn't work (read on for the results). Here's my project structure:
Proj
----Src
----Inc
SysHdrs
And this is my clang-tidy command from inside Proj:
clang-tidy.exe Src/*.c -header-filter=Proj\\Inc\\.* -checks=* -- -I"abs/path/to/Proj/Inc" -isystem"abs/path/to/SysHdrs"
I'm getting warnings on my Src files, as well as on some SysHdrs files such as SysHdrs/DLib_Defaults.h and SysHdrs/yvals.h. For example:
abs/path/to/SysHdrs/DLib_Defaults.h:563:6: error: "Compiler must support __weak" [clang-diagnostic-error]
#error "Compiler must support __weak"
^
abs/path/to/SysHdrs/yvals.h:37:4: error: "DLib compiled with wrong (version of IAR) compiler" [clang-diagnostic-error]
#error "DLib compiled with wrong (version of IAR) compiler"
^
abs/path/to/SysHdrs/yvals.h:232:11: error: unknown type name '__WCHAR_T_TYPE__' [clang-diagnostic-error]
typedef __WCHAR_T_TYPE__ _Wchart;
abs/path/to/SysHdrs/yvals.h:358:3: error: expected identifier or '(' [clang-diagnostic-error]
__WEAK __ATTRIBUTES void __iar_Locksyslock_Malloc(void);
^
Note that I do need to supply the system headers to clang, because otherwise it'd complain about a missing stdio.h / string.h etc.
As far as I know the -header-filter should filter out whatever doesn't match the regex pattern, so my system headers shouldn't be included in the outuput. Further, I've explicitly set the SysHdrs as "system headers" by using the -isystem identifier.
I even tried -header-filter=main\.h and it still processes the system headers.
Anything else I can try?
Related
I have some HDF5 C code that I am trying to port to C++Builder. I am getting this error at build time:
[ilink64 Error] Error: Unresolved external 'H5check_version' referenced from D:\DELPHITOOLS\PASHDF\C\WIN64\DEBUG\FILE2.O
H5check_version is included in H5public.h as a macro.
Why does C++Builder not find this?
H5check_version is included in H5public.h as a macro.
If that were true, you would not be getting a linker error, since macros are handled only during the preprocessor stage.
Somewhere in your project, the compiler is seeing a declaration of H5check_version as a function, and your file2 unit is calling it as a function, but the linker can't find the implementation of that function, hence the error.
Your project needs to contain a reference to the appropriate .lib file that either implements the actual function (static linking) or tells the linker which DLL the function is exported from (dynamic linking).
C/C++ is case sensitive, so H5check_version is different from H5Check_version.
AFAIK pascal is not case sensitive at all.
Regards
First question here.
I have some troubles with the XCode Build System, specifically with preprocessor definitions.
I'm trying to define a macro for the objective-c runtime to avoid enforcing the dispatch functions to be cast to an appropriate function pointer type. The usual way to go would be to use #define OBJC_OLD_DISPATCH_PROTOTYPES and then include the header on the next line. Once the header gets included, the macro is already defined and the header is configured accordingly.
But that's where it starts to get weird!
The macro is not recognized at all and the header gets included as if the #define statement was not there so it fails to #define OBJC_OLD_DISPATCH_PROTOTYPES and it gets (re?)defined as 0.
main.c
#include <stdio.h>
#define OBJC_OLD_DISPATCH_PROTOTYPES 1
#include <objc/objc-runtime.h>
int main(int argc, const char * argv[]) {
// From there:
// - Build System: OBJC_OLD_DISPATCH_PROTOTYPES is always 0, except if defined in build settings
// - Clang (only): OBJC_OLD_DISPATCH_PROTOTYPES is 1
printf("%d\n", OBJC_OLD_DISPATCH_PROTOTYPES);
}
The build system acts as expected when the preprocessor macro is defined in the project build settings under the "Apple Clang - Preprocessing" section. It defines the global macro using the -D parameter of clang making it available to any files used by the project.
However, source code compiles correctly when I use clang from a terminal using clang main.c.
Could someone tell me what I need to configure for the build system to behave normally?
It gives a warning when building with Xcode IDE:
Ambiguous expansion of macro 'OBJC_OLD_DISPATCH_PROTOTYPES'
and the output is indeed 0 using Xcode directly, but 1 with clang main.c. The difference is that Xcode uses clang with enabled modules by default: You get the same warning on the command line if you enable modules there:
clang -fmodules main.c
Solution
In Xcode, select the target, go to the "Build Settings" tab and in the "Apple Clang - Language - Modules" section, switch the "Enable Modules (C and Objective-C)" entry to 'NO':
Then you get the expected result in both cases, regardless of whether you use Xcode or Clang on the command line.
Explanation:
If you use modules the following happens:
instead of the preprocessor including the text and compiling the result, a binary representation of the module is used
modules are (independently) precompiled, i.e. they use the definitions from the time the module was precompiled
consequently, preprocess definitions from the code before the include/import statement have no effect on the module (nor on other imported modules).
if modules are enabled, not only #imports are affected, but also #includes are translated into module imports under the hood
So you have a contradictory definitions for the OBJC_OLD_DISPATCH_PROTOTYPES.
The precompiled module uses a 0 for OBJC_OLD_DISPATCH_PROTOTYPES and you redefine it as 1.
BTW: if you use
#define OBJC_OLD_DISPATCH_PROTOTYPES 0
then you use the same definition that the precompiled module is using and therefore there is no warning about an ambiguous expansion of the macro even if modules are enabled.
Without enabled modules, the preprocessor includes the text, compiles the result and returns the expected result, i.e. in objc.h the desired typedef are used.
I am using the clang compiler on windows. I used the installer from the LLVM website. Sometimes it gives me a compiler error.
clang -I./include main.c CoreFoundation.dll
it gives:
In file included from main.c:4:
In file included from ./include\CoreFoundation/CFNumberFormatter.h:110:
./include\CoreFoundation/CFXMLParser.h:159:81: error: unknown type name 'CFXMLNodeRef'
typedef void * (*CFXMLParserCreateXMLStructureCallBack)(CFXMLParserRef parser,
CFXMLNodeRef nodeDesc, void *info);
...
and sometimes this..
In file included from main.c:4:
In file included from ./include\CoreFoundation/CoreFoundation.h:86:
./include\CoreFoundation/CFDateFormatter.h:104:105: error: unknown type name 'CFDateRef'; did you mean 'CFDataRef'?
CFStringRef CFDateFormatterCreateStringWithDate(CFAllocatorRef allocator, CFDateFormatterRef formatter, CFDateRef date) AVAILABLE_MAC_OS_X_VERSION_10_3_AND_LATER;
...
...and other similar warnings, seemingly randomly choosing where to stop. Sometimes it compiles through without error. When it gives an error, they seem to be be about not finding a symbol from an included file. It doesn't complain about not finding the file. But it doesn't consistently stop at the same point and sometimes compiles successfully.
I can reproduce this "error" under Linux with gcc. I even get the "report this compiler bug pls" message.
When it gives an error, they seem to be be about not finding a symbol from an included file
You can get this:
if you compile with multiple threads (eg. make -j8)
if you abort the compile and then start it again without "cleaning" all obj files
if you compiled your source, changed something and compile without "cleaning"
if your compiler/make/build process changes the order every time... (had this with cmake and opencv 3 source)
I am new to static checking and I am assigned a task to do static checking of C code. I am given the liberty to select any one tool keeping in mind that the organisation already uses lint so a lint based tool should be preferred.
I selected splint because it is a free software. (PC lint and Lint being commercial)
Now I tried compiling a simple C file which had #include <unistd.h>
Splint shows error:
/usr/include/unistd.h:221:26: Parse Error:
Suspect missing struct or union keyword: __ssize_t :
int. (For help on parse errors, see splint -help parseerrors.)
Cannot continue.
How can I get this working?
I read in some places that splint doesn't support C99 standard whereas some says it supports. Can anyone tell me whether I should reconsider my choice as I will be using C99 format. What are the other free alternatives which are very similar to lint/splint?
I am trying to add a preference bundle to a tweak I am building. I followed the part of this tutorial where they add the preference bundle. After I tried adding the preference bundle, my tweak fails to compile with the following error:
Making all for tweak MyTweak...
Preprocessing Tweak.xm...
Compiling Tweak.xm...
Linking tweak MyTweak...
Stripping MyTweak...
Signing MyTweak...
Making all in prefs...
Making all for bundle prefs...
Copying resource directories into the bundle wrapper...
Compiling prefs.mm...
cc1objplus: warnings being treated as errors
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk/System/Library/PrivateFrameworks/Preferences.framework/Headers/PSListController.h:9,
from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk/System/Library/PrivateFrameworks/Preferences.framework/Headers/PSLocaleController.h:8,
from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk/System/Library/PrivateFrameworks/Preferences.framework/Headers/Preferences.h:9,
from prefs.mm:1:
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk/System/Library/PrivateFrameworks/Preferences.framework/Headers/PSViewController.h:47: warning: property ‘specifier’ type does not match protocol ‘PSController’ property type
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk/System/Library/PrivateFrameworks/Preferences.framework/Headers/PSViewController.h:47: warning: property ‘rootController’ type does not match protocol ‘PSController’ property type
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk/System/Library/PrivateFrameworks/Preferences.framework/Headers/PSSetupController.h:7,
from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk/System/Library/PrivateFrameworks/Preferences.framework/Headers/PSInternationalLanguageSetupController.h:7,
from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk/System/Library/PrivateFrameworks/Preferences.framework/Headers/Preferences.h:24,
from prefs.mm:1:
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk/System/Library/PrivateFrameworks/Preferences.framework/Headers/PSRootController.h:71: warning: property ‘specifier’ type does not match protocol ‘PSController’ property type
make[3]: *** [obj/prefs.mm.ade1d157.o] Error 1
make[2]: *** [internal-bundle-all_] Error 2
make[1]: *** [prefs.all.bundle.variables] Error 2
make: *** [internal-all] Error 2
Any ideas?
Thanks.
Your versions of the headers may be messed up, since they're Private Framework headers, not official Apple headers.
Two possible solutions:
Redownload the headers from a better source. rpetrich's versions are often recommended.
If that doesn't work, edit the headers manually to fix the problem. Find the header containing the PSController protocol (probably PSController.h), check what type specifier is supposed to be, and then make the change in PSViewController.h. I believe I had to do something like this the first time I was dealing with Preference Bundles.