On Sat, May 9, 2020 at 3:22 AM Akim Demaille <a...@lrde.epita.fr> wrote: > > Hi Joshua, > > > Le 8 mai 2020 à 19:26, Joshua Watt <jpewhac...@gmail.com> a écrit : > > > > On 5/8/20 2:39 AM, Akim Demaille wrote: > > > >> It appears that your approach is not sufficient for synclines. I toyed > >> with it, and the generated #lines are not adjusted. > >> > >> I'm somewhat bugged that this relies on a new option, mostly because it > >> means that it cannot be controlled from within the grammar file itself. > >> Do you really think we need a list of rules? Do you have evidence for > >> that need? > >> > >> If not, maybe we can find a solution which would rely only on %define/-D. > > > > > > I think there is a bit of missing background, which I will attempt to > > provide here (and fix up my commit message to also include): > > > > This option is intended to be use in conjunction with the > > "-fdebug-prefix-map" [1] option in GCC (and other compilers). > > That's news to me, thanks a lot for the additional details. Prior art > clearly settles it: that's the right name for the option, and of course we'll > use `=` too. > > > When this option is used, you don't necessarily *have* to change the #line > > directives because the compiler will map them for you when the source code > > is compiled. However, I can also see the argument that bison should handle > > the mapping internally, and it doesn't look like it would be too hard to > > apply the mapping to #line directives also, so I can do that if you would > > like. > > Yes, I understand why it's not needed, but I would definitely like the #lines > to be adjusted too. You seem to grok enough of bison to handle it yourself, > otherwise I'll do it afterwards. > > > I don't think this is the type of thing you'd want to be able to control > > from the grammar files themselves; it's entirely an option that needs be > > specified by the user compiling the source code (since only they know the > > prefix mapping) and allowing to be set in the grammar file seems like it > > would only cause confusion and/or broken compiles (at least for the purpose > > of making builds reproducible). > > I've seen projects with several build systems, and being able to factor > things is a good thing. But I agree it's a weak argument here. > > > >> We are now getting rid of our hand-written list structures > >> in favor gnulib's implementation of lists. Not much of a big deal, > >> but I'd rather avoid stepping backward at this point. > > > > Ok, I'm not very familiar with gnulib, but I'll look up how to do that and > > fix it. > > Do waste time on this though. If you get it to work quickly, all the better. > > >> Out of curiosity, why do you prefer "&filename[oldprefix_len]" to > >> "filename + oldprefix_len"? The latter seems more natural to me. > > That's a real question :)
Habit. I've written a lot of code where pointer math was eschewed as being "unclear", with a preference for address of index, with the idea its more clear. I'm not real sold it matters :) > > > I did originally want to put it in output.at, but it looked like that was > > all language agnostic. I'll move it there and add the other relevant > > languages. > > Excellent. > > You don't need to make one large commit. Each commit must pass the test > suite, but we like small commits, so you can treat skeletons one by one for > instance, or adding tests later. > > Cheers!
