more code completion fun!

[christopher j bottaro]

phew, after attempting it with regular expressions, then moving on to lex and 
yacc, i've finally gotten somewhere after ditching all that and writing an 
LL(k) grammer for use with ANTLR 2.0.  so far the grammer can parse method 
definitions include parameter and local variable declarations.  the grammer 
recognizes scope and parses to remember the scope where the var was defined.  
for example...

virtual const char* SomeClass::AnotherClass::AMethod(int& x, char y)	{

	// scope 1a
	{
		QString var;
	}

	// scope 1b
	{
		QPoint var;
		
		// scope 2a
		{
			QRect var;
		}
	}

}

the method will be parsed, including its return type, qualified name, and 
parameters.  then codeblocks will be parsed including their begin and end 
lines and all variable declarations enclosed in them will be parsed.

after the parsing, it shouldn't be too hard to determine the line number that 
the cursor is currently on, determine what scope that falls in, then search 
the QDict of that scope for what ever variable you want completion for, get 
its type, look up its type in KDevelop's classstore, then populate a listbox 
full of members.

so far i've just tested it by building a parser outta the grammer and running 
it in a console program on kwview.cpp which is 70k.  it parses and prints out 
the results to cout in less than a second on a p2 600.

i suppose the real challenge is resolving function calls and pointer derefs?  
anyone have any suggestions?

also, when i compile my grammer, i get like over a page of non-determinisms, 
but they don't seem to matter at all...  here are some of the ones that 
bother me...

primary_expr
	:	(scope)? IDENTIFIER
	|	INTEGER (DOT INTEGER)?  // non-determinism here
	|	STRING_LIT
	|	CHAR_LIT
	|	OP expression CP
	;

// this rule is fine...
postfix_expr
	:	primary_expr	(	(OP (arg_expr_list)? CP)
				|	(OSB expression CSB)
				)?
				(	((DOT|PTR) postfix_expr)
				)?
	;

// this whole thing apperent causes a lot of non determinisms
unary_expr
	:	(unary_op|INCR|DECR)* postfix_expr
	|	"sizeof" OP returntype CP
	|	"sizeof" postfix_expr
	;

cast_expr
	:	(OP returntype CP)? unary_expr  // non determinism here
	;

anyways, antlr is great, maybe the class parser should be rewritten using it. 
 its cool how rules can have return types and take arguments and throw 
exceptions and such.  its a lot more pleasureable writing an LL(k) grammer 
also.  god, i wish i hadn't have dropped my automata theory class.

tell me what you all think...potentially useful?

christopher

-
to unsubscribe from this list send an email to kdevelop-request at kdevelop.org with the following body:
unsubscribe »your-email-address«