Thu Apr 13 13:43:19 UTC 2006 William R. Otte <wotte@dre.vanderbilt.edu>escher_x_4_9_integration_point

26 files changed, 189 insertions, 168 deletions

diff --git a/TAO/CIAO/CCF/CCF/CIDL/SemanticAction/Factory.hpp b/TAO/CIAO/CCF/CCF/CIDL/SemanticAction/Factory.hpp
index d16c5ce3ec1..521602ac70f 100644
--- a/TAO/CIAO/CCF/CCF/CIDL/SemanticAction/Factory.hpp
+++ b/TAO/CIAO/CCF/CCF/CIDL/SemanticAction/Factory.hpp
@@ -15,7 +15,7 @@ namespace CCF
     {
       struct Composition;
       struct HomeExecutor;
-      
+
       struct Factory : virtual IDL3::SemanticAction::Factory
       {
         virtual Composition&
diff --git a/TAO/CIAO/CCF/CCF/CIDL/SemanticGraph/Elements.cpp b/TAO/CIAO/CCF/CCF/CIDL/SemanticGraph/Elements.cpp
index 82220fe9bb7..349f1854786 100644
--- a/TAO/CIAO/CCF/CCF/CIDL/SemanticGraph/Elements.cpp
+++ b/TAO/CIAO/CCF/CCF/CIDL/SemanticGraph/Elements.cpp
@@ -12,7 +12,7 @@ namespace CCF
     {
       using Introspection::TypeInfo;
       using Introspection::Access;
-      
+
       namespace
       {
         TypeInfo
diff --git a/TAO/CIAO/CCF/CCF/CodeGenerationKit/IndentationImplanter.hpp b/TAO/CIAO/CCF/CCF/CodeGenerationKit/IndentationImplanter.hpp
index 57dcf02af4a..40259a694f6 100644
--- a/TAO/CIAO/CCF/CCF/CodeGenerationKit/IndentationImplanter.hpp
+++ b/TAO/CIAO/CCF/CCF/CodeGenerationKit/IndentationImplanter.hpp
@@ -77,7 +77,7 @@ namespace Indentation
 
     virtual int_type
     put (char_type c) throw (Exception, ExH::System::Exception)
-    {  
+    {
       return buffer_.sputc (c);
     }
 
diff --git a/TAO/CIAO/CCF/CCF/CodeGenerationKit/Regex.hpp b/TAO/CIAO/CCF/CCF/CodeGenerationKit/Regex.hpp
index 8b5a14cbf22..be0bd3827e0 100644
--- a/TAO/CIAO/CCF/CCF/CodeGenerationKit/Regex.hpp
+++ b/TAO/CIAO/CCF/CCF/CodeGenerationKit/Regex.hpp
@@ -46,7 +46,7 @@ namespace regex
     if (e.empty ()) return src;
 
     wchar_t delimiter (e[0]);
-    
+
     std::wstring::size_type first = e.find (delimiter);
     std::wstring::size_type middle = e.find (delimiter, first + 1);
     std::wstring::size_type last = e.find (delimiter, middle + 1);
diff --git a/TAO/CIAO/CCF/CCF/IDL2/SemanticAction/Impl/Enum.cpp b/TAO/CIAO/CCF/CCF/IDL2/SemanticAction/Impl/Enum.cpp
index a87d87470b2..5e846d90211 100644
--- a/TAO/CIAO/CCF/CCF/IDL2/SemanticAction/Impl/Enum.cpp
+++ b/TAO/CIAO/CCF/CCF/IDL2/SemanticAction/Impl/Enum.cpp
@@ -55,6 +55,7 @@ namespace CCF
           {
             Enumerator& e (ctx.tu ().new_node<Enumerator> ());
             ctx.tu ().new_edge<Belongs> (e, *type_);
+            ctx.tu ().new_edge<Defines> (ctx.scope (), e, name);
           }
         }
 
diff --git a/TAO/CIAO/CCF/CCF/IDL2/SemanticAction/TypeId.hpp b/TAO/CIAO/CCF/CCF/IDL2/SemanticAction/TypeId.hpp
index 1c8d7bdadae..a716961bbf0 100644
--- a/TAO/CIAO/CCF/CCF/IDL2/SemanticAction/TypeId.hpp
+++ b/TAO/CIAO/CCF/CCF/IDL2/SemanticAction/TypeId.hpp
@@ -22,7 +22,7 @@ namespace CCF
         end () = 0;
       };
 
-      
+
       struct TypePrefix
       {
         virtual void
diff --git a/TAO/CIAO/CCF/CCF/IDL2/SemanticGraph/Enum.hpp b/TAO/CIAO/CCF/CCF/IDL2/SemanticGraph/Enum.hpp
index 8399fecc6b0..6e3d2ee723d 100644
--- a/TAO/CIAO/CCF/CCF/IDL2/SemanticGraph/Enum.hpp
+++ b/TAO/CIAO/CCF/CCF/IDL2/SemanticGraph/Enum.hpp
@@ -5,7 +5,7 @@
 #ifndef CCF_IDL2_SEMANTIC_GRAPH_ENUM_HPP
 #define CCF_IDL2_SEMANTIC_GRAPH_ENUM_HPP
 
-#include "CCF/IDL2/SemanticGraph/Elements.hpp"
+#include "CCF/IDL2/SemanticGraph/IntExpression.hpp"
 
 namespace CCF
 {
@@ -35,7 +35,7 @@ namespace CCF
       };
 
 
-      class Enumerator : public virtual Nameable, public virtual Instance
+      class Enumerator : public virtual Nameable, public virtual IntConst
       {
       public:
         static Introspection::TypeInfo const&
diff --git a/TAO/CIAO/CCF/CCF/IDL2/SemanticGraph/Exception.cpp b/TAO/CIAO/CCF/CCF/IDL2/SemanticGraph/Exception.cpp
index 84ca130cafa..9ed3a7e494b 100644
--- a/TAO/CIAO/CCF/CCF/IDL2/SemanticGraph/Exception.cpp
+++ b/TAO/CIAO/CCF/CCF/IDL2/SemanticGraph/Exception.cpp
@@ -12,7 +12,7 @@ namespace CCF
     {
       using Introspection::TypeInfo;
       using Introspection::Access;
-      
+
       namespace
       {
         TypeInfo
diff --git a/TAO/CIAO/CCF/CCF/IDL2/SemanticGraph/Member.cpp b/TAO/CIAO/CCF/CCF/IDL2/SemanticGraph/Member.cpp
index b57bb0fe764..597be660772 100644
--- a/TAO/CIAO/CCF/CCF/IDL2/SemanticGraph/Member.cpp
+++ b/TAO/CIAO/CCF/CCF/IDL2/SemanticGraph/Member.cpp
@@ -12,7 +12,7 @@ namespace CCF
     {
       using Introspection::TypeInfo;
       using Introspection::Access;
-      
+
       namespace
       {
         TypeInfo
diff --git a/TAO/CIAO/CCF/CCF/IDL2/SemanticGraph/Native.cpp b/TAO/CIAO/CCF/CCF/IDL2/SemanticGraph/Native.cpp
index 46e24ae9c76..b2c29fe2881 100644
--- a/TAO/CIAO/CCF/CCF/IDL2/SemanticGraph/Native.cpp
+++ b/TAO/CIAO/CCF/CCF/IDL2/SemanticGraph/Native.cpp
@@ -12,7 +12,7 @@ namespace CCF
     {
       using Introspection::TypeInfo;
       using Introspection::Access;
-      
+
       namespace
       {
         TypeInfo
diff --git a/TAO/CIAO/CCF/CCF/IDL2/SemanticGraph/Operation.cpp b/TAO/CIAO/CCF/CCF/IDL2/SemanticGraph/Operation.cpp
index 697751f14cd..83ed23ffe40 100644
--- a/TAO/CIAO/CCF/CCF/IDL2/SemanticGraph/Operation.cpp
+++ b/TAO/CIAO/CCF/CCF/IDL2/SemanticGraph/Operation.cpp
@@ -12,7 +12,7 @@ namespace CCF
     {
       using Introspection::TypeInfo;
       using Introspection::Access;
-      
+
       // Receives
       //
       //
diff --git a/TAO/CIAO/CCF/CCF/IDL2/SemanticGraph/Struct.cpp b/TAO/CIAO/CCF/CCF/IDL2/SemanticGraph/Struct.cpp
index 463dec37f23..46fd9b9ef3a 100644
--- a/TAO/CIAO/CCF/CCF/IDL2/SemanticGraph/Struct.cpp
+++ b/TAO/CIAO/CCF/CCF/IDL2/SemanticGraph/Struct.cpp
@@ -36,18 +36,28 @@ namespace CCF
       {
         if (defined ())
         {
+          CompilerElements::Context& ctx (
+            const_cast<CompilerElements::Context&> (context ()));
+
+          if (ctx.count ("struct-complete-test"))
+            return true;
+
+          ctx.set ("struct-complete-test", true);
+          bool c (true);
+
           for (Scope::NamesIterator i (names_begin ());
-               i != names_end ();
+               c && i != names_end ();
                ++i)
           {
             Member const& m (dynamic_cast<Member&> ((*i)->named ()));
             Type const& t (m.belongs ().type ());
 
             if (!t.complete ())
-              return false;
+              c = false;
           }
 
-          return true;
+          ctx.remove ("struct-complete-test");
+          return c;
         }
 
         return false;
diff --git a/TAO/CIAO/CCF/CCF/IDL2/SemanticGraph/Union.cpp b/TAO/CIAO/CCF/CCF/IDL2/SemanticGraph/Union.cpp
index a1d32705644..28c673a94f3 100644
--- a/TAO/CIAO/CCF/CCF/IDL2/SemanticGraph/Union.cpp
+++ b/TAO/CIAO/CCF/CCF/IDL2/SemanticGraph/Union.cpp
@@ -142,18 +142,28 @@ namespace CCF
       {
         if (defined ())
         {
+          CompilerElements::Context& ctx (
+            const_cast<CompilerElements::Context&> (context ()));
+
+          if (ctx.count ("union-complete-test"))
+            return true;
+
+          ctx.set ("union-complete-test", true);
+          bool c (true);
+
           for (Scope::NamesIterator i (names_begin ());
-               i != names_end ();
+               c && i != names_end ();
                ++i)
           {
             Member const& m (dynamic_cast<Member&> ((*i)->named ()));
             Type const& t (m.belongs ().type ());
 
             if (!t.complete ())
-              return false;
+              c = false;
           }
 
-          return true;
+          ctx.remove ("union-complete-test");
+          return c;
         }
 
         return false;
diff --git a/TAO/CIAO/CCF/CCF/IDL2/Traversal/Union.cpp b/TAO/CIAO/CCF/CCF/IDL2/Traversal/Union.cpp
index d440907ed4c..b14f518983e 100644
--- a/TAO/CIAO/CCF/CCF/IDL2/Traversal/Union.cpp
+++ b/TAO/CIAO/CCF/CCF/IDL2/Traversal/Union.cpp
@@ -49,7 +49,7 @@ namespace CCF
       {
       }
 
-      
+
       // Union
       //
       //
diff --git a/TAO/CIAO/CCF/CCF/IDL2/Traversal/Union.hpp b/TAO/CIAO/CCF/CCF/IDL2/Traversal/Union.hpp
index 0237be5016d..2bcad1eb4ea 100644
--- a/TAO/CIAO/CCF/CCF/IDL2/Traversal/Union.hpp
+++ b/TAO/CIAO/CCF/CCF/IDL2/Traversal/Union.hpp
@@ -38,7 +38,7 @@ namespace CCF
         post (Type&);
       };
 
-      
+
       //
       //
       //
@@ -52,7 +52,7 @@ namespace CCF
 
         virtual void
         name (Type&);
-        
+
         virtual void
         post (Type&);
       };
diff --git a/TAO/CIAO/CCF/CCF/IDL3/SemanticGraph/Elements.cpp b/TAO/CIAO/CCF/CCF/IDL3/SemanticGraph/Elements.cpp
index 4d3b325f5fd..ab49a698842 100644
--- a/TAO/CIAO/CCF/CCF/IDL3/SemanticGraph/Elements.cpp
+++ b/TAO/CIAO/CCF/CCF/IDL3/SemanticGraph/Elements.cpp
@@ -12,7 +12,7 @@ namespace CCF
     {
       using Introspection::TypeInfo;
       using Introspection::Access;
-      
+
       namespace
       {
         TypeInfo
diff --git a/TAO/CIAO/CCF/Documentation/DesignNotes b/TAO/CIAO/CCF/Documentation/DesignNotes
index b81778b5ba4..1cf74e88400 100644
--- a/TAO/CIAO/CCF/Documentation/DesignNotes
+++ b/TAO/CIAO/CCF/Documentation/DesignNotes
@@ -1,14 +1,14 @@
 
 Note: this file is somewhat outdated
 
-Intention of this file is to capture and document CIDL complier design 
+Intention of this file is to capture and document CIDL complier design
 ideas/decisions.
 
 Conceptual parts of CIDL compiler design
 ----------------------------------------
 
 Option Parser                       Consists of option parser and option
-                                    database. 
+                                    database.
 
 C Preprocessor Interfacing          Represents mechanism of preprocessing
                                     cidl files.
@@ -30,10 +30,10 @@ Semantic Analyzer                   Traverses Syntax Tree and performs
                                     semantic expansions.
 
 
-Code Generation Stream              Stream to output generated code to. Used 
+Code Generation Stream              Stream to output generated code to. Used
                                     by concrete Code Generators
 
-Code Generators 
+Code Generators
 {
 
   Executor Mapping Generator          Generator for local executor mapping.
@@ -48,7 +48,7 @@ Code Generators
 }
 
 Compiler driver                     Establishes order of execution of
-                                    different components as part of 
+                                    different components as part of
                                     compilation process.
 
 
@@ -63,8 +63,8 @@ How everything works together
     cidl file and generates Syntax Tree by means of semantic rules.
 
 (4) At this point we have Syntax Tree corresponding to the original cidl
-    file. Compiler Driver executes Executor Mapping Generator, 
-    Executor Implementation Generator and Skeleton Thunk Generator on 
+    file. Compiler Driver executes Executor Mapping Generator,
+    Executor Implementation Generator and Skeleton Thunk Generator on
     Syntax Tree.
 
 
@@ -72,7 +72,7 @@ How everything works together
 General Design Ideas/Decision
 -------------
 
-[IDEA]: There is an effort to use autoconf/automake in ACE/TAO. Maybe it's 
+[IDEA]: There is an effort to use autoconf/automake in ACE/TAO. Maybe it's
         a good idea to start using it with CIDLC? There is one side advantage
         of this approach: if we decide to embed GCC CPP then we will have to
         use configure (or otherwise ACE-ify the code which doesn't sound like
@@ -81,7 +81,7 @@ General Design Ideas/Decision
 [IDEA]: CIDLC is a prototype for a new IDLC, PSDLC and IfR model. Here are
         basic concepts:
 
-          - use common IDL grammar, semantic rules and syntax tree nodes 
+          - use common IDL grammar, semantic rules and syntax tree nodes
             for IDLC, CIDLC, PSDLC and IfR. Possibly have several libraries
             for example ast_idl-2.so, ast_idl-3.so, scaner_idl-2.so
             scaner_idl-3.so, parser_idl-2.so, parser_idl-3.so. Dependency
@@ -102,16 +102,16 @@ General Design Ideas/Decision
                        ---------parser_idl-3.so---------
 
             Same idea applies for CIDL and PSDL.
-                                             
 
-          - use the same internal representation (syntax tree) in all 
+
+          - use the same internal representation (syntax tree) in all
             compilers and IfR. This way at some stage if we will need
             to make one of the compilers IfR-integrated (import keyword?)
             then it will be a much easier task than it's now. This internal
-            representation may also be usable in typecodes 
+            representation may also be usable in typecodes
+
+            @@ boris: not clear to me.
 
-            @@ boris: not clear to me. 
-            
             @@ jeff: A typecode is like a piece of the Syntax Tree with these
                exceptions -
 
@@ -125,44 +125,44 @@ General Design Ideas/Decision
                different classes than used to compose the ST itself.
 
             @@ boris: Ok, let me see if I got it right. So when typecode
-               is kept in parsed state (as opposite to binary) (btw, when 
+               is kept in parsed state (as opposite to binary) (btw, when
                does it happen?) it makes sense to apply the same techniques
                (if in fact not the same ST nodes and traversal mechs) as
                for XIDL compilation.
 
 [IDEA]: We should be consistent with the way external compilers that we call
         report errors. For now those are CPP and IDLC.
-                       
+
 Option Parser
 -------------
 
 [IDEA]: Use Spirit parser framework to generate option parser.
 
-[IDEA]: Option Database is probably a singleton. 
+[IDEA]: Option Database is probably a singleton.
 
-        @@ jeff: This is a good idea, especially when passing some of the 
-           options to a preprocessor or spawned IDL compier. But I think we 
-           will still need 'state' classes for the front and back ends (to 
-           hold values set by command line options and default values) so 
+        @@ jeff: This is a good idea, especially when passing some of the
+           options to a preprocessor or spawned IDL compier. But I think we
+           will still need 'state' classes for the front and back ends (to
+           hold values set by command line options and default values) so
            we can keep them decoupled).
 
 
-        @@ boris: I understand what you mean. Though I think we will be 
+        @@ boris: I understand what you mean. Though I think we will be
            able to do with one 'runtime database'. Each 'compiler module'
            will be able to populate its 'namespace' with (1) default
-           values, (2) with module-specific options and (3) arbitrary 
+           values, (2) with module-specific options and (3) arbitrary
            runtime information. I will present prototopy design shortly.
-           
+
 
 [IDEA]: It seems we will have to execute at least two external programs
         as part of CIDLC execution: CPP and IDLC. Why wouldn't we follow
         GCC specs model (gcc -dumpspecs). Here are candidates to be put into
-        specs:        
+        specs:
 
           - default CPP name and options
           - default  IDLC name and options
           - default file extensions and formats for different mappings
-          - other ideas? 
+          - other ideas?
 
 [IDEA]: Provide short and long option names (e.g. -o and --output-dir)
         for every option (maybe except -I, -D, etc).
@@ -188,9 +188,9 @@ C Preprocessor Interfacing
 IDL Compiler Interfacing
 ------------------------
 
-[IDEA]: Same as for CPP: Can we use pipes? 
+[IDEA]: Same as for CPP: Can we use pipes?
 
-        @@ jeff: check with Nanbor on this. I think there may be CCM/CIAO 
+        @@ jeff: check with Nanbor on this. I think there may be CCM/CIAO
            use cases where we need the intermediate IDL file.
 
 [IDEA]: Will need a mechanism to pass options to IDLC from CIDLC command
@@ -207,7 +207,7 @@ Scanner
         iterator"-based scanner. So this basically mean that we may have to
         keep the whole sequence in memory. BTW, this is another good reason
         to have scanner: if we manage to make scanner a predictable parser
-        (i.e. no backtracking) then we don't have to keep the whole 
+        (i.e. no backtracking) then we don't have to keep the whole
         preprocessed cidl file in memory.
 
 
@@ -221,17 +221,17 @@ Parser
         much easier to reuse/inherit even dynamically. Need to elaborate
         this idea.
 
-[IDEA]: Use functors as semantic actions. This way we can specify (via 
+[IDEA]: Use functors as semantic actions. This way we can specify (via
         functor's data member) on which Syntax Tree they are working.
         Bad side: semantic rules are defined during grammar construction.
         However we can use a modification of the factory method pattern.
-        Better ideas? 
+        Better ideas?
 
         @@ jeff: I think ST node creation with a factory
            is a good idea - another ST implementation could be plugged in,
            as long as it uses a factory with the same method names.
 
-        @@ boris: Right. In fact it's our 'improved' way of handling 'BE' 
+        @@ boris: Right. In fact it's our 'improved' way of handling 'BE'
            usecases.
 
 
@@ -242,23 +242,23 @@ Syntax Tree
 [IDEA]: Use interface repository model as a base for Syntax Tree hierarchy.
 
 [IDEA]: Currently (in IDLC) symbol lookup is accomplished by AST navigation,
-        and is probably the biggest single bottleneck in performance. Perhaps 
-        a separate symbol table would be preferable. Also, lookups could be 
-        specialized, e.g., for declaration, for references, and perhaps a 
+        and is probably the biggest single bottleneck in performance. Perhaps
+        a separate symbol table would be preferable. Also, lookups could be
+        specialized, e.g., for declaration, for references, and perhaps a
         third type for argument-related lookups.
 
 [NOTE]: If we are to implement symbol tables then we need to think how we
         are going to inherit (extend) this tables.
 
 [NOTE]: Inheritance/supports graphs: these graphs need to be traversed at
-        several points in the back end. Currently they are rebuilt for each 
-        use, using an n-squared algorithm. We could at least build them only 
-        once for each interface/valuetype, perhaps even with a better 
-        algorithm. It could be integrated into inheritance/supports error 
-        checking at node creation time, which also be streamlined. 
-
-        @@ boris: Well, I think we should design our Syntax Tree so that 
-           every interface/valuetype has a list (flat?) of interfaces it 
+        several points in the back end. Currently they are rebuilt for each
+        use, using an n-squared algorithm. We could at least build them only
+        once for each interface/valuetype, perhaps even with a better
+        algorithm. It could be integrated into inheritance/supports error
+        checking at node creation time, which also be streamlined.
+
+        @@ boris: Well, I think we should design our Syntax Tree so that
+           every interface/valuetype has a list (flat?) of interfaces it
            inherits from/supports.
 
 [IDEA]: We will probably want to use factories to instantiate Syntax Tree
@@ -272,19 +272,19 @@ Common Syntax Tree traversal Design Ideas/Decision
 
 [IDEA] If we specify Syntax Tree traversal facility then we will be able
        to specify (or even plug dynamically) Syntax Tree traversal agents
-       that may not only generate something but also annotate or modify 
+       that may not only generate something but also annotate or modify
        Syntax Tree. We are already using this technique for a number of
        features (e.g. AMI, IDL3 extension, what else?) but all these agents
        are hardwired inside TAO IDLC. If we have this facility then we will
        be able to produce modular and highly extensible design. Notes:
 
        - Some traversal agents can change Syntax Tree so that it will be
-         unusable by some later traversal agents. So maybe the more 
-         generic approach would be to produce new Syntax Tree? 
+         unusable by some later traversal agents. So maybe the more
+         generic approach would be to produce new Syntax Tree?
 
-         @@ jeff: Yes, say for example that we were using a common ST 
-            representation for the IDL compiler and the IFR. We would not 
-            want to send the extra AMI nodes to the IFR so in that case 
+         @@ jeff: Yes, say for example that we were using a common ST
+            representation for the IDL compiler and the IFR. We would not
+            want to send the extra AMI nodes to the IFR so in that case
             simple modification of the ST might not be best.
 
 [IDEA] Need a generic name for "Syntax Tree Traversal Agents". What about
@@ -306,16 +306,16 @@ Code Generation Stream
 	will result in a generated code like this:
 
        namespace N
-       {      
-         ...         
+       {
+         ...
 
          long foo (long arg0,
                    long arg1)
          {
            return arg0 + arg1;
          }
-             
-         ...      
+
+         ...
        }
 
        Note that no special actions were taken to ensure proper indentation.
@@ -336,34 +336,34 @@ Code Generators
        @@ boris: I would say may not always be correct
 
 
-       However, for purposes of type coercion and other checking (such as 
-       for positive integer values in string, array and sequence bounds) 
+       However, for purposes of type coercion and other checking (such as
+       for positive integer values in string, array and sequence bounds)
        evaluation must be done internally.
-       
+
        @@ boris: note that evaluation is needed to only verify that things
-          are correct. You don't have to (shouldn't?) substitute original 
+          are correct. You don't have to (shouldn't?) substitute original
           (const) expression with what's been evaluated.
 
 
-       @@ jeff: it may be necessary in some cases to append 'f' or 'U' to 
+       @@ jeff: it may be necessary in some cases to append 'f' or 'U' to
           a generated number to avoid a C++ compiler warning.
 
        @@ boris: shouldn't this 'f' and 'U' be in IDL as well?
 
 [IDEA] I wonder if it's a good idea to use a separate pass over syntax tree
-       for semantic checking (e.g. type coercion, positive values for 
-       sequence bounds). 
+       for semantic checking (e.g. type coercion, positive values for
+       sequence bounds).
 
-       @@ jeff: This may hurt performance a little - more lookups - but it 
+       @@ jeff: This may hurt performance a little - more lookups - but it
           will improve error reporting.
-      
+
        @@ boris:  As we dicussed earlier this pass could be used to do
           'semantic expansions' (e.g. calculate a flat list of interface's
           children, etc). Also I don't think we should worry about speed
           very much here (of course I don't say we have to be stupid ;-)
           In fact if we are trading better design vs faster compilation
           at this stage we should always go for better design.
-      
+
 
 Executor Mapping Generator
 --------------------------
@@ -394,66 +394,66 @@ Vault
 Some thoughts from Jeff that I are not directly related to CIDLC and are
 rather current IDLC design defects:
 
-* AMI/AMH implied IDL: more can be done in the BE preprocessing pass, 
-  hopefully eliminating a big chunk of the huge volume of AMI/AMH visitor 
-  code. The implied IDL generated for CCM types, for example, leaves almost 
+* AMI/AMH implied IDL: more can be done in the BE preprocessing pass,
+  hopefully eliminating a big chunk of the huge volume of AMI/AMH visitor
+  code. The implied IDL generated for CCM types, for example, leaves almost
   nothing extra for the visitors to do.
 
-* Fwd decl redefinition: forward declaration nodes all initially contain a 
-  heap-allocated dummy full-definition member, later replaced by a copy 
+* Fwd decl redefinition: forward declaration nodes all initially contain a
+  heap-allocated dummy full-definition member, later replaced by a copy
   of the full definition. This needs to be streamlined.
 
-* Memory leaks: inconsistent copying/passing policies make it almost 
-  impossible to eliminate the huge number of leaks. The front end will be 
-  more and more reused, and it may be desirable to make it executable as a 
-  function call, in which case it will important to eliminate the leaks. 
-  Perhaps copying of AST nodes can be eliminated with reference counting or 
+* Memory leaks: inconsistent copying/passing policies make it almost
+  impossible to eliminate the huge number of leaks. The front end will be
+  more and more reused, and it may be desirable to make it executable as a
+  function call, in which case it will important to eliminate the leaks.
+  Perhaps copying of AST nodes can be eliminated with reference counting or
   just with careful management, similarly for string identifiers and literals.
-  Destroy() methods have been put in all the node classes, and are called 
-  recursively from the AST root at destruction time, but they are far from 
+  Destroy() methods have been put in all the node classes, and are called
+  recursively from the AST root at destruction time, but they are far from
   doing a complete job.
 
-* Visitor instantiation: the huge visitor factory has already been much 
-  reduced, and the huge enum of context state values is being reduced. 
-  However there will still be an abundance of switch statements at nearly 
-  every instance of visitor creation at scope nesting. We could make better 
+* Visitor instantiation: the huge visitor factory has already been much
+  reduced, and the huge enum of context state values is being reduced.
+  However there will still be an abundance of switch statements at nearly
+  every instance of visitor creation at scope nesting. We could make better
   use of polymorphism to get rid of them.
 
 * Node narrowing: instead of the impenetrable macros we use now, we
-  could either generate valuetype-like downcast methods for the (C)IDL 
+  could either generate valuetype-like downcast methods for the (C)IDL
   types, or we could just use dynamic_cast.
 
 * Error reporting: making error messages more informative, and error recovery
-  could both be a lot better, as they are in most other IDL compilers. If a 
-  recursive descent parser is used (such as Spirit), there is a simple 
+  could both be a lot better, as they are in most other IDL compilers. If a
+  recursive descent parser is used (such as Spirit), there is a simple
   generic algorithm for error recovery.
 
 
-* FE/BE node classes: if BE node classes are implemented at all, there should 
-  be a complete separation of concerns - BE node classes should contain only 
-  info related to code generation, and FE node classes should contain only 
-  info related to the AST representation. As the front end becomes more 
-  modular and reusable, this will become more and more necessary. 
+* FE/BE node classes: if BE node classes are implemented at all, there should
+  be a complete separation of concerns - BE node classes should contain only
+  info related to code generation, and FE node classes should contain only
+  info related to the AST representation. As the front end becomes more
+  modular and reusable, this will become more and more necessary.
 
   @@ boris: It doesn't seem we will need two separate and parallel hierarhies.
 
 * Undefined fwd decls: now that we have dropped support for platforms without
-  namespaces, the code generated for fwd declarations not defined in the same 
-  translation unit can be much improved, most likely by the elimination of 
+  namespaces, the code generated for fwd declarations not defined in the same
+  translation unit can be much improved, most likely by the elimination of
   generated flat-name global methods, and perhaps other improvements as well.
 
-* Strategized code generation: many places now have either lots of 
-  duplication, or an explosion of branching in a single visitor. Adding code 
-  generation for use cases incrementally may give us an opportunity to 
+* Strategized code generation: many places now have either lots of
+  duplication, or an explosion of branching in a single visitor. Adding code
+  generation for use cases incrementally may give us an opportunity to
   refactor and strategize it better.
 
-* Node generator: this class does nothing more than call 'new' and pass 
-  unchanged the arguments it gets to the appropriate constructor - it can be 
+* Node generator: this class does nothing more than call 'new' and pass
+  unchanged the arguments it gets to the appropriate constructor - it can be
   eliminated.
 
-* Virtual methods: there are many member functions in the IDL compiler that 
+* Virtual methods: there are many member functions in the IDL compiler that
   are needlessly virtual.
 
-* Misc. leveraging: redesign of mechanisms listed above can have an effect 
+* Misc. leveraging: redesign of mechanisms listed above can have an effect
   on other mechanisms, such as the handling of pragma prefix, typeprefix, and
   reopened modules.
diff --git a/TAO/CIAO/CCF/Documentation/TODO b/TAO/CIAO/CCF/Documentation/TODO
index 7a70b99f513..879602513df 100644
--- a/TAO/CIAO/CCF/Documentation/TODO
+++ b/TAO/CIAO/CCF/Documentation/TODO
@@ -10,7 +10,7 @@ Legend:
 
 ------------------------------------------------------------------------
 
-@@ In operation comma member function is used both for parameters and 
+@@ In operation comma member function is used both for parameters and
    exceptions. As a result one can get unexpected extra commas.
 
 @@ Make CCF buildable with MPC.
@@ -21,7 +21,7 @@ Legend:
 
 @@ Typedef.hpp TypeId.hpp: naming inconsistency.
 
-@@ Need ICE mechanism (search for abort ()) 
+@@ Need ICE mechanism (search for abort ())
 
 @@ Need evolution of semantic action error handling/reporting.
 
@@ -31,17 +31,17 @@ Legend:
 @@+++ Currently character stream is scanned completely before parsing. The
       better approach would be scanning on demand (1).
 
-@@+++ IDL2::Parsing::parse () should be eliminated (or terminated if you 
+@@+++ IDL2::Parsing::parse () should be eliminated (or terminated if you
       like ;-). This item depends on (1).
 
 @@++ 'using namespace' cleanup.
-   
+
 @@ Replace all i++ with ++i.
 
-@@ It seems that SyntaxTree::Node origin in terms of file:line should be 
-   preserved for subsequent diagnostic implemented as separate paths 
+@@ It seems that SyntaxTree::Node origin in terms of file:line should be
+   preserved for subsequent diagnostic implemented as separate paths
    (see repository id generator for example).
- 
+
 @@++++ Diagnostic evolution
 
 @%++ XML indentation buffer
diff --git a/TAO/CIAO/CCF/Example/CIDL/LocalExecutorMapping/test-0.idl b/TAO/CIAO/CCF/Example/CIDL/LocalExecutorMapping/test-0.idl
index cba2229b654..3c50f4acdd2 100644
--- a/TAO/CIAO/CCF/Example/CIDL/LocalExecutorMapping/test-0.idl
+++ b/TAO/CIAO/CCF/Example/CIDL/LocalExecutorMapping/test-0.idl
@@ -4,17 +4,17 @@
 
 module Empty
 {
-  interface I 
+  interface I
   {
   };
 };
 
 module M
-{ 
+{
   interface I {};
-  
+
   typedef I Internal;
-  
+
   //local interface CCM_I : I {};
 };
 
diff --git a/TAO/CIAO/CCF/Example/CIDL/LocalExecutorMapping/test-1.idl b/TAO/CIAO/CCF/Example/CIDL/LocalExecutorMapping/test-1.idl
index 2140367480c..0a437cb0320 100644
--- a/TAO/CIAO/CCF/Example/CIDL/LocalExecutorMapping/test-1.idl
+++ b/TAO/CIAO/CCF/Example/CIDL/LocalExecutorMapping/test-1.idl
@@ -9,13 +9,13 @@ module M1
 {
   interface Blah;
   interface Fool {};
-  
-  component C1 
+
+  component C1
   {
     provides M::I i;
     readonly attribute long l;
   };
-  
+
   home H1 manages C1
   {
     attribute M::I i;
diff --git a/TAO/CIAO/CCF/Example/CIDL/LocalExecutorMapping/test-2.idl b/TAO/CIAO/CCF/Example/CIDL/LocalExecutorMapping/test-2.idl
index 8d6ccd7ad6b..51bf3d88a4b 100644
--- a/TAO/CIAO/CCF/Example/CIDL/LocalExecutorMapping/test-2.idl
+++ b/TAO/CIAO/CCF/Example/CIDL/LocalExecutorMapping/test-2.idl
@@ -27,7 +27,7 @@ module M2
   {
     provides Goof pg;
     uses Goof ug;
-    
+
     publishes E pe;
     emits E me;
     consumes E ce;
@@ -40,34 +40,34 @@ module M2
     long l;
     OctetSeq octet_seq;
   };
-  
+
   typedef sequence<S> S_Seq;
-  
-  exception Ex1 
+
+  exception Ex1
   {
     string descr;
   };
-  
+
   exception Ex2
   {
   };
-  
+
   home H2 : M1::H1 supports I, J manages C2
   {
     readonly attribute long rl;
     readonly attribute M::I rai;
     attribute OctetSeq seq;
     attribute S_Seq a_s_seq;
-    
-    void 
-    foo (in long l, 
-         inout boolean b, 
-	 out long ol, 
-	 in M::I i, 
-	 out unsigned long long ull, 
-	 inout S_Seq s_seq,
-	 in V v) raises (Ex1, Ex2);
-	 	 
+
+    void
+      foo (in long l,
+           inout boolean b,
+           out long ol,
+           in M::I i,
+           out unsigned long long ull,
+           inout S_Seq s_seq,
+           in V v) raises (Ex1, Ex2);
+
     factory new (in long l, in OctetSeq s) raises (Ex2, Ex1);
     finder find (in long l, in OctetSeq s) raises (Ex1, Ex2);
   };
diff --git a/TAO/CIAO/CCF/Example/CodeGenerationKit/Indentation/XML/indent_xml.cpp b/TAO/CIAO/CCF/Example/CodeGenerationKit/Indentation/XML/indent_xml.cpp
index b65389ca306..f244249c69b 100644
--- a/TAO/CIAO/CCF/Example/CodeGenerationKit/Indentation/XML/indent_xml.cpp
+++ b/TAO/CIAO/CCF/Example/CodeGenerationKit/Indentation/XML/indent_xml.cpp
@@ -17,7 +17,7 @@ main ()
 
   cout << "<?xml version=\"1.0\"?>" << endl;
   cout << "<!DOCTYPE corbacomponent SYSYEM \"corbacomponent.dtd\">" << endl << endl;
-  
+
   cout << "<atag>whatever</atag>" << endl;
 
   cout << "<open>" << endl;
diff --git a/TAO/CIAO/CCF/Test/IDL2/Compiler/test.idl b/TAO/CIAO/CCF/Test/IDL2/Compiler/test.idl
index 1d18e7118fe..737a729524b 100644
--- a/TAO/CIAO/CCF/Test/IDL2/Compiler/test.idl
+++ b/TAO/CIAO/CCF/Test/IDL2/Compiler/test.idl
@@ -22,11 +22,11 @@ module InterfaceTest
   abstract interface AI;
   local interface LI;
   interface I;
-  
+
   abstract interface AI
   {
   };
-  
+
   interface I : AI
   {
   };
@@ -42,7 +42,7 @@ module InterfaceTest
 module MemberTest
 {
   typedef long Id;
-  
+
   struct S
   {
     Id id;
@@ -62,12 +62,12 @@ module ModuleTest
       typedef long L;
     };
   };
-  
+
   module M
   {
     typedef N::L L;
   };
-  
+
   module N
   {
     typedef M::N::L L;
@@ -95,7 +95,7 @@ module Sequence
   typedef sequence<octet> OctetSeq;
 
   typedef OctetSeq RawSeq;
-  
+
   typedef sequence<string> StringSeq, StrSeq;
 };
 
@@ -106,12 +106,12 @@ module Sequence
 module StructTest
 {
   struct S;
-  
+
   struct S
   {
     long m; // Struct cannot be empty.
   };
-  
+
 };
 
 // Typeid
@@ -120,7 +120,7 @@ module StructTest
 module TypeidTest
 {
   interface I;
-  
+
   typeid I "Foo";
   typeprefix TypeidTest "Bar";
 };
@@ -133,7 +133,7 @@ module TypeidTest
 module TypedefTest
 {
   interface I;
-  
+
   typedef I J;
 
   interface I
diff --git a/TAO/CIAO/CCF/Test/IDL2/LexicalAnalyzer/Coverage.idl b/TAO/CIAO/CCF/Test/IDL2/LexicalAnalyzer/Coverage.idl
index dc1aa225336..a29dde465d2 100644
--- a/TAO/CIAO/CCF/Test/IDL2/LexicalAnalyzer/Coverage.idl
+++ b/TAO/CIAO/CCF/Test/IDL2/LexicalAnalyzer/Coverage.idl
@@ -2,7 +2,7 @@
 // author    : Boris Kolpackov <boris@dre.vanderbilt.edu>
 // cvs-id    : $Id$
 
-// This file is supposed to cover an IDL2 lexical structure and intended 
+// This file is supposed to cover an IDL2 lexical structure and intended
 // for IDL2 lexer regression testing.
 //
 
diff --git a/TAO/CIAO/CCF/Test/IDL3/Compiler/GeneratorImpl.hpp b/TAO/CIAO/CCF/Test/IDL3/Compiler/GeneratorImpl.hpp
index 5125e62d580..91e3ab3cb49 100644
--- a/TAO/CIAO/CCF/Test/IDL3/Compiler/GeneratorImpl.hpp
+++ b/TAO/CIAO/CCF/Test/IDL3/Compiler/GeneratorImpl.hpp
@@ -516,9 +516,9 @@ namespace IDL3
       concrete_event_type.edge_traverser (inherits);
 
       //--
-      
+
       supports.node_traverser (type_name);
-      
+
       component_defines.node_traverser (attribute);
       component_defines.node_traverser (provider);
       component_defines.node_traverser (user);
diff --git a/TAO/CIAO/CCF/Test/IDL3/Compiler/test.idl b/TAO/CIAO/CCF/Test/IDL3/Compiler/test.idl
index e85e86a610d..a7e1cfb1d5a 100644
--- a/TAO/CIAO/CCF/Test/IDL3/Compiler/test.idl
+++ b/TAO/CIAO/CCF/Test/IDL3/Compiler/test.idl
@@ -21,7 +21,7 @@ module ComponentTest
   interface J
   {
   };
-  
+
   component A : B supports I, J
   {
   };
@@ -83,11 +83,11 @@ module HomeTest
   interface J
   {
   };
-  
+
   component A
   {
   };
-  
+
   home AH manages A
   {
   };
@@ -103,14 +103,14 @@ module HomeTest
 
 
 // HomeFactory
-// 
+//
 //
 module HomeFactoryTest
 {
   component A
   {
   };
-  
+
   home AH manages A
   {
     factory new (in long size);
@@ -126,7 +126,7 @@ module ProvidesTest
   interface I
   {
   };
-  
+
   component C
   {
     provides I i;
@@ -158,7 +158,7 @@ module UsesTest
   interface I
   {
   };
-  
+
   component C
   {
     uses I i;