Applied RE: [cdt-patch] Fix for PR36766, 36767, 36769 (STL parsing probl

[John Camelon <jcamelon@xxxxxxxxxx>]

The patch is still valid.  Applied
to both HEAD and PST branches.  
Thanks

JohnC

victor.mozgin@xxxxxxxxxxxxx
Sent by: cdt-patch-admin@xxxxxxxxxxx

06/09/2003 12:52 PM

Please respond to
cdt-patch@xxxxxxxxxxx

To	cdt-patch@xxxxxxxxxxx
cc	Andrew Niefer/Ottawa/IBM@IBMCA
Subject	RE: [cdt-patch] Fix for PR36766, 36767, 36769 (STL parsing proble        ms)

        Hi
Andrew,
 
Thanks for clarification, I was
stuck on ctors/dtors/operators, and didn't think about conversions - I'll
try to check this case. Well, I think the patch is still valid as it should
solve the rest of the problems in these PRs (I believe ;)). Case of conversion
function can be a separate PR.
 
        /Vic
-----Original Message-----
From: Andrew Niefer [mailto:aniefer@xxxxxxxxxx] 
Sent: Monday, June 09, 2003 5:03 PM
To: cdt-patch@xxxxxxxxxxx
Subject: RE: [cdt-patch] Fix for PR36766, 36767, 36769 (STL parsing
proble ms)


Hi Victor, 
I think that particular operator was meant to be a conversion function,
in which case its mostly correct. 

According to the ANSI spec  12.3.2: 
A conversion function is a member function of a class X with a name of
the form 
        conversion-function-id :  operator  
conversion-type-id 
        conversion-type-id :  type-specifier-seq
  conversion-declarator? 
        conversion-delcaration : ptr-operator  conversion-declarator?
Neither paramter types nor return type can be specified.  Classes,
enumerations, and typedef-names shall not be declared in the type-specifier-seq.
 The type of a conversion function is "function taking no parameter,
returning conversion-type-id 

So the only problem with the test is that op would have been a class, enumeration
or typedef. 
A simple example looks like this: 

template < class T > class X { 
 public: 
        operator int( ); 
} 

template <class T >  X<T>::operator int() { /*...*/}

X < char > x; 
int i = int(x);        //calls X::operator int()


-Andrew

victor.mozgin@xxxxxxxxxxxxx
Sent by: cdt-patch-admin@xxxxxxxxxxx

06/07/2003 06:34 PM

Please respond to
cdt-patch@xxxxxxxxxxx

To	cdt-patch@xxxxxxxxxxx
cc
Subject	RE: [cdt-patch] Fix for PR36766, 36767, 36769 (STL parsing proble        ms)

        Err, missed another one - it seems that ACEFailedTest.java
is redundant also. Tests testBug36766and36769x() in DOMTests.java cover
all these cases already. Testcase in ACEFailedTest still fails because
it contains incorrect operator overloading declaration:
  
template <class A, B> cls<A, C>::operator op &() const
{} 
  
There is no return type, so parse naturally fails (non-existent "op
&" operator name is unimportant for CDT parser). If changed to
  
template <class A, B> cls<A, C>& cls<A, C>::operator&
() const {} 
  
parse succeeds. 
  
        /Vic
  
-----Original Message-----
From: victor.mozgin@xxxxxxxxxxxxx [mailto:victor.mozgin@xxxxxxxxxxxxx]
Sent: Saturday, June 07, 2003 1:10 PM
To: cdt-patch@xxxxxxxxxxx
Subject: [cdt-patch] Fix for PR36766, 36767, 36769 (STL parsing problems)

    Here is the patch that should take care of parsing templated
constructor/destructor/operator declarations. By the way, STLFailedTests.java
contains only testBug36805() now, and PR36805 is marked as resolved. Maybe
STLFailedTests.java can be removed? 
  
                    
           /Vic