MantisBT - GCC-XML
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0001976GCC-XMLpublic2005-06-25 14:582012-07-26 10:47
ReporterDan Churchill 
Assigned ToBrad King 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Summary0001976: typedefs declared in classes resolved to their target when used
DescriptionConsider this simple example - comments explain the problem:

// typedef defined outside of class
typedef int My_Int;

class example
{
    // typedef defined inside of class
    typedef int Examples_Int;

    // PROBLEM: the type attribute of the Arguement element for 'x' will be that of
    // FundamentalType "int" instead of Typedef "Examples_Int"
    example(float a, Examples_Int x);

    // this one works right (where the typedef exists outside of the class
    // declaration)
    example(long b, My_Int y);
};
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2012-07-26 10:47Brad KingNote Added: 0030130
2012-07-26 10:47Brad KingStatusassigned => closed
2012-07-26 10:47Brad KingResolutionopen => won't fix

Notes
(0002557)
Brad King   
2005-06-27 09:39   
Unfortunately the information the XML dump code needs to reference the original typedef is dropped by GCC's parser before the dump occurs. In the past the namespace-scope typedef did not work properly either but a solution was found. The solution does not seem to work in the class-scope typedef case though.

It may still be possible to recover this information but it will take a time investment I cannot make right now. If you want to try it look in GCC/gcc/cp/xml.c at the xml_get_idref function to get started.
(0002901)
vince   
2005-08-15 13:37   
The following change to decl2.c fixes this problem in my test set (of 126 relativley complex and diverse source files)

396d395
<
954a954
> tree type = TREE_TYPE (value);
961c961
< if (processing_template_decl)
---
> if (processing_template_decl) {
962a963,973
> }
> else {
> if (TYPE_NAME (type) != value
> && (TYPE_NAME (type) != DECL_ABSTRACT_ORIGIN (value))) {
> DECL_ORIGINAL_TYPE (value) = type;
> type = build_type_copy (type);
> TYPE_STUB_DECL (type) = TYPE_STUB_DECL (DECL_ORIGINAL_TYPE (value));
> TYPE_NAME (type) = value;
> TREE_TYPE (value) = type;
> }
> }
(0002902)
Brad King   
2005-08-15 18:10   
Thanks for the patch. I'll try it out. FYI, I've duplicated the problem in pure gcc and reported it to their bug tracker:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22573 [^]

It doesn't look like they are very interested in fixing it though.
(0003354)
Brad King   
2005-12-02 10:25   
I tried your patch and it seems to work for simple examples but caused problems when running on large projects. The nightly tests of some other projects that use GCC-XML failed the day after I committed the change so I removed it. I should have updated this bug report then but must have forgotten.

The native GCC bug report has been closed as not-a-bug. Apparently there is a debate in their community about whether typedef names should be expanded in error messages and they are leaning towards yes. Here is a patch they included related to this change:

http://gcc.gnu.org/ml/gcc-patches/2005-10/msg01052.html [^]

Unfortunately I don't have time to dig deep into the bowels of GCC and fix this myself. It looks like we're stuck until the GCC folks resolve the issue.
(0030130)
Brad King   
2012-07-26 10:47   
Closing after no updates in 7 years. The behavior will be whatever upstream GCC does.