Re: Bison 3.1 check "examples/variant.cc" fails
Hi Simon, > Le 18 sept. 2018 à 11:52, Simon Sobisch a écrit : > > Hi, I've tried to build Bison the first time from source using an old MinGW > environment. > * configure finds several things to be missing and generates replacements in > the lib directory (works very good btw) > * make passes > * make check fails: > > $ make examples/variant.cc > YACC examples/variant.cc > ?: m4 subprocess failed: No such file or directory > make: *** [examples/variant.cc] Error 1 I will need your help here, I don’t understand why it would fail. Try $ make examples/variant.cc V=1 and see if you see something fishy. Also, run this: $ ./tests/bison examples/variant.yy --trace=tools (./tests/bison is in your build dir, where you ran configure, and examples/variant.yy is in the source tree, where you untared Bison. Adjust to you own paths). This command should help you understand what is going on. > I've attached config.log and as configure doesn't seem to check for m4 > version 1.4.6 prerequisite mentioned in README: > > $ m4 --version > m4 (GNU M4) 1.4.16 > Copyright (C) 2011 Free Software Foundation, Inc. Good point. But as of today, it seems unlikely to be found :) > Is there anything more I can test? > > > Unrelated note: there was a single warning during make which may be possible > to fix, too: > > > ../lib/timevar.c:66:35: warning: 'struct rusage' declared inside parameter > list > extern int getrusage (int, struct rusage *); > ^ > ../lib/timevar.c:66:35: warning: its scope is only this definition or > declaration, which is probably not what you want I don’t understand this: you don’t have an error, so I guess getrusage is usable, yet configure:12563: gcc -o conftest.exe -g -O2 conftest.c >&5 conftest.c:189:26: fatal error: sys/resource.h: No such file or directory compilation terminated. so it is not declared in sys/resource.h. Do you know which header defines rusage on your machine?
Bison 3.1 check "examples/variant.cc" fails
Hi, I've tried to build Bison the first time from source using an old MinGW environment. * configure finds several things to be missing and generates replacements in the lib directory (works very good btw) * make passes * make check fails: $ make examples/variant.cc YACC examples/variant.cc ?: m4 subprocess failed: No such file or directory make: *** [examples/variant.cc] Error 1 I've attached config.log and as configure doesn't seem to check for m4 version 1.4.6 prerequisite mentioned in README: $ m4 --version m4 (GNU M4) 1.4.16 Copyright (C) 2011 Free Software Foundation, Inc. Is there anything more I can test? Unrelated note: there was a single warning during make which may be possible to fix, too: ../lib/timevar.c:66:35: warning: 'struct rusage' declared inside parameter list extern int getrusage (int, struct rusage *); ^ ../lib/timevar.c:66:35: warning: its scope is only this definition or declaration, which is probably not what you want Thank you, Simon config.log.tgz Description: application/compressed
Unused explicitly named references ewarning
Just a thought, Bison might issue a warning if an explicitly named reference is
not used in the action. For example, in
exp: exp[x] "/" exp[y] {…}
if the action does not have $x and/or $y.
Re: Automatially move from $n (was: C++11 move semantics)
> On 18 Sep 2018, at 04:48, Frank Heckenbach wrote: > > Hans Åberg wrote: > C++ does not support the implementation of a (tracing) GC, because the information needed, though available to the compiler, is not available from the language. The fact that it does not have a GC is another topic. >>> >>> I know and (again) I don't care because I don't want to use GC >>> anyway. You're basically discussing with yourself here. >> >> It exemplifies the of limitations C++. See below. > > Nope. Again: compile-time != runtime. It is funny, below you give a link of people wanting to add unavailable runtime information to compile time. >>> My option? I'm not having this problem. >> >> So then why bother bringing it up in the first place? > > Funnily, I preemptively answered this question just in the next > sentence that you also quoted: Hilariously, you rather introduced this new topic, when I discussed something else. >>> Again, I only brought up the >>> make_pair thing as a counterexample to your claim that an automatic >>> break would avoid any possible double-move. >> >> You gave a counterexample of something else than what I discussed. > > Nope, you said: "So a way to make it safe is to jump out of the > action statement.", That referred to that other feature. > I replied: "Not necessarily: You could use it > twice within one expression (unsafe even with jump)", and you > replied: "That would probably not be possible, if one gets an > automated break after it." Then I gave an example of what I had said > before, that it *is* possible to use it twice in one statement, > counter to your claim. I never said it occured in my code, just > explained why break isn't the solution. > > You can check it here: > http://lists.gnu.org/archive/html/bug-bison/2018-09/msg00036.html Then when you clarified, I decided to follow your topic. >>> But it might be a solution to someone else's problem (or another >>> problem of mine some other day ;). >> >> Until that day, it's too esoteric to be worth implementing, in my opinion. > > Esoteric I don't know, but certainly not hard to implement. > Basically a flag that it set when moved from and causes an exception > on any subsequent access (except assignment to, and destruction, of > course). Seems like a nice student project ... :) So then implement this compile time check yourself, rather than having lengthy discussions here. > What would be much more interesting would be a generic decorator > that does this and can be applied to any type one wants to, but > that's more tricky and I think impossible in current C++ because one > can't wrap "any method" generically. Maybe if Herb Sutter's > metaclass proposal takes off, one (far) day ... > https://herbsutter.com/2017/07/26/metaclasses-thoughts-on-generative-c/ Even though the compiler may have access to the information to check that, you don't have access to that from the language itself. >>> >>> - Within(!) the compiler, more general, but a job for compiler >>> experts, not me. >> >> You won't get that for the same reason as in the GC case above. > > And why would that be? You said yourself that "the compiler may have > access to the information to check that". Why don't you check with the GCC people if they want to implement it.
