Bug 2569 - IDL construct doesn't compile
Summary: IDL construct doesn't compile
Status: ASSIGNED
Alias: None
Product: TAO
Classification: Unclassified
Component: IDL Compiler (show other bugs)
Version: 1.5.1
Hardware: x86 Linux
: P3 normal
Assignee: DOC Center Support List (internal)
URL:
Depends on: 2571
Blocks:
  Show dependency tree
 
Reported: 2006-06-28 08:52 CDT by Johnny Willemsen
Modified: 2018-01-15 11:21 CST (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Johnny Willemsen 2006-06-28 08:52:29 CDT
The IDL construct below doesn't compile with the IDL compiler when it is build
with intel c++ or sun C++. Added already a test case for tao_idl, just storing
it as reference to refer to in the future. This does compile when interface B is
a real interface instead of just forward declared. Jeff is already aware of this.

module A
{
  typeprefix A "TAO";
  interface B;
  interface C{
    void op (in B a);
  };
};
Comment 1 Johnny Willemsen 2006-06-28 14:30:22 CDT
Did some debugging, it seems that in IDL_GlobalData::update_prefix (char
*filename) the check at the bottom if (!this->pd_in_main_file) is true on
windows making the stack is empty after that, but on linux I can see that this
if returns false, meaning the stack contains one entry with an empty string and
then the things go wrong later. This flag, pd_in_main_file is set from
idl_parse_line_and_file in lex.yy.cpp, on linux I do have the data:

</TMP//TAO-IDLI_ZQAGYB.CPP> fname </TMP//TAO-IDLI_ZQAGYB.CPP>
idl_global->real_filename(), is main before 0 is real 1

where real is then 1 meaning pd_in_main_file is set to 1. 

On windows with borland I do have the following:
Comment 2 Johnny Willemsen 2006-06-28 14:34:32 CDT
<C:\DOCUME~1\JOHNNY\LOCALS~1\TEMP\TAO-IDLI_3WARO5.CPP> fname
<C:\DOCUME~1\JOHNNY\LOCALS~1\TEMP\\TAO-IDLI_3WARO5.CPP> idl
_global->real_filename(), is main before 0 is real 0

so on windows the real filename has a \\ and filename is the same file with just
\ at the end. This seems a bug to me, in DRV_pre_proc the IDL compiler should
replace \\ with \ for any file, because it later does so in its processing. When
I add the code block below to DRV_pre_proc then things also fail on windows
which makes this bug more generic. Just add the code before calling
set_real_filename, maybe add a function in utl?

      long i;
      long j;

      // Put Microsoft-style pathnames into a canonical form.
      for (i = 0, j = 0; t_ifile[j] != '\0'; i++, j++)
        {
          if (t_ifile[j] == '\\' && t_ifile[j + 1] == '\\')
            {
              j++;
            }

            t_ifile[i] = t_ifile[j];
        }

      t_ifile[i] = '\0';
Comment 3 Johnny Willemsen 2006-06-28 14:36:01 CDT
After replacing \\ with \ in the temp filename the typeprefix.idl test fails,
but when I also here replace the forward declaration B with real interface B
then things work again.
Comment 4 Johnny Willemsen 2006-07-03 05:20:35 CDT
To get the solaris/icc builds running again I have committed the following patch
that can be reverted when this bug is fixed or to reproduce this bug

--- ORBInitializer.pidl	9 May 2006 07:34:34 -0000	1.2
+++ ORBInitializer.pidl	3 Jul 2006 10:18:51 -0000
@@ -24,11 +24,13 @@
 #ifndef _ORB_INITIALIZER_PIDL
 #define _ORB_INITIALIZER_PIDL
 
+#include "tao/PI/ORBInitInfo.pidl"
+
 module PortableInterceptor {
 
   typeprefix PortableInterceptor "omg.org";
 
-  local interface ORBInitInfo;
+//  local interface ORBInitInfo;
 
   local interface ORBInitializer
   {
Comment 5 Johnny Willemsen 2006-07-03 05:23:06 CDT
also in tao/tests/idl_test/typeprefix.idl a workaround should be reverted,
change B to a forward declaration and uncomment the last block
Comment 6 Jeff Parsons 2006-07-11 22:41:16 CDT
I don't have access to these compilers, so without knowing what their 
preprocessors are doing, any fix I make would be a stab in the dark. Can this 
bug be reassigned to someone who can actually test these preprocessors? It 
doesn't require any specific knowledge of the IDL compiler or of IDL.
Comment 7 Jeff Parsons 2006-11-25 16:42:45 CST
Accepted, but my last comment still stands.