Hi Iain, > On Tue, 27 Nov 2018 at 20:32, Rainer Orth <r...@cebitec.uni-bielefeld.de> > wrote: >> >> Hi Mike, >> >> > On Nov 27, 2018, at 2:18 AM, Rainer Orth <r...@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