Re: [ C++ 4.6 Patch] allow uninitialized const or reference members with -fpermissive

OK, thanks. Jason

Re: [ C++ 4.6 Patch] allow uninitialized const or reference members with -fpermissive

2011/5/25 Jason Merrill : > On 05/24/2011 04:40 PM, Fabien Chêne wrote: >> >> Indeed. I have also added two testcases to check sfinae on 'new T', >> with and without -fpermissive, which leads to a different result. > > We don't want to do that; overload resolution should always produce the same > r

Re: [ C++ 4.6 Patch] allow uninitialized const or reference members with -fpermissive

On 05/24/2011 04:40 PM, Fabien Chêne wrote: Indeed. I have also added two testcases to check sfinae on 'new T', with and without -fpermissive, which leads to a different result. We don't want to do that; overload resolution should always produce the same result. We can only be permissive in n

Re: [ C++ 4.6 Patch] allow uninitialized const or reference members with -fpermissive

2011/5/22 Jason Merrill : > I think you also need something to avoid returning error_mark_node from > build_new_1. Indeed. I have also added two testcases to check sfinae on 'new T', with and without -fpermissive, which leads to a different result. Tested x86_64-unknown-linux-gnu. OK for 4.6 ? I

Re: [ C++ 4.6 Patch] allow uninitialized const or reference members with -fpermissive

I think you also need something to avoid returning error_mark_node from build_new_1. Jason

[ C++ 4.6 Patch] allow uninitialized const or reference members with -fpermissive

Hi, As discussed off-list with Jason, it would be better to use permerror instead of error when diagnosing uninitialized const or reference members. At least for 4.6. That would be usefull to provide a transition for invalid code that exploits the following accept-invalids: PR 25811, PR 43719, PR