Developer forums (C::B DEVELOPMENT STRICTLY!) > CodeCompletion redesign
New parser model for Code completion
grv575:
--- Quote from: TDragon on December 23, 2005, 07:34:49 pm ---- Open MSys, go to the antlr directory, run "./configure --disable-examples" (I added "--prefix=/path/to/antlr-dir" because I wasn't sure where the default was)
- Run "make install"
--- End quote ---
See right here is where I get errors about not being able to build Makefile.in. Could you post your `echo $PATH` in msys?
anonuser:
Alright I've got me antlr going and a working C++ grammer file.
Now just need to work with the AST it gives me.
TDragon:
$ echo $PATH
.:/usr/local/bin:/mingw/bin:/bin:/mingw/bin:/e/PHP:/e/WINDOWS/system32:/e/WINDOWS:/e/WINDOWS/System32/Wbem:/e/Program Files/ATI Technologies/ATI Control Panel:.:/e/Program Files/doxygen/bin:/e/Python24:/e/Program Files/CVSNT/
grv575:
Thanks TDragon. It turned out to be something wrong with my msys configuration. Reinstalling mingw and msys fixed things. So getting antlr running wasn't so bad on mingw after all. I didn't just use the supplied Main.cpp because I wanted to see how easy it would be to generalize that part for other parsers (as long as there is a .g file for the parser definition). Tried to use sa few of the C++ specific extensions to antlr which were written as possible (e.g. no modding the antlr source to support his tracing extensions). So it looks like modifying antlr.2.76 is not necessary at all - just build it first and then the c++ grammer does plug in fairly nicely. Steps to get the parser working:
--- Code: ---install mingw & msys:
binutils-2.16.91-20050827-1.tar.gz
extra.zip
gcc-core-3.4.4-20050522-1.tar.gz
gcc-g++-3.4.4-20050522-1.tar.gz
gdb-6.3-2.exe
mingw-runtime-3.9.tar.gz
mingw-utils-0.3.tar.gz
mingw32-make-3.80.0-3.tar.gz
MSYS-1.0.10.exe
w32api-3.5.tar.gz
extract all the archives to C:\MinGW, run the gdb installer, run the msys installer (use C:\MinGW for the postinstall prompt)
extract CPP_parserV3.1
copy CPP_parser.g, CPPDictionary.hpp, Dictionary.hpp, DictEntry.hpp, Dictionary.cpp, CPPSymbol.hpp, Support.cpp to a new folder test_folder
download antlr-2.7.5.exe to test_folder
comment out all lines in CPP_parser.g dealing with antlrTrace()
run antlr-2.7.5.exe CPP_parser.g
run msys
extract antlr-2.7.6.tar.gz
run ./configure --disable-examples && make && make install
change back to test_folder
create test.cpp:
---
#include <iostream>
#include <string>
#include "CPPLexer.hpp"
#include "CPPParser.hpp"
ANTLR_USING_NAMESPACE(std)
ANTLR_USING_NAMESPACE(antlr)
// The following data used by process_line_directive(char*,int) below
// I believe this data and function have to be at this level so as to
// be available to both CPPLexer and CPPParser (and Support.cpp)
int this_line = 0; // current line
int deferredLineCount = 0;
int include_line = 0; // include file's line number
int include_last_set = 0; // where included file's line number was last set
char currentIncludedFile[128]; // path and name of current included file
int principal_line = 0; // principal file's line number
int principal_last_set = 0; // where principal file's line number was last set
char principal_file[128]; // path and name of principal file
bool in_user_file = false; // true if we are inside the users's source file
int main()
{
try
{
CPPLexer lexer(cin);
CPPParser parser(lexer);
parser.init();
parser.translation_unit();
}
catch (exception& e)
{
cerr << "exception: " << e.what() << endl;
}
}
// Needed for #line_number directives generated by gcc -E preprocessing or msvc preprocessing
void process_line_directive(const char *includedFile, const char *includedLineNo)
{
// See global interface variables above
// Working variables
static int line, result;
static bool principal_file_set = false;
static int x;
//printf("Main entered\n");
// Extract included file line no.
result = sscanf(includedLineNo, "%d \n", &line);
//printf("Main: line %d\n",line);
// remove first " from file path+name by shifting all characters left
for(x=1;includedFile[x]!='"';x++)
{
currentIncludedFile[x-1] = includedFile[x];
}
// Check path and name are not too long
if(x>128)
{
//
printf("Path and name of included file too long\n");
printf("Increase length of currentIncludedFile and\n");
printf(" principal_file to at least %d characters\n",x);
printf("Abandon run\n");
getchar();
}
// Replace last " from file name with null
currentIncludedFile[x-1] = NULL;
if (!principal_file_set)
{
strcpy (principal_file, currentIncludedFile);
principal_file_set = true;
}
// check for main file name
if (strcmp(principal_file, currentIncludedFile) == 0)
{
principal_line = line;
principal_last_set = this_line;
strcpy(currentIncludedFile, " "); // delete include file name
in_user_file = true; // we are processing users's .C or .CPP file (aka principal_file)
}
else
// Check that this is a genuine path
if(currentIncludedFile[1]==':')
{//printf("main.cpp 222 entered\n");
//printf("main.cpp 223 %s %s\n",principal_file,currentIncludedFile);
include_line = line;
include_last_set = this_line;
in_user_file = false; // we are processing a header file
}
}
---
Then compile:
gcc -I/usr/local/include -L/usr/local/lib *.cpp -lstdc++ -lantlr
To test:
run ./a.exe < Quadratic.i (msvc preprocessor processed file)
(gcc -E preprocesses in gcc although not fully supported yet - need to add gcc __attribute__ specifiers and __builtin_va_list to the basic types in the CPP_parser.g grammar)
--- End code ---
So it looks fairly complete as a c++ parser. What would be best is if the grammar is modified to fully support gcc -E for handling preprocessing. This way there's no bugs as well - tried and true tools like the gcc preprocessor are used to handle #includes, etc. So code completion would be robust since it would have all the correct symbols defined in the current source file. And then you could just do gcc -E *.cpp for all cpp project files if global code completion is enabled.
takeshimiya:
I would recommend to use a library for pre-processing:
C/C++ pre-processor parsers:
ucpp
Wave
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version