Hello world,
here is my first patch made from the git world. It certainly took
enough time to work out how to to this, but I think I have it
figured out now...
Anyway, the fix is rather straightforward. We cannot have a reference
on a function. If this slipped through on parsing, let's issue th
On Thu, Jan 16, 2020 at 11:34:43PM +0100, Thomas Koenig wrote:
> diff --git a/gcc/testsuite/gfortran.dg/function_reference_1.f90
> b/gcc/testsuite/gfortran.dg/function_reference_1.f90
> new file mode 100644
> index 000..78c92a6f20d
> --- /dev/null
> +++ b/gcc/testsuite/gfortran.dg/function
Hello Thomas, hi all,
On 1/16/20 11:34 PM, Thomas Koenig wrote:
Anyway, the fix is rather straightforward. We cannot have a reference
on a function. If this slipped through on parsing, let's issue the
error during resolution.
Regression-tested. OK for trunk?
I think I am fine with the check it
On 1/17/20 4:49 AM, Steve Kargl wrote:
On Thu, Jan 16, 2020 at 11:34:43PM +0100, Thomas Koenig wrote:
+type(t) :: foo
+print *, foo(1)%a ! { dg-error "Function call can not contain a reference" }
I do not understand this error message, and find it to be confusing.
foo(1)%a looks like an invalid
On Fri, Jan 17, 2020 at 09:29:33AM +0100, Tobias Burnus wrote:
> On 1/17/20 4:49 AM, Steve Kargl wrote:
> > On Thu, Jan 16, 2020 at 11:34:43PM +0100, Thomas Koenig wrote:
> >> +type(t) :: foo
> >> +print *, foo(1)%a ! { dg-error "Function call can not contain a
> >> reference" }
> > I do not under
Am 17.01.20 um 15:42 schrieb Steve Kargl:
Gfortran probably should not try to guess what the user
thought s/he wanted. The generic "Syntax error" would
seem to apply here. To me, foo(1)%a looks much more like
an array reference rather than a function reference.
OK, so here's a patch which doe
On Fri, Jan 17, 2020 at 11:20:06PM +0100, Thomas Koenig wrote:
> Am 17.01.20 um 15:42 schrieb Steve Kargl:
> > Gfortran probably should not try to guess what the user
> > thought s/he wanted. The generic "Syntax error" would
> > seem to apply here. To me, foo(1)%a looks much more like
> > an arra
On 1/17/20 11:20 PM, Thomas Koenig wrote:
function_reference_1.f90:9:8:
9 | print *, foo(1)%a ! { dg-error "Syntax error" }
| 1
Error: Syntax error in expression at (1)
The error message is not helpful at all. I was recently struggling to
understand why/where some code was f
Am 18.01.20 um 12:44 schrieb Tobias Burnus:
function_reference_1.f90:9:8:
9 | print *, foo(1)%a ! { dg-error "Syntax error" }
| 1
Error: Syntax error in expression at (1)
The error message is not helpful at all.
Well, yes. It is no better than what we currently have for the
Hello world,
I found an ommission in primary.c which prevented issuing a
more specific error instead of "syntax error" for the case
when a function was declared in an EXTERNAL statement,
and I have now gone for the "Unexpected junk after foo"
variant.
Regression-tested. OK for trunk?
Regards
Hello Thomas,
looks good to me. Nice catch the missing "break".
Tobias
PS: I think it does not exercise a differ code path, but instead of
derived types, using a character string works as well. The following is
accepted with the unmodified trunk:
character(len=4):: str
print *, str(1)(1:4)
11 matches
Mail list logo
