On 2 December 2022 20:30:56 CET, Jason Merrill wrote:
>Here's what I'm applying:
I meant to play with it during the weekend,
looks good, many thanks for taking care of this!
cheers,
On 11/23/22 10:28, Jason Merrill wrote:
On 11/22/22 15:25, Jason Merrill wrote:
On 11/20/22 12:06, Bernhard Reutner-Fischer wrote:
Hi Jason!
The "meh" of result-decl-plugin-test-2.C should likely be omitted,
grokdeclarator would need some changes to add richloc hints and we
would not
be able
On 11/22/22 15:25, Jason Merrill wrote:
On 11/20/22 12:06, Bernhard Reutner-Fischer wrote:
Hi Jason!
The "meh" of result-decl-plugin-test-2.C should likely be omitted,
grokdeclarator would need some changes to add richloc hints and we
would not
be able to make a reliable guess what to remove
On 11/20/22 12:06, Bernhard Reutner-Fischer wrote:
Hi Jason!
The "meh" of result-decl-plugin-test-2.C should likely be omitted,
grokdeclarator would need some changes to add richloc hints and we would not
be able to make a reliable guess what to remove precisely.
C.f. /* Check all other uses of
Hi Jason!
The "meh" of result-decl-plugin-test-2.C should likely be omitted,
grokdeclarator would need some changes to add richloc hints and we would not
be able to make a reliable guess what to remove precisely.
C.f. /* Check all other uses of type modifiers. */
Furthermore it is unrelated to DE
Hi Jason!
Possible test.
An existing test might be to equip the existing warning for
bool unsigned double meh(void) {return 0;}
with a fix-it hint instead of the brief
error: two or more data types in declaration of ‘meh’.
Likewise for
bool unsigned meh(void) {return 0;}
error: ‘unsigned’ speci
On Fri, 18 Nov 2022 11:06:29 -0500
Jason Merrill wrote:
> Ah, so the problem is deferred parsing of methods, rather than
> templates. Building the DECL_RESULT sooner does seem like the right
> approach to handling that, whether that's in grokfndecl or grokmethod.
> >> I'd like to get the temp
On 11/18/22 05:49, Bernhard Reutner-Fischer wrote:
On Thu, 17 Nov 2022 18:52:36 -0500
Jason Merrill wrote:
On 11/17/22 14:02, Bernhard Reutner-Fischer wrote:
On Thu, 17 Nov 2022 09:53:32 -0500
Jason Merrill wrote:
Instead, you want to copy the location for instantiations, i.e. check
DECL_
On Thu, 17 Nov 2022 18:52:36 -0500
Jason Merrill wrote:
> On 11/17/22 14:02, Bernhard Reutner-Fischer wrote:
> > On Thu, 17 Nov 2022 09:53:32 -0500
> > Jason Merrill wrote:
> >> Instead, you want to copy the location for instantiations, i.e. check
> >> DECL_TEMPLATE_INSTANTIATION instead of !DE
On 11/17/22 14:02, Bernhard Reutner-Fischer wrote:
On Thu, 17 Nov 2022 09:53:32 -0500
Jason Merrill wrote:
On 11/17/22 03:56, Bernhard Reutner-Fischer wrote:
On Tue, 15 Nov 2022 18:52:41 -0500
Jason Merrill wrote:
On 11/12/22 13:45, Bernhard Reutner-Fischer wrote:
gcc/cp/ChangeLog:
On Thu, 17 Nov 2022 09:53:32 -0500
Jason Merrill wrote:
> On 11/17/22 03:56, Bernhard Reutner-Fischer wrote:
> > On Tue, 15 Nov 2022 18:52:41 -0500
> > Jason Merrill wrote:
> >
> >> On 11/12/22 13:45, Bernhard Reutner-Fischer wrote:
> >>> gcc/cp/ChangeLog:
> >>>
> >>> * decl.cc (start_fun
On 11/17/22 03:56, Bernhard Reutner-Fischer wrote:
On Tue, 15 Nov 2022 18:52:41 -0500
Jason Merrill wrote:
On 11/12/22 13:45, Bernhard Reutner-Fischer wrote:
gcc/cp/ChangeLog:
* decl.cc (start_function): Set the result decl source location to
the location of the typespec.
--
te stuff is, i thought
i would not need it at all but had hoped that there is a spot where
both declspec are at hand and something is "derived" from the templates.
>
> > + return ret;
> > }
> >
> > /* Returns true iff an EH_SPEC_BLOCK should be
On 11/12/22 13:45, Bernhard Reutner-Fischer wrote:
gcc/cp/ChangeLog:
* decl.cc (start_function): Set the result decl source location to
the location of the typespec.
---
Bootstrapped and regtested on x86_86-unknown-linux with no regressions.
Ok for trunk?
Cc: Nathan Sidwell
Cc
gcc/cp/ChangeLog:
* decl.cc (start_function): Set the result decl source location to
the location of the typespec.
---
Bootstrapped and regtested on x86_86-unknown-linux with no regressions.
Ok for trunk?
Cc: Nathan Sidwell
Cc: Jason Merrill
---
gcc/cp/decl.cc | 15 +++
15 matches
Mail list logo
