Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110773
MIME-Version: 1.0
References: <c11e2cfd-aa74-c64e-c8f7-7ddd5cde22ce@gmail.com>
 <C9EDDF3F-1CC1-4252-AF8A-9470B4527754@gmail.com> <CALKiJKpReoUVMD0Z5DUmmdTO4VXLX-auP98cfoinO+hgBbQnSA@mail.gmail.com>
 <0915B96B-DFF1-4F24-993B-350D36EB9A74@gmail.com>
In-Reply-To: <0915B96B-DFF1-4F24-993B-350D36EB9A74@gmail.com>
Date: Mon, 29 Jun 2020 12:15:40 +0100
Message-ID: <CALKiJKph5s5MXxAPbqwe1099Lh=AfSBgfOdHY-=__S2RTB_5Yw@mail.gmail.com>
To: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000007e786d05a9372e0d"
Subject: Re: [PHP-DEV] Improving output of syntax errors
From: rowan.collins@gmail.com (Rowan Tommins)

--0000000000007e786d05a9372e0d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, 29 Jun 2020 at 10:42, Claude Pache <claude.pache@gmail.com> wrote:

>
> At this point, I don=E2=80=99t feel strongly, because currently, when I s=
ee
> =E2=80=9Cunexpected '''' (T_CONSTANT_ENCAPSED_STRING)=E2=80=9D,
> my automatism is not looking for a string with specific quote style (whic=
h
> is not evident by looking at four consecutive quotes), but for a missing =
or
> misplaced punctuation mark, because, by experience, it is most of the tim=
e
> the root cause of an error message containing that specific token name.
>


Yes, there's a bunch of cases where what the parser sees and expects isn't
really that helpful, and what's parsed as a zero-length string may not
actually look that way in the source. There's probably diminishing returns
trying to handle that at the message level, rather than extending the
parser itself as has been done for mis-matched brackets.




> Another way to give the programmer the appropriate information, is
> replacing =E2=80=9Cquoted string=E2=80=9D with =E2=80=9Csingle-quoted str=
ing=E2=80=9D and =E2=80=9Cdouble-quoted
> string=E2=80=9D.
>


That would actually make a lot of sense. I'll have a look if it can be done
without changing the actual parser definitions (which recognise both forms
as the same token type).




> And while I am thinking about it: a case that tends to cause divergent
> squint is: unexpected '"', which you changed into: unexpected token """. =
In
> that specific case, it would be nice if it the common name of the offendi=
ng
> token was spelt out, something like: unexpected double quotation mark.
>


That would be a reasonable special-case; theoretically, the same would
apply for a lone single-quote, although I think the parser happens never to
see that as a separate token.


Thanks for the feedback,
--=20
Rowan Tommins
[IMSoP]

--0000000000007e786d05a9372e0d--