Hi again,
On 07/03/2018 21:49, Paolo Carlini wrote:
... If you ask my opinion, at the moment I still believe that the best
solution would be doing something at parsing time, save the
information, in a more elegant way, maybe adding a special "erroneous
TREE_VEC" flag to the TREE_VECs. I don't
Hi,
On 07/03/2018 21:23, Jason Merrill wrote:
On Wed, Mar 7, 2018 at 12:18 PM, Paolo Carlini wrote:
Hi,
[snip the various clarifications]
Il 7 Marzo 2018 17:57:07 CET, Jason Merrill ha scritto:
My thought was that this patch adds a lot of managing of the flag in
different places in the par
On Wed, Mar 7, 2018 at 12:18 PM, Paolo Carlini wrote:
> Hi,
>
> [snip the various clarifications]
>
> Il 7 Marzo 2018 17:57:07 CET, Jason Merrill ha scritto:
>>My thought was that this patch adds a lot of managing of the flag in
>>different places in the parser, whereas looking for error_mark_nod
Hi,
[snip the various clarifications]
Il 7 Marzo 2018 17:57:07 CET, Jason Merrill ha scritto:
>My thought was that this patch adds a lot of managing of the flag in
>different places in the parser, whereas looking for error_mark_node in
>the template parms here would be just in one place. But
On Wed, Mar 7, 2018 at 10:55 AM, Paolo Carlini wrote:
> Hi,
>
> On 07/03/2018 16:38, Jason Merrill wrote:
>>
>> On Tue, Mar 6, 2018 at 5:00 PM, Paolo Carlini
>> wrote:
>>>
>>> On 06/03/2018 21:33, Jason Merrill wrote:
Interesting, that seems like a promising idea. I'm not sure we need
Hi,
On 07/03/2018 16:38, Jason Merrill wrote:
On Tue, Mar 6, 2018 at 5:00 PM, Paolo Carlini wrote:
On 06/03/2018 21:33, Jason Merrill wrote:
Interesting, that seems like a promising idea. I'm not sure we need
to do this based on an error in a default template arg, though; can we
drop
+ ||
On Tue, Mar 6, 2018 at 5:00 PM, Paolo Carlini wrote:
> On 06/03/2018 21:33, Jason Merrill wrote:
>>
>> Interesting, that seems like a promising idea. I'm not sure we need
>> to do this based on an error in a default template arg, though; can we
>> drop
>>
>> + || error_operand_p (TREE_PURPOSE (p
Hi,
On 06/03/2018 21:33, Jason Merrill wrote:
Interesting, that seems like a promising idea. I'm not sure we need
to do this based on an error in a default template arg, though; can we
drop
+ || error_operand_p (TREE_PURPOSE (parameter)))
?
Good point, yes, I believe we can, isn't necessary
Interesting, that seems like a promising idea. I'm not sure we need
to do this based on an error in a default template arg, though; can we
drop
+ || error_operand_p (TREE_PURPOSE (parameter)))
?
Jason
Hi again,
On 06/03/2018 19:58, Paolo Carlini wrote:
.. g, consider the patch withdrawn in its detailed form, I have a
new testcase which add some random code after that ill-formed class
and it's mishandled, it ICEs again.
The below avoids the idiotic thinko (I added a testcase for that) and
.. g, consider the patch withdrawn in its detailed form, I have a
new testcase which add some random code after that ill-formed class and
it's mishandled, it ICEs again.
Well, I would still appreciate some feedback about the general idea...
Paolo.
11 matches
Mail list logo