[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RFC: custom error messages
Re: RFC: custom error messages
Fri, 17 Jan 2020 00:56:29 +0100
On Dienstag, 14. Januar 2020 21:24:59 CET Akim Demaille wrote:
> Hi Christian,
> Thanks for your answer! I definitely need feedback on these matters.
> > Le 14 janv. 2020 à 14:50, Christian Schoenebeck
<address@hidden> a écrit :
> >> I wouldn't call memory management in yacc.c "easy": lots of efforts
> >> are made to allocate on the call stack, and to avoid malloc.
> > For such a new API function it would be easier, e.g. because you don't
> > have to take care about breaking existing users' code. So you could e.g.
> > add an optional allocator argument (where NULL would use Bison's default
> > allocation) for this new API function, or a macro that could be redefined
> > by users, etc. So there would be a bunch of options to address this
> > concern.
> I'm looking for answers that apply in all the backends, so I'm trying
> to stay away from macros. C++ developers also tend to despise them.
Yes, but unfair comparison. With C++ you can avoid many macros by using
templates and/or lambda expressions, without facing downsides like reduced
optimization potential by the compiler or increased memory pressure or
extensive amount of code, unsafety, etc.
> The current state of my draft looks like this:
> /* Put in YYARG at most YYARGN of the expected tokens given
> the current YYCTX, and return the number of tokens stored
> in YYARG.
> If YYARG is null, return the number of expected tokens. */
> static int
> yyexpected_tokens (const yyparse_context_t *yyctx,
> int yyarg, int yyargn);
> WDYT? It should satisfy those who are ready to pay for a dynamic
> allocation, and satisfy those who want a bounded one, at compile
> time. Anyway, it is always bounded by YYNTOKENS.
Well, it would be fine with me, but not sure if it would for everyone.
Disadvantage might be that user code would always need to allocate
YYNTOKENS * sizeof(int) for calling this function (e.g. embedded devices).
I haven't seen your implementation, but remembering how I implemented it, it
is probably not just a single table lookup or anything comparable simple
action as efficient as Theta(1), right? I mean you are probably walking the
tables, so a function interface taking an index as argument would not be an
option for runtime efficiency reason, right?
> >> I do not plan to expose an enum for symbol numbers. What value would
> >> it bring to give name to these numbers?
> > To make it clear which internal numbers are actually reflecting user's
> > rules/
> Please, do not use "rule" when you mean "nonterminal symbol". It
> seems to confuse some people.
I knew I'll get that ticking-off. :) "nonterminal symbol" is too long for
always using it, and most people know the semantic of "rule" in the context of
grammars. Invent a better, non ambiguous short term as alternative then. ;-)
> >> I fully subscribe to this view, but string literals are definitely not
> >> the way to go. So a few months ago I realized that what we really need
> >> to do is to merge Joel E. Denny's PhD into Bison
> >> (https://tigerprints.clemson.edu/all_dissertations/519/).
> >> _That's_ the real way forward. That's Bison 4.
> > So IMO all other issues discussed here so far would be in the shadow of
> > this major new feature anyway.
> Absolutely. Joel did a wonderful work. And it's a pity that it
> went unnoticed for so long.
> > Do you plan to "merge" the high level (user visible) aspects of this
> > built-in scanner support feature "as-is", or have you already ideas about
> > adjusting certain high-level aspects (if that's not too early to discuss
> > at all)?
> So far, I don't see things I would change. I have not had the
> chance to toy with his version of Bison, and there are legal
> matters to settle. Also, his schedule is very tight. But Joel
> and I both agree the marging should happen. It is far too soon
> for the details though.
> That being said, if you have comments on this regard, you're most
> welcome to shoot!
Sure, but I'll wait for you to resolve the legal matters first.
Any chance that this would be released under a more permissive license, e.g.
> > Last question: I noticed you mentioned it was already hard enough to test
> > Bison code right now. Would it make sense to establish some kind of well
> > defined, distributed test case mechanism for upstream projects? I mean in
> > the sense that upstream projects using Bison would write test cases for
> > their own specific use cases of Bison by using a some kind of defined
> > interface for you to automatically grab, compile and execute them?
> That would be very helpful, indeed. But in a way, that's the point
> of the betas... It's not automated, but, well, I do count on you
> guys to really give a shot at the betas and report your mileage.
> On this regard Frank's feedback is extremely valuable. Even when
> his answer is just "runs fine with my stuff": at least I know someone
> else tried, and it gives me _some_ confidence in the release.
The only way to handle QA are automated tests nowadays. That's the only way to
go. You barely find people testing things manually today in regular release
cycles, especially when it comes to tools. Among developers you also see the
trend that more and more are not running their "own" software manually at all;
they just write tests (which run automated on remotes), or even: are just
reviewing those submitted by other people.
Likewise you can be sure I'll get my hands on those planned builtin scanner
features once they are there, but I won't be able test every Bison release
manually. That's simply not possible.
> If you look at the past, it's clear that QA is insufficient for
> - v2.7.90 v2.7.91 v3.0 v3.0.1 v3.0.2 v3.0.3 v3.0.4 v3.0.5
> - v3.1
> - v3.1.90 v3.1.91 v3.2 v3.2.1 v3.2.1 v3.2.2 v3.2.3 v3.2.4
> - v3.2.90 v3.2.91 v3.3 v3.3.1 v3.3.2
> - v3.3.90 v3.3.91 v3.4 v3.4.1 v3.4.2
> - v3.4.90 v3.4.91 v3.4.92 v3.5
> In spite of the two betas of v3.2, v3.3 and v3.4, bug fix releases
> were needed. And I have 3.5.1 ready to be released, although there
> were three betas.
> I don't know how to improve this.
> However, when I was referring to the complexity of testing Bison,
> I was thinking about the test suite: I try to always create
> test cases for the regressions we discover, and for the features
> I add. But it's difficult, and hard to predict which combination
> of features would break. And it's impossible to try all the possible
Yeah, that's what I assumed and hence my idea about some kind of formal
interface for automated downstream test cases. That way you would always have
feedback about feature set combinations projects are really using, and
immediate feedback already even if some yet unreleased change would break
something for any downstream project,
It is about saving time as you can see and being able to concentrate on things
that really matter instead of having to write all those tests by yourself.
And downstream projects would benefit from probably having to maintain less
Bison version checks, and/or being automatically informed very early about
upcoming backward incompatibility issues to be handled and/or trying to react
by sending a veto email to prevent that. :)
But just an idea ...
Re: RFC: custom error messages, Rici Lake, 2020/01/06
Re: RFC: custom error messages, Adrian Vogelsgesang, 2020/01/08
- [PATCH 01/12] yacc.c: extract yyerror_message_arguments, (continued)
- [PATCH 01/12] yacc.c: extract yyerror_message_arguments, Akim Demaille, 2020/01/16
- [PATCH 04/12] yacc.c: add custom error message generation, Akim Demaille, 2020/01/16
- [PATCH 06/12] tests: compute verbose error messages from the custom ones, Akim Demaille, 2020/01/16
- [PATCH 05/12] yacc.c: check custom error messages, Akim Demaille, 2020/01/16
- [PATCH 07/12] yacc.c: isolate yyexpected_tokens, Akim Demaille, 2020/01/16
- [PATCH 08/12] yacc.c: let custom error messages see the location, Akim Demaille, 2020/01/16
- [PATCH 09/12] yacc.c: check custom error messages with parse-params, Akim Demaille, 2020/01/16
- [PATCH 10/12] tests: a clearer test for parse-params, Akim Demaille, 2020/01/16
- [PATCH 12/12] yacc.c: portability to G++ 4.8, Akim Demaille, 2020/01/16
- [PATCH 11/12] yacc.c: pass the parse-params to yyreport_syntax_error, Akim Demaille, 2020/01/16
- Re: RFC: custom error messages,
Christian Schoenebeck <=
- Re: RFC: custom error messages, Akim Demaille, 2020/01/17
- Re: RFC: custom error messages, Christian Schoenebeck, 2020/01/18