[cfe-dev] Impending initialization rewrite

Douglas Gregor dgregor at apple.com
Mon Nov 30 07:01:01 PST 2009


Over the next few days, I plan to rewrite much of the semantic analysis for initialization to clean up a variety of problems that have surfaced over the past few months.

Major issues to address:

	1) Redundancy: initialization is currently spread among several files (SemaDecl, SemaDeclCXX, SemaInit, SemaOverload) with a disturbing amount of redundancy. I'd like to pull all of this code together into a single place that more clearly implements the C and C++ initialization rules.
	2) Diagnostics: our diagnostics for initialization failures, overload resolution, etc. are currently rather poor. They use barbaric means to distinguish the different kinds of initialization and assignment (see the "const char *Flavor" argument to, e.g., Sema::PerformCopyInitialization), have wording that does backflips to make up for that fact, and fail to adequately track the entities that are being initialized (variable, field, base class, temporary due to cast, temporary due to implicit conversion, etc.)
	3) Correctness & ASTs: we've been patching up the initialization code and its corresponding ASTs for a while, but since the code is so spread out we end up fixing the same bugs in many places. 
	4) Overloading: all of the initialization code has to be prepared to attempt a conversion without producing any diagnostics if it fails, for overloading purposes. To prepare for C++0x, this includes checking of { } initializer lists.
	5) Copy elision: audit all of the places where we can perform copy elision to ensure that the initialization code propagates that information into the ASTs.
	6) Temporaries: Make temporaries explicit, even when they are of POD or scalar type.
	7) Warnings: (possibly) implement new initialization warnings, such as -Wmissing-field-initializers.

Interface:

The main initialization code will have three entry points:

	TryInitialization) determines whether an object or reference can be initialized from a given set of expressions, taking into account the kind of initialization (direct, copy, value, etc.), target type, source expression, etc. The result of this routine will be some indicator of success/failure and an InitializationSequence which, like ImplicitConversionSequence, will describe the steps needed to perform the initialization. TryInitialization will never emit diagnostics nor build any permanent ASTs.

	PerformInitialization) performs the initialization of an object or reference given an InitializationSequence, building appropriate ASTs and performing checking that had to be delayed because it isn't part of overloading (e.g., binding a non-const reference to a bit-field).

	DiagnoseInitialization) emits diagnostics for a failed initialization, where TryInitialization could not produce a valid initialization sequence. The key here is reusability: we want DiagnoseInitialization to be used both by the obvious clients (variable initialization, base/member initialization, casts) and also for overload resolution (e.g., to specify precisely why a given overload candidate failed to match).

Any questions, comments, or advice would be appreciated!

	- Doug



More information about the cfe-dev mailing list