[3/5] dtc: Cleanup yyerrorf() function

[Jon Loeliger]

> Currently, we put the source file name into the yylloc variable, but
> never use the stored value.  Instead the yyerrorf() function directly
> accesses srcpos_file to get the input file name.
> 
> That works in practice, but is likely not to always be correct if we
> ever re-enable the glr-parser option.  Even now, its correctness
> relies on the exact point in time bison executes the semantic rules
> w.r.t. to the lexing rules, which is probably correct but not
> obviously correct, which is far from ideal.
> 
> So, this patch replaces yyerrorf() with a srcpos_error() function
> which pulls the filename information out of the yylloc variable, which
> bison is explicitly supposed to get right for us.
> 
> Signed-off-by: David Gibson <david at gibson.dropbear.id.au>

This isn't how I'd like to see this work at all.

The original intent goes like this:

- As a file is referenced, it is put on a list (or array) of files.
  This list is essentially write-only so that any file ever
  referenced accumulates into this list.

- The source positions maintain a pointer (or index) into that
  table of file names.

- The table of files is *always* available, even long after
  parsing has finished.

- There is an entirely different stack of directories that
  tracks where file references are resolved.

Thus, a routine like srcpos_error() should take a srcpos
for its basis information.  Yes, that is the same type
as the YYLTYPE during parsing, but my point is that the
srcpos type is conceptually longer lasting than just parsing
and will be available by later semantic processing passes too.

Thanks,
jdl