I am building an ASTMatcher-based tool that I would like to run over my sources:
int main(int argc, const char** argv) {
CommonOptionsParser OptionsParser(argc, argv, MyToolCategory);
ClangTool Tool(OptionsParser.getCompilations(),
OptionsParser.getSourcePathList());
MatchFinder Finder;
// Repeated calls to Finder.addMatcher(...);
Tool.run(newFrontendActionFactory(&Finder).get());
// Handle the results of the matching.
}
Running this over a source file that depends on other headers yields the following error:
~$ /path/to/my/tool /path/to/my/file.cpp --
/path/to/my/file.cpp:8:10: fatal error: 'string' file not found
#include <string>
^~~~~~~~
1 error generated.
Error while processing /path/to/my/file.cpp.
I do not want to include any other headers in this processing, lest my matchers find content in those headers that I do not want to handle.
I tried passing -fsyntax_only to the tool, but I get the same result as above:
~$ /path/to/my/tool /path/to/my/file.cpp -- -fsyntax-only
I noticed in the ASTMatcher tutorial that there is a clang::SyntaxOnlyAction. However, I have been unable to figure out how MatchFinder and SyntaxOnlyAction can be used in conjunction with one another. Likewise, I have been able to do an AST dump from the command line of the same file, no problem, so I know it's possible.
Is it possible to configure a MatchFinder-based tool to honor the syntax-only behavior?
Related
I'd like to compile the following C++ snippet using threads with Emscripten
#include <cstdio>
#include <thread>
void foo() { puts("foo\n"); }
void bar(int x) { printf("bar %d\n", x); }
int main(int argc, char* argv[]) {
std::thread first(foo);
std::thread second(bar, 123);
puts("main, foo and bar now execute concurrently...\n");
first.join();
second.join();
puts("foo and bar completed.\n");
}
To get Emscripten to use threads I pass the "-s USE_PTHREADS=1" option during compilation and linking
target_compile_options(
Emscripten PRIVATE -v "SHELL:-s USE_PTHREADS=1 -s PTHREAD_POOL_SIZE=8")
target_link_options(
Emscripten PRIVATE -v --emrun
"SHELL:-s MINIFY_HTML=0 -s USE_PTHREADS=1 -s PTHREAD_POOL_SIZE=8")
I also change the suffix of the compilation output to .html which leads to Emscripten directly producing a .html page
set(CMAKE_EXECUTABLE_SUFFIX ".html")
So far so good. The snippet compiles as expected and I can see the toolchain passing some pthread arguments on the command line.
In order to test the output I fire up a webserver with python and open the .html page with Firefox. The Firefox option javascript.options.shared_memory was enabled by default in my version (78.0.1) so I thought that my code should work out of the box. Sadly this isn't the case and I'm getting Uncaught ReferenceError: SharedArrayBuffer is not defined exceptions thrown at me through the console.
Testing the code with node works though:
$ node --experimental-wasm-threads --experimental-wasm-bulk-memory Emscripten.js
main, foo and bar now execute concurrently...
foo
bar 123
foo and bar completed.
/edit
Ok, seems like SharedArrayBuffer still undergoes some standardization process...
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer/Planned_changes
After compiling an application with clang 3.6 using -fsanitize=undefined,
I'm trying to start the instrumented program while using a suppression file to ignore some of the errors:
UBSAN_OPTIONS="suppressions=ubsan.supp" ./app.exe
The suppression file ubsan.supp contains:
signed-integer-overflow:example.c
This leads to an error message:
UndefinedBehaviorSanitizer: failed to parse suppressions
The same occurs with a gcc 4.9 build.
The only documentation I can find is http://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html, which is for clang 3.9, while I use 3.6 (which doesn't have documentation for ubsan included).
Can anyone provide working examples for ubsan suppression files, that work in clang 3.6?
Edit: By browsing the source code of ubsan, I found that the only valid suppression type might be "vptr_check" - dunno which version I was looking at though.
Can anyone confirm that in clang 3.9 more suppression types are available?
I didn't spend the time to find out exactly which suppressions were available in clang-3.6, but it appears that in clang-3.7 only vptr_check is available as a suppression. Starting in clang-3.8, the suppressions list is defined to be the list of checks, plus vptr_check.
In clang-3.9 the checks available are:
"undefined"
"null"
"misaligned-pointer-use"
"alignment"
"object-size"
"signed-integer-overflow"
"unsigned-integer-overflow"
"integer-divide-by-zero"
"float-divide-by-zero"
"shift-base"
"shift-exponent"
"bounds"
"unreachable"
"return"
"vla-bound"
"float-cast-overflow"
"bool"
"enum"
"function"
"returns-nonnull-attribute"
"nonnull-attribute"
"vptr"
"cfi"
"vptr_check"
I'd tried it by creating three files, compile.sh, main.cpp and suppressions.supp as shown below. The unsigned-integer-overflow is not a part of undefined that's why it needs to be included specifically. This works on my machine with clang-3.9.
So, I'd guess more suppression types are valid in clang-3.9.
# compile.sh
set -x
UBSAN_OPTIONS=suppressions=suppressions.supp:print_stacktrace=1 #:help=1
export UBSAN_OPTIONS
clang++-3.9 -g -std=c++11 -fsanitize=undefined -fno-omit-frame-pointer -fsanitize=unsigned-integer-overflow main.cpp
./a.out
// main.cpp
#include <bits/stdc++.h>
#include <bits/stl_tree.h>
using namespace std;
int main(int argc, char **argv) {
unsigned int k = UINT_MAX;
k += 1;
return 0;
}
# suppressions.supp
unsigned-integer-overflow:main.cpp
I am having trouble writing a bison parser, and unexpectedly ran into difficulties getting the parser to print debug information. I found two solutions on the web, but neither seems to work.
This advocates to put this code in the main routine:
extern int yydebug;
yydebug = 1;
Unfortunately the C++ compiler detects an undefined reference to `yydebug'.
This suggests putting
#if YYDEBUG == 1
extern yydebug;
yydebug = 1;
#endif
into the grammar file. It compiles but does not produce output.
What does work is to edit the parser file itself, replacing
int yydebug;
by
int yydebug = 1;
The big disadvantage is that I have to redo this every time I change the grammar file, which during debugging would happen constantly. Is there any other way I can provoke the parser into coughing up its secret machinations?
I am using bison v2.4.1 to generate the parser, with the following command-line options:
bison -ldv -p osil -o $(srcdir)/OSParseosil.tab.cpp OSParseosil.y
Although the output is a C++ file, I am using the standard C skeleton.
With bison and the standard C skeleton, to enable debug support you need to do one of the following:
Use the -t (Posix) or --debug (Bison extension) command-line option when you create your grammar. (bison -t ...)
Use the -DYYDEBUG=1 command-line option (gcc or clang, at least) when you compile the generated grammar (gcc -DYYDEBUG=1 parser.tab.c ...`).
Add the %debug directive to your bison source
Put #define YYDEBUG 1 in the prologue in your bison source (the part of the file between %{ and %}.
I'd use -t in the bison command line. It's simple, and since it is Posix standard it probably will also work on other derived parser generators. However, adding %debug to the bison source is also simple; while it is not as portable, it works in bison 2.4.
Once you've done that, simply setting yydebug to a non-zero value is sufficient to produce debug output.
If you want to set yydebug in some translation unit other than the generated parser itself, you need to be aware of the parser prefix you declared in the bison command line. (In the parser itself, yydebug is #defined to the prefixed name.) And you need to declare the debug variable (with the correct prefix) as extern. So in your main, you probably want to use:
extern int osildebug;
// ...
int main(int argc, char** argv) {
osildebug = 1;
// ...
}
If you're using bison, your best place to find information is the bison manual; most of the above answer will be found in that page.
I'm following the instructions in How to build applications with OpenCV inside the Microsoft Visual Studio but I'm getting errors from the sample code:
error C2065: 'CAP_PROP_FRAME_WIDTH' : undeclared identifier
error C2065: 'CAP_PROP_FRAME_HEIGHT' : undeclared identifier
error C2065: 'CAP_PROP_FRAME_COUNT' : undeclared identifier
I think the identifiers that are undeclared should be declared in highgui so why am I not getting them despite the demo code's #include <opencv2/highgui/highgui.hpp>?
Here are the steps I have taken.
I've unpacked the OpenCV (Version 2.4.6) files into C:\OpenCV, run setx -m OPENCV_DIR C:\OpenCV\Build\x64\vc11 from an elevated command prompt and added %OPENCV_DIR%\bin to my path (following instructions in Installation in Windows). Then using the Property pages (View -> Property Pages or Shift-F4) set to 'All Configurations'
I've added $(OPENCV_DIR)\..\..\include to my C/C++ Additional Include Directories
I've added $(OPENCV_DIR)\lib to the linker Additional Library Directories
I've cut-an-paste the directory listing of the lib files in C:\OpenCV\build\x64\vc11\lib into my input Additional Dependencies
I've copied the sample code from the article into a new C++ console app (with ATL). I had to change one line in the template code from int _tmain(int argc, _TCHAR* argv[]) to int _tmain(int argc, char* argv[])
I think the identifiers that are undeclared should be (are) declared in highgui so why am I not getting them despite the demo code's #include <opencv2/highgui/highgui.hpp>?
Other people having similar issues getting this sample code working in the How to build applications with OpenCV inside the Microsoft Visual Studio note seem to fall over with link errors (e.g. here and here) but I am getting past the linker.
========== EDIT ==========
There appear to be more insurmountable difficulties with the sample code. It is documented as a simple example to load and display an image whose path is supplied as the sole argument to main, while the code listing itself is video code requiring four command line arguments (i.e. it first checks and stops if argc != 5). I've submitted a documentation bug. I think the sample code listing should have been be taken from this: https://github.com/Itseez/opencv/blob/master/samples/cpp/tutorial_code/introduction/display_image/display_image.cpp
Try with CV_CAP_ or cv::CAP_... It looks like there were some changes aiming to improve consistency of constants in OpenCV...
I am using the opencv 2.4.6 and this has helped me do the trick
change CAP_PROP_FRAME_WIDTH into CV_CAP_PROP_FRAME_WIDTH
change CAP_PROP_FRAME_HEIGHT into CV_CAP_PROP_FRAME_HEIGHT
change CAP_PROP_FRAME_COUNT into CV_CAP_PROP_FRAME_COUNT
and similarly if there are any other cap prop keywords into cv cap prop keywords
try this.
I have started learning OpenCV.
I am working on linux.
From their documentation page I was able to compile this
http://docs.opencv.org/doc/tutorials/introduction/linux_gcc_cmake/linux_gcc_cmake.html#linux-gcc-usage
However after that I got lost in trying to declare a new mat and it's constructors.
SO I decided to go with this book http://www.amazon.com/Learning-OpenCV-Computer-Vision-Library/dp/0596516134
However I am not able to compile the very first program from this book.
The program is here :
#include "highgui.h"
int main(int argc, char** argv)
{
IplImage* img = cvLoadImage (argv[1]);
cvNamedWindow("Example1", CV_WINODW_AUTOSIZE);
cvShowImage("Example1",img);
cvWaitKey(0);
cvReleaseImage(&img);
cvDestroyWindow("Example1");
}
I saved this in a file named load.c
Then I created a CMakeLists.txt file and put this in it :
project( load )
find_package( OpenCV REQUIRED )
add_executable( load load )
target_link_libraries( load ${OpenCV_LIBS} )
when running "cmake ." from terminal it is succesful. But when I am running "make" it gives me this error :
Scanning dependencies of target load
[100%] Building C object CMakeFiles/load.dir/load.o
/home/ishan/load/load.c: In function ‘main’:
/home/ishan/load/load.c:4:2: error: too few arguments to function ‘cvLoadImage’
/usr/local/include/opencv2/highgui/highgui_c.h:212:18: note: declared here
/home/ishan/load/load.c:5:28: error: ‘CV_WINODW_AUTOSIZE’ undeclared (first use in this function)
/home/ishan/load/load.c:5:28: note: each undeclared identifier is reported only once for each function it appears in
make[2]: *** [CMakeFiles/load.dir/load.o] Error 1
make[1]: *** [CMakeFiles/load.dir/all] Error 2
make: *** [all] Error 2
I think it is because this example in the book is for OpenCV 1.x while I am currently running 2.4.3, however I believe there must be a way to run this program and the subsequent program that are in the book.
I think the problem lies with linking the header files properly.
I would like to first read from the book and using reference from documentation and then switch to documentation fully. But for now I wish to learn from the book as learning from the book is far easier to me than documentation. Plus I bought this book for approx 3000 INR and got it just today, I don't want to see it go to waste. I want to learn from it.
Please help me out.
CV_WINODW_AUTOSIZE is mispelled. The correct constant is CV_WINDOW_AUTOSIZE
cvLoadImage (argv[1]); should be cvLoadImage (argv[1], 1); (for loading a color image) because the C standard does not support default arguments.
By the way, if you're using OpenCV 2.0+, I recommend learning the C++ API. It's a lot less convoluted than the C API and performance is comparable.