On Wed, Apr 13, 2011 at 3:46 PM, Jason Merrill wrote:
> On 04/11/2011 04:50 PM, Rodrigo Rivas wrote:
>>
>> Because the type of the expression must have complete type *only* if
>> it is an array.
>
> Actually, if it has class type, it must also have a complete type or t
27;t think that should matter too much.
Regards
--
Rodrigo
Changelog:
gcc/cp/
2011-03-10 Rodrigo Rivas Costa
* decl2.c (cp_check_const_attributes): New.
(cplus_decl_attributes): Call cp_check_const_attributes.
gcc/testsuite/
2011-03-10 Rodrigo Rivas Costa
* g++.dg/
On Fri, Mar 11, 2011 at 6:51 AM, Jason Merrill wrote:
> How about just calling maybe_constant_value call after the
> fold_non_dependent_expr call in cp_parser_parenthesized_expression_list?
Well, I first tried something like this, but the key problem is the
*non_dependent* part, so it does nothin
On Fri, Mar 11, 2011 at 4:58 PM, Jason Merrill wrote:
> Sure, I guess calling it in one place is better. But I think let's wait
> until 4.6.1 for this patch.
Oh, I didn't notice the only-regression-fixes status. No problem.
--
Rodrigo.
Hi again.
Here it is my first try at this. I have changed the list to
gcc-patches, I don't know if cross post would be correct.
Please, note that this patch is not finished: the new test cases are
still missing, and expect format mistakes, misspellings and the
like...
A few comments:
1. I'm not
On Tue, Mar 29, 2011 at 10:12 AM, Jonathan Wakely wrote:
> Should we consistently refer to % so the keyword is highlighted?
Now that you say... I've not been quite consistent. We could say
"range-based %", with only a dash between 'range' and 'based'.
On Tue, Mar 29, 2011 at 5:46 PM, Gabriel Dos Reis
wrote:
> or "new-style for loop"?
Well, that is what they are called in Java, isn't it? And the syntax
is just the same, so it would make kind of sense.
But in the C++0x draft and the GCC docs it is almost always called
"range-based for loops, so I
On Tue, Mar 29, 2011 at 8:22 PM, Jonathan Wakely wrote:
> How about "No suitable % and % functions found for range
> expression of type %qT in % statement" ?
Nice.
But the problem here is that there are a lot of different error conditions:
1. begin member but not end member.
2. end member but not
On Tue, Mar 29, 2011 at 11:13 PM, Jonathan Wakely wrote:
Thank you for your suggestions!
IMO, error cases 3 (hey, two 3s!), 4 and 6 are not so likely, as
including any STL container header will make a begin and an end
functions declared, though maybe not usabe. In these cases the most
probable err
On Thu, Mar 31, 2011 at 7:22 PM, Jason Merrill wrote:
> On 03/28/2011 08:28 PM, Rodrigo Rivas wrote:
>>
>> A few comments:
>> 1. I'm not sure about what should happen if the begin/end found in class
>> scope are not ordinary functions.
>
> Whatever range.be
Hi!
It took some time but I finally re-wrote the patch and added a few testsuites.
A few comments as usual:
I've moved the array stuff into cp_parser_perform_range_for_lookup. I
think that it belongs there: it's just a special lookup case .
I finally agreed with Jason about calling lookup_member
it.
Also, I added a few more test cases: one with begin/end as member
functions with default arguments and member template functions with
default template arguments; other with begin/end member functions as
virtual functions.
And since we are approaching the acceptability, here it is the changelog:
12 matches
Mail list logo
