On Tue, 4 Dec 2018 at 14:49, Rainer Orth <r...@cebitec.uni-bielefeld.de> wrote: > > Hi Iain, > > > On Sat, 1 Dec 2018 at 19:28, Iain Buclaw <ibuc...@gdcproject.org> wrote: > >> > >> On Thu, 29 Nov 2018 at 15:12, Rainer Orth <r...@cebitec.uni-bielefeld.de> > >> wrote: > >> > > >> > 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. > >> > > >> > >> Hi Rainer, > >> > >> Attached patch for it, I've checked that and it does the right thing > >> and passes on x86_64. > >> > >> There's a couple more changes than just testsuite files, as compiling > >> with -fdoc unearthed bug fixes not backported from the D version of > >> the compiler. These I'll apply separately. > >> > > > > D2 front-end and testsuite changes have been upstreamed/downstreamed. > > If there's no complaint, I'll apply the dejagnu fix as well. > > not at all: I've checked it on i386-pc-solaris2.11/gas and > sparc-sun-solaris2.12/as and compilable/ddoc12.d now PASSes on both, so > the gdc-test.exp part is ok. Please mention PR d/88039 in the > ChangeLog. >
Done, and committed in r266933. -- Iain
