RE: [cdt-dev] Parsing code under inactive #if or #ifdef

["Brunauer, Walter" <Walter.Brunauer@xxxxxxxxxxxxx>]

Hi,
 
and then there is the probably even more complex part that is not even
known to CDT, but known by the build tool and tool chains only (like an
incomplete software system, or external sources or libraries attracting
internally inactive code, a not 100% integrated tool chain to CDT, etc.,
etc.). There most probably is no perfect solution for refactoring
inactive code only using parsing technology on source code, at least not
for arbitrary systems. There may not even be a perfect solution using
other technology, as any legacy code or legacy build system might not be
thoroughly known either, thus the possible results are not completely
known, thus the context is not a closed one, and thus its not going to
be totally right - well, most probably much less than totally after all.
 
The biggest problem here is really to detect too much "inactive" code.
False positives is the worst a user could experience IMHO. Besides, I do
not know any tool based on parsing technology only offering inactive
code refactoring - it seems just too simple to prove shortcomings.
 
Just my 2 cents,
 
Walter


________________________________

	From: cdt-dev-bounces@xxxxxxxxxxx
[mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Schaber, Gerhard
	Sent: Donnerstag, 11. September 2008 16:04
	To: CDT General developers list.
	Subject: RE: [cdt-dev] Parsing code under inactive #if or #ifdef
	
	
	Hi!
	 
	I am sure that this is a lot of work, and obviously solution 3
is the way to go. Without this effort I don't think there can be any
reliable refactoring tools. If only one configuration is analyzed, and
you rename or move elements that occur in different configurations, then
the code would be broken for all other configurations.
	 
	Best regards,
	 
	   Gerhard
	 


________________________________

		From: cdt-dev-bounces@xxxxxxxxxxx
[mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Chris Recoskie
		Sent: Donnerstag, 11. September 2008 15:18
		To: CDT General developers list.
		Subject: Re: [cdt-dev] Parsing code under inactive #if
or #ifdef
		
		

		Conditional compilation is very tricky to handle
properly. It is not a matter of just letting the preprocessor output all
the code from all paths through the code as this will generally result
in incorrect code, and thus an unsuccessful parse (or at lesast, one
filled with problem bindings).
		
		Here is a presentation I gave at last year's summit on
how we could handle this: 
http://wiki.eclipse.org/images/b/b3/Handling_Conditional_Compilation_In_
CDT%E2%80%99s_Core.pdf
		
		Beforewarned, doing this feature right would mean a lot
of work. I think, in retrospect, that even my large estimates that I
gave in that presentation were somewhat naive.
		
		===========================
		
		Chris Recoskie
		Team Lead, IBM CDT Team
		IBM Toronto
		http://www.eclipse.org/cdt
		
		 "Dmitry Smirnov" <divis1969@xxxxxxxxx>
		
		
		

				"Dmitry Smirnov" <divis1969@xxxxxxxxx> 
				Sent by: cdt-dev-bounces@xxxxxxxxxxx 

				09/11/2008 08:58 AM 
	
	Please respond to
"CDT General developers list." <cdt-dev@xxxxxxxxxxx>

 

To

cdt-dev@xxxxxxxxxxx	


cc

	


Subject

[cdt-dev] Parsing code under inactive #if or #ifdef	
	 	

		Hi,
		
		I'm trying to use AST/PDOM for parsing a project in goal
to build
		browsable view of the code (outside of Eclipse, some set
of WEB
		pages).
		
		For this purpose I would like to have inactive code to
be parsed too.
		As I can see, now this is prevented by CPreprocessor
class. Method
		executeIfdef() and other similar methods call
		skipOverConditionalCode().
		
		I would like to propose some enchancement for this. I
believe some
		scanner options could be added that changes default
behaviour. If this
		option is active, CPreprocessor will not call
		skipOverConditionalCode() thus making parser to handle
all the code.
		
		I suppose, some methods should also be changed (like
values of macro
		defined inside active/inactive branches).
		
		What do you think about such feature? Perhaps, CDT
already have some
		plans for similar enchancement?
		
		I'm going to test this approach with CDT 5.0. If you
have some
		thoughts that could help me with it, please let me know.
		
		Dmitry
		_______________________________________________
		cdt-dev mailing list
		cdt-dev@xxxxxxxxxxx
		https://dev.eclipse.org/mailman/listinfo/cdt-dev