X-Git-Url: http://git.buserror.net/cgi-bin/gitweb.cgi?p=polintos%2Fscott%2Fpriv.git;a=blobdiff_plain;f=idlcomp%2Fmain.cc;h=a02453cad2a8f9b3de8b18f4f4f89a7db7c76df2;hp=597fbb768c7aa7ae47ae577e0cd2b8105d7e3c8e;hb=eec2efc14a0d624d475dc89e2bcb962e7c081df5;hpb=57f664cc02f517937b1a810a503e21ad8bc727bc diff --git a/idlcomp/main.cc b/idlcomp/main.cc index 597fbb7..a02453c 100644 --- a/idlcomp/main.cc +++ b/idlcomp/main.cc @@ -1,94 +1,103 @@ -/* main.cc -- entry point for the interface compiler - * - * Written by Scott Wood - * - * The idlc program implements two main functions. One is to turn - * .idl files into binary type descriptions. The other is to turn - * those type descriptions into language-specific stubs (though a - * compiler/interpreter could also just read the binary types - * directly, as the ORB does). - * - * For the former function, it is necessary to do the work in multiple - * passes, as not all information is available the first time through due - * to the absence of forward declarations. The passes are as follows: - * - * 1: Parse the input text, and determine which symbols exist in - * which namespaces. At this point, no non-namespace-qualified - * symbol lookups will be done (though namespace-qualified lookups - * are done, such as to check for duplicate symbols). - * - * Objects will be created for each entity (Interface, Struct, - * Datum, Alias, etc.), but any reference to another entity will be - * stored as a StrList, not as an object pointer. This must be the - * case even if a lookup during this pass would have found - * something, as on the second pass it might find a "closer" - * matching symbol added later. - * - * The StrList will later be looked up with only the entity - * containing the reference as context, so namespace search rules - * must not depend on anything else. - * - * This is the only pass that involves actually reading and - * parsing the input file(s). - * - * 2: Look up the namespace names of using namespace.* statements. - * These are the only lookups where order of the statements in the - * file matters, and it alters the result of a lookup, so it must be - * completed before chain lookups are done. - * - * 3: Look up the symbol names recorded in pass 1 for aliases, and - * typedefs, and const datum initializers and types. This is done - * before the rest of the lookups, so there will always be a - * complete chain to follow in subsequent passes. - * - * This is done by calling the virtual lookup_chain() method on - * the root namespace, which recursively calls it on all of its - * contents. - * - * 4: Look up other symbol names recorded in pass 1. At this point, - * unresolved alias chains may still exist and must be handled, - * though they should be fixed during this phase so that they do not - * appear in phase 4. Typedefs will remain fully chained, as the - * chain is semantically meaningful and must be preserved in the - * output. - * - * Const datum initializers are looked up in this pass despite being - * chains, since aliases aren't resolved in pass 2, and it's - * (slightly) easier to do the lookup in pass 3 and resolve the - * chain in pass 4 than to store a Symbol reference in pass 2, - * get the concerete sym in pass 3, and still have to either - * concrete-ize other Datums' initializers or wait until pass 4 - * to resolve the chain. - * - * This is done by calling the virtual lookup_misc() method on the - * root namespace, which recursively calls it on all of its - * contents. Upon receiving this call, each entity object should - * call lookup_sym() or lookup_type() on the various StrLists it has - * stored, but should not do anything with the object pointer - * until pass 4 (unless the object was satisfactorily initialized - * in pass 1). - * - * 5: Perform any remaining semantic analysis, now that all references - * to other entities have been looked up. - * - * This is done by calling the virtual final_analysis() method on - * the root namespace, which recursively calls it on all of its - * contents. - * - * 6: Generate output. - * This is done by calling the virtual output() method on - * the root namespace, which recursively calls it on all of its - * contents. - * - * All circular dependencies must be contained within the set of files - * passed to the compiler in one invocation. Supporting circular - * dependencies over multiple invocations of the compiler would require - * explicitly running only certain passes, then compiling the other - * batch, and then finishing the original batch. It could be done with - * some pain (intermediate states would need to be serialized), but I - * only want to do it if there's a real need. Circular dependencies - * ought to be isolated fairly locally... - */ +// Entry point for the interface compiler +// +// This software is copyright (c) 2006 Scott Wood . +// +// This software is provided 'as-is', without any express or implied warranty. +// In no event will the authors or contributors be held liable for any damages +// arising from the use of this software. +// +// Permission is hereby granted to everyone, free of charge, to use, copy, +// modify, prepare derivative works of, publish, distribute, perform, +// sublicense, and/or sell copies of the Software, provided that the above +// copyright notice and disclaimer of warranty be included in all copies or +// substantial portions of this software. +// +// The idlc program implements two main functions. One is to turn +// .idl files into binary type descriptions. The other is to turn +// those type descriptions into language-specific stubs (though a +// compiler/interpreter could also just read the binary types +// directly, as the ORB does). +// +// For the former function, it is necessary to do the work in multiple +// passes, as not all information is available the first time through due +// to the absence of forward declarations. The passes are as follows: +// +// 1: Parse the input text, and determine which symbols exist in +// which namespaces. At this point, no non-namespace-qualified +// symbol lookups will be done (though namespace-qualified lookups +// are done, such as to check for duplicate symbols). +// +// Objects will be created for each entity (Interface, Struct, +// Datum, Alias, etc.), but any reference to another entity will be +// stored as a StrList, not as an object pointer. This must be the +// case even if a lookup during this pass would have found +// something, as on the second pass it might find a "closer" +// matching symbol added later. +// +// The StrList will later be looked up with only the entity +// containing the reference as context, so namespace search rules +// must not depend on anything else. +// +// This is the only pass that involves actually reading and +// parsing the input file(s). +// +// 2: Look up the namespace names of using namespace.* statements. +// These are the only lookups where order of the statements in the +// file matters, and it alters the result of a lookup, so it must be +// completed before chain lookups are done. +// +// 3: Look up the symbol names recorded in pass 1 for aliases, and +// typedefs, and const datum initializers and types. This is done +// before the rest of the lookups, so there will always be a +// complete chain to follow in subsequent passes. +// +// This is done by calling the virtual lookup_chain() method on +// the root namespace, which recursively calls it on all of its +// contents. +// +// 4: Look up other symbol names recorded in pass 1. At this point, +// unresolved alias chains may still exist and must be handled, +// though they should be fixed during this phase so that they do not +// appear in phase 4. Typedefs will remain fully chained, as the +// chain is semantically meaningful and must be preserved in the +// output. +// +// Const datum initializers are looked up in this pass despite being +// chains, since aliases aren't resolved in pass 2, and it's +// (slightly) easier to do the lookup in pass 3 and resolve the +// chain in pass 4 than to store a Symbol reference in pass 2, +// get the concerete sym in pass 3, and still have to either +// concrete-ize other Datums' initializers or wait until pass 4 +// to resolve the chain. +// +// This is done by calling the virtual lookup_misc() method on the +// root namespace, which recursively calls it on all of its +// contents. Upon receiving this call, each entity object should +// call lookup_sym() or lookup_type() on the various StrLists it has +// stored, but should not do anything with the object pointer +// until pass 4 (unless the object was satisfactorily initialized +// in pass 1). +// +// 5: Perform any remaining semantic analysis, now that all references +// to other entities have been looked up. +// +// This is done by calling the virtual final_analysis() method on +// the root namespace, which recursively calls it on all of its +// contents. +// +// 6: Generate output. +// This is done by calling the virtual output() method on +// the root namespace, which recursively calls it on all of its +// contents. +// +// All circular dependencies must be contained within the set of files +// passed to the compiler in one invocation. Supporting circular +// dependencies over multiple invocations of the compiler would require +// explicitly running only certain passes, then compiling the other +// batch, and then finishing the original batch. It could be done with +// some pain (intermediate states would need to be serialized), but I +// only want to do it if there's a real need. Circular dependencies +// ought to be isolated fairly locally... #include #include @@ -120,8 +129,8 @@ const char *cmdname, *output_dir, *cur_input_file = "", *output_ns_name; list inputs; list nspace_stack; Language *first_lang, *output_lang; -Interface *System_Object; -Struct *System_VStruct; +InterfaceRef System_Object; +StructRef System_VStruct; AutoReleasePool autorelease_pool; void print_usage() @@ -778,6 +787,7 @@ int main(int argc, const char **argv) { int ret = run_idlc(argc, argv); autorelease_pool.clean(); + return ret; } @@ -788,7 +798,7 @@ extern "C" int yywrap() extern char *yytext; -void idl_error(char *s) +void idl_error(const char *s) { if (strlen(yytext)) fprintf(stderr, "%s:%d: %s at \"%s\".\n", cur_input_file, curline, s, yytext);