[Swig-devel] [ swig-Bugs-943169 ] Separate "tag" namespace (of ANSI C) is broken in CVS SWIG

[SourceForge.net <no...@so...>]

Bugs item #943169, was opened at 2004-04-28 05:40
Message generated for change (Comment added) made by olly
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101645&aid=943169&group_id=1645

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: parsing
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Matthias Koeppe (mkoeppe)
Assigned to: David M. Beazley (beazley)
Summary: Separate "tag" namespace (of ANSI C) is broken in CVS SWIG

Initial Comment:
Some recent change since the release of SWIG 1.3.21 has
broken the separate namespace in which union, struct,
enum tags live (in ANSI C, not in C++).

I have code that uses variables of the same name as some
union/struct/enum tag name.  This used to work with
SWIG 1.3.21 and some later CVS versions, but now it is
broken.  SWIG now warns that the variable is a
duplicate identifier and fails to wrap it.

This is my test case, which I have also put into the
test suite as
Examples/test-suite/tag_no_clash_with_variable.i:

------------------------------
/* This is a test case for -*- C -*- mode. */
%module tag_no_clash_with_variable

%inline %{

/* error_action is only a tag, not a type... */
enum error_action {
    ERRACT_ABORT,
    ERRACT_EXIT, 
    ERRACT_THROW
};

/* ... thus it does not clash with a variable of the
same name. */ 
enum error_action error_action;

/* Likewise for structs: */

struct buffalo { 
  int foo;
};

struct buffalo buffalo; 

/* And for union */

union onion {
  int cheese;
};

union onion onion;
 
%}
------------------------------

I think this is important to fix, because I have
frequently seen C code that depends on this separate
namespace.  (Not only my own code.)


----------------------------------------------------------------------

>Comment By: Olly Betts (olly)
Date: 2010-09-27 15:27

Message:
This looks like parsing rather than codegen.

I think r5847 may have introduced this issue, but I haven't checked
behaviour before/after to verify this.

This issue is still present in SVN trunk after 2.0.0 (r12229).

----------------------------------------------------------------------

Comment By: Olly Betts (olly)
Date: 2010-09-27 15:27

Message:
This looks like parsing rather than codegen.

I think r5847 may have introduced this issue, but I haven't checked
behaviour before/after to verify this.

This issue is still present in SVN trunk after 2.0.0 (r12229).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101645&aid=943169&group_id=1645