[testsuite] Require ucn support in gdc.test/compilable/ddoc12.d (PR d/88039)

[Rainer Orth]

Hi Iain,

> On Tue, 27 Nov 2018 at 20:32, Rainer Orth <ro@cebitec.uni-bielefeld.de> wrote:
>>
>> Hi Mike,
>>
>> > On Nov 27, 2018, at 2:18 AM, Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
>> > wrote:
>> >>
>> >> Some assemblers, including the Solaris one, don't support UTF-8
>> >> identifiers, which breaks the gdc.test/compilable/ddoc12.d testcase as
>> >> reported in the PR.
>> >
>> > So, another style of fix, would be to change the binding from the language
>> > front-end to encode unsupported symbols using a fixed, documented, abi
>> > defined technique.
>>
>> there's been some discussion on this in the PR.  Joseph's suggestion was
>> to follow the system compilers if this were done, and indeed they do
>> encode UTF-8 identifiers in some way which could either be
>> reverse-engineered or a spec obtained.  However, given Iain's stance
>> towards UTF-8 identifiers in D, I very much doubt this is worth the
>> effort.  Ultimately, it's his call, of course.
>>
>
> Not only my stance, but as a whole just how those maintaining the core
> language generally agree on. Encoding UTF8 characters in symbols is
> not part of the D ABI, so that is something that needs convincing
> upstream.
>
> There is a third way however, all compilable/ddoc* tests don't
> actually require us to compile the module all the way down to object
> code, the only thing that really needs to be tested is the Ddoc
> generator itself.  Which would be setting 'dg-do-what compile' and
> build with the compiler option -fdoc, then dg-final checks for the
> presence of the file ddoc12.html is the minimum that needs to be done
> for these tests to be considered passed.
>
> I'll have a look into doing it that way tomorrow.

that would be even better of course, also saving some testing time.

Thanks.
	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University