Comments

This gccgo patch cleans up the error internationalization. With this
patch I think no calls to error_at use _(). All calls which pass
strings to functions which call error_at use _().
Since I want to eventually make the Go frontend proper independent of
gcc, I'm going to have to work out how to handle the special gcc
formatting characters I am currently using, like %< and so forth. I'm
not sure what the right approach is going to be there. So this is an
interim patch along the way to gcc-independent error handling, which at
least gets things right for now.
Committed to gccgo branch.
Ian

On Tue, 16 Nov 2010, Ian Lance Taylor wrote:
> Since I want to eventually make the Go frontend proper independent of> gcc, I'm going to have to work out how to handle the special gcc> formatting characters I am currently using, like %< and so forth. I'm> not sure what the right approach is going to be there. So this is an> interim patch along the way to gcc-independent error handling, which at> least gets things right for now.
I don't see a particular problem with using those formats and defining
them to be part of the interface that the front end uses to any back end
it is hooked up to; it's a reasonably well-defined, reimplementable
interface. It's the huge number of direct uses of "tree" interfaces in
the gofrontend/ directory I'd consider the most obvious major separation
issue; for a proper separation, I think everything that deals with trees
should be considered to be on the GCC side rather than part of the front
end proper (just as with the Ada front end).

"Joseph S. Myers" <joseph@codesourcery.com> writes:
> On Tue, 16 Nov 2010, Ian Lance Taylor wrote:>>> Since I want to eventually make the Go frontend proper independent of>> gcc, I'm going to have to work out how to handle the special gcc>> formatting characters I am currently using, like %< and so forth. I'm>> not sure what the right approach is going to be there. So this is an>> interim patch along the way to gcc-independent error handling, which at>> least gets things right for now.>> I don't see a particular problem with using those formats and defining > them to be part of the interface that the front end uses to any back end > it is hooked up to; it's a reasonably well-defined, reimplementable > interface. It's the huge number of direct uses of "tree" interfaces in > the gofrontend/ directory I'd consider the most obvious major separation > issue; for a proper separation, I think everything that deals with trees > should be considered to be on the GCC side rather than part of the front > end proper (just as with the Ada front end).
Completely agreed about the tree code. I'm working on moving them, but
doing it cleanly requires a bunch of plumbing.
Not sure how I feel about the formatting code.
Ian