On 11 September 2017 at 17:42, Jeff Law wrote:
> On 05/28/2017 03:11 PM, Iain Buclaw wrote:
>> This patch adds the D front-end implementation, the only part of the
>> compiler that interacts with GCC directly, and being the parts that I
>> maintain, is something that I can talk
On 05/28/2017 03:11 PM, Iain Buclaw wrote:
> This patch adds the D front-end implementation, the only part of the
> compiler that interacts with GCC directly, and being the parts that I
> maintain, is something that I can talk about more directly.
>
> For the actual code generation pass, that
On Wed, 14 Jun 2017, Iain Buclaw wrote:
> Just to make sure I understand the structure correct. There are a a
> lot of files that would be involved.
>
> - d/d-target.def: Define the hooks.
> - d/d-target.h: Data definitions, extern gcc_targetdm;
> - d/d-target-def.h: Default initializers (if
On 14 June 2017 at 00:41, Iain Buclaw wrote:
> On 13 June 2017 at 19:29, Joseph Myers wrote:
>> You have two new target macros TARGET_CPU_D_BUILTINS and
>> TARGET_OS_D_BUILTINS. You're missing any documentation for them in
>> tm.texi.in. And we
On Wed, 14 Jun 2017, Iain Buclaw wrote:
> > But will exgettext nevertheless extract messages from the dfrontend code,
> > if the functions happen to have string arguments in the same position as
> > the generic diagnostic functions do? If so, I think that should be
> > disabled, to avoid putting
On 13 June 2017 at 19:29, Joseph Myers wrote:
> As I read it, the front end has functions with names such as error, but no
> useful i18n will actually occur because the functions in d-diagnostic.cc
> format the messages with xvasprintf before passing to the common
>
As I read it, the front end has functions with names such as error, but no
useful i18n will actually occur because the functions in d-diagnostic.cc
format the messages with xvasprintf before passing to the common
diagnostic code.
But will exgettext nevertheless extract messages from the