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. -- Iain
