CodeObjectResolve Method (ResolveCategory, ResolveFlags)

Parameters

resolveCategory

Type: Nova.ResolvingResolveCategory

flags

Type: Nova.ResolvingResolveFlags

Return Value

Type: CodeObject

Resolves the current object if it's an UnresolvedRef, otherwise recursively resolves all child UnresolvedRefs. Leaves already-resolved references alone - unless the Unresolve flag is specified, in which case it converts all resolved references back to UnresolvedRefs while leaving existing UnresolvedRefs alone. Note that all declarations are processed during parsing - only symbolic references to declarations must be resolved. References to built-in types (types with keywords) and references to namespaces in NamespaceDecl statements are resolved during parsing (and all Namespace objects are declared). If this method is called on a Solution, Project, or CodeUnit, then resolving will proceed in 3 phases in order to resolve all references in a single "pass" without dependency problems: - Phase 1 resolves top-level statements in CodeUnits, NamespaceDecls, and then stops at TypeDecls after resolving any base lists (necessary so that base types will be resolved for later phases). - Phase 2 stops at the bodies of methods/properties, or base/this initializers, or field initializers (this gets all 'signatures' of members resolved for the final phase). - Phase 3 continues resolving method bodies and the other items not done in phase 2. These 3 phases neatly resolves all references in a single attempt without dependency issues - with a few minor exceptions. Switches resolve all Case constant expressions before the Case bodies in order to handle any forward references by 'goto case ...' statements. Types of fields initialized to constant values via references to other constant fields might not evaluate to their final constant value during Phase 3, but they'll have their correct type and that should be good enough. Currently, all 3 phases traverse the tree from the top down as opposed to building lists of objects at which to continue for the later 2 phases - such lists could be huge, and the first 2 phases only require traversal of the upper 3 to 4 levels of the tree for most references. Symbols might be resolved: - For an entire file, after the file is added and all parsing is complete for all added files. After loading and parsing a solution, after adding an existing project to a solution and parsing it, or after adding an existing file to a project and parsing it. After all parsing is complete, *all* references (resolved *and* unresolved) must be resolved. Resolved symbols must be re-resolved because new types or partial class members could cause conflicts. Ideally, resolution would be limited to references that might need it, but to be safe we should just re-resolve all references. - For an entire file, if a 'using' statement is added or removed. All references (resolved or unresolved) must be re-resolved to determine if they are still resolved or now have conflicts. HOWEVER, if conflicts arise in such a case, they should probably be auto- matically resolved by default, by adding the use of namespace prefixes to keep references tied to the same objects to which they were already resolved. - For all files with a 'using' or 'namespace' if the associated namespace has had a type added, removed, or renamed; or if a public member of a type was added, removed, renamed, or its signature changed. Of course, this applies to all files when types in the global namespace are changed. In theory, scope could be taken into consideration in order to avoid resolving all references in the entire program. For renames, resolving is necessary only to detect conflicts.