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

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

[Rainer Orth]

[-- Attachment #1: Type: text/plain, Size: 868 bytes --]

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.

Since we don't want to modify the upstream testcase directly, I've
instead modified the gdc.test driver to require ucn support via a
dg-require-effective-target directive, based on the file name.

Tested on i386-pc-solaris2.11 with gas (which does support them and the
test still PASSes) and sparc-sun-solaris2.11 with as (which doesn't, so
the test turns out as UNSUPPORTED).

Ok for mainline?

	Rainer

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


2018-11-25  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>

	PR  d/88039
	* gdc.test/gdc-test.exp	(dmd2dg): Require ucn support for tests
	using UCNs in identifiers.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: testsuite-d-ddoc12-ucn.patch --]
[-- Type: text/x-patch, Size: 901 bytes --]

# HG changeset patch
# Parent  c94c294504322187c207bc70ad6734280adc7043
Require ucn support in gdc.test/compilable/ddoc12.d (PR d/88039)

diff --git a/gcc/testsuite/gdc.test/gdc-test.exp b/gcc/testsuite/gdc.test/gdc-test.exp
--- a/gcc/testsuite/gdc.test/gdc-test.exp
+++ b/gcc/testsuite/gdc.test/gdc-test.exp
@@ -276,6 +276,14 @@ proc dmd2dg { base test } {
     # Since GCC 6-20160131 blank lines are not allowed in the output by default.
     dg-allow-blank-lines-in-output { 1 }
 
+    # Require UCN support for tests with UCN identifiers.
+    switch $test {
+	compilable/ddoc12.d {
+	    set out_line "// { dg-require-effective-target ucn }"
+	    puts $fdout $out_line
+	}
+    }
+
     # Compilable files are successful if an output is generated.
     # Fail compilable are successful if an output is not generated.
     # Runnable must compile, link, and return 0 to be successful by default.

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

[Mike Stump]

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.

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

[Rainer Orth]

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.

	Rainer

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

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

[Iain Buclaw]

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.

--
Iain

Re: [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

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

[Iain Buclaw]

[-- Attachment #1: Type: text/plain, Size: 2240 bytes --]

On Thu, 29 Nov 2018 at 15:12, Rainer Orth <ro@cebitec.uni-bielefeld.de> wrote:
>
> 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.
>

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.

-- 
Iain

---

[-- Attachment #2: ddoc.patch --]
[-- Type: text/x-patch, Size: 8853 bytes --]

diff --git a/gcc/d/dmd/doc.c b/gcc/d/dmd/doc.c
index d35ca7b2522..797991ee2c4 100644
--- a/gcc/d/dmd/doc.c
+++ b/gcc/d/dmd/doc.c
@@ -133,6 +133,25 @@ bool isCVariadicParameter(Dsymbols *a, const utf8_t *p, size_t len)
     return false;
 }
 
+/****************************************************
+ */
+static Parameter *isFunctionParameter(Dsymbol *s, const utf8_t *p, size_t len)
+{
+    TypeFunction *tf = isTypeFunction(s);
+    if (tf && tf->parameters)
+    {
+        for (size_t k = 0; k < tf->parameters->dim; k++)
+        {
+            Parameter *fparam = (*tf->parameters)[k];
+            if (fparam->ident && cmp(fparam->ident->toChars(), p, len) == 0)
+            {
+                return fparam;
+            }
+        }
+    }
+    return NULL;
+}
+
 static Dsymbol *getEponymousMember(TemplateDeclaration *td)
 {
     if (!td->onemember)
@@ -150,6 +169,54 @@ static Dsymbol *getEponymousMember(TemplateDeclaration *td)
     return NULL;
 }
 
+/****************************************************
+ */
+static Parameter *isEponymousFunctionParameter(Dsymbols *a, const utf8_t *p, size_t len)
+{
+    for (size_t i = 0; i < a->dim; i++)
+    {
+        TemplateDeclaration *td = (*a)[i]->isTemplateDeclaration();
+        if (td && td->onemember)
+        {
+            /* Case 1: we refer to a template declaration inside the template
+
+               /// ...ddoc...
+               template case1(T) {
+                 void case1(R)() {}
+               }
+             */
+            td = td->onemember->isTemplateDeclaration();
+        }
+        if (!td)
+        {
+            /* Case 2: we're an alias to a template declaration
+
+               /// ...ddoc...
+               alias case2 = case1!int;
+             */
+            AliasDeclaration *ad = (*a)[i]->isAliasDeclaration();
+            if (ad && ad->aliassym)
+            {
+                td = ad->aliassym->isTemplateDeclaration();
+            }
+        }
+        while (td)
+        {
+            Dsymbol *sym = getEponymousMember(td);
+            if (sym)
+            {
+                Parameter *fparam = isFunctionParameter(sym, p, len);
+                if (fparam)
+                {
+                    return fparam;
+                }
+            }
+            td = td->overnext;
+        }
+    }
+    return NULL;
+}
+
 static TemplateDeclaration *getEponymousParent(Dsymbol *s)
 {
     if (!s->parent)
@@ -1590,6 +1657,12 @@ void ParamSection::write(Loc loc, DocComment *, Scope *sc, Dsymbols *a, OutBuffe
                 {
                     size_t o = buf->offset;
                     Parameter *fparam = isFunctionParameter(a, namestart, namelen);
+                    if (!fparam)
+                    {
+                        // Comments on a template might refer to function parameters within.
+                        // Search the parameters of nested eponymous functions (with the same name.)
+                        fparam = isEponymousFunctionParameter(a, namestart, namelen);
+                    }
                     bool isCVariadic = isCVariadicParameter(a, namestart, namelen);
                     if (isCVariadic)
                     {
@@ -2085,17 +2158,10 @@ Parameter *isFunctionParameter(Dsymbols *a, const utf8_t *p, size_t len)
 {
     for (size_t i = 0; i < a->dim; i++)
     {
-        TypeFunction *tf = isTypeFunction((*a)[i]);
-        if (tf && tf->parameters)
+        Parameter *fparam = isFunctionParameter((*a)[i], p, len);
+        if (fparam)
         {
-            for (size_t k = 0; k < tf->parameters->dim; k++)
-            {
-                Parameter *fparam = (*tf->parameters)[k];
-                if (fparam->ident && cmp(fparam->ident->toChars(), p, len) == 0)
-                {
-                    return fparam;
-                }
-            }
+            return fparam;
         }
     }
     return NULL;
@@ -2108,7 +2174,10 @@ TemplateParameter *isTemplateParameter(Dsymbols *a, const utf8_t *p, size_t len)
 {
     for (size_t i = 0; i < a->dim; i++)
     {
-        TemplateDeclaration *td = getEponymousParent((*a)[i]);
+        TemplateDeclaration *td = (*a)[i]->isTemplateDeclaration();
+        // Check for the parent, if the current symbol is not a template declaration.
+        if (!td)
+            td = getEponymousParent((*a)[i]);
         if (td && td->origParameters)
         {
             for (size_t k = 0; k < td->origParameters->dim; k++)
diff --git a/gcc/testsuite/gdc.test/compilable/ddoc10236.d b/gcc/testsuite/gdc.test/compilable/ddoc10236.d
index 25738ec34e3..1c547613c44 100644
--- a/gcc/testsuite/gdc.test/compilable/ddoc10236.d
+++ b/gcc/testsuite/gdc.test/compilable/ddoc10236.d
@@ -1,5 +1,5 @@
 // PERMUTE_ARGS:
-// REQUIRED_ARGS: -D -Dd${RESULTS_DIR}/compilable -w -o-
+// REQUIRED_ARGS: -D -Dd${RESULTS_DIR}/compilable -wi -o-
 
 /*
 TEST_OUTPUT:
diff --git a/gcc/testsuite/gdc.test/compilable/ddoc10236b.d b/gcc/testsuite/gdc.test/compilable/ddoc10236b.d
index d814d375c06..065ced0936c 100644
--- a/gcc/testsuite/gdc.test/compilable/ddoc10236b.d
+++ b/gcc/testsuite/gdc.test/compilable/ddoc10236b.d
@@ -1,5 +1,5 @@
 // PERMUTE_ARGS:
-// REQUIRED_ARGS: -D -Dd${RESULTS_DIR}/compilable -w -o-
+// REQUIRED_ARGS: -D -Dd${RESULTS_DIR}/compilable -wi -o-
 
 /*
 TEST_OUTPUT:
diff --git a/gcc/testsuite/gdc.test/compilable/ddoc13502.d b/gcc/testsuite/gdc.test/compilable/ddoc13502.d
index 6ab2ca0614d..93f383fea9f 100644
--- a/gcc/testsuite/gdc.test/compilable/ddoc13502.d
+++ b/gcc/testsuite/gdc.test/compilable/ddoc13502.d
@@ -1,5 +1,5 @@
 // PERMUTE_ARGS:
-// REQUIRED_ARGS: -D -Dd${RESULTS_DIR}/compilable -w -o-
+// REQUIRED_ARGS: -D -Dd${RESULTS_DIR}/compilable -wi -o-
 /*
 TEST_OUTPUT:
 ---
diff --git a/gcc/testsuite/gdc.test/compilable/ddoc4899.d b/gcc/testsuite/gdc.test/compilable/ddoc4899.d
index 1fbd6a9cbe8..b5cfa86367c 100644
--- a/gcc/testsuite/gdc.test/compilable/ddoc4899.d
+++ b/gcc/testsuite/gdc.test/compilable/ddoc4899.d
@@ -1,5 +1,5 @@
 // PERMUTE_ARGS:
-// REQUIRED_ARGS: -D -Dd${RESULTS_DIR}/compilable -w -o-
+// REQUIRED_ARGS: -D -Dd${RESULTS_DIR}/compilable -wi -o-
 
 /*
 TEST_OUTPUT:
diff --git a/gcc/testsuite/gdc.test/gdc-test.exp b/gcc/testsuite/gdc.test/gdc-test.exp
index 246ac850a20..7dd97d393ea 100644
--- a/gcc/testsuite/gdc.test/gdc-test.exp
+++ b/gcc/testsuite/gdc.test/gdc-test.exp
@@ -27,7 +27,10 @@ proc gdc-convert-args { args } {
 
     foreach arg [split [lindex $args 0] " "] {
         # List of switches kept in ASCII collated order.
-        if { [regexp -- {^-I([\w+/-]+)} $arg pattern path] } {
+        if [string match "-D" $arg] {
+            lappend out "-fdoc"
+
+        } elseif { [regexp -- {^-I([\w+/-]+)} $arg pattern path] } {
             lappend out "-I$path"
 
         } elseif { [regexp -- {^-J([\w+/-]+)} $arg pattern path] } {
@@ -183,6 +186,7 @@ proc dmd2dg { base test } {
 
     # Split base, folder/file.
     set type [file dirname $test]
+    set name [file tail $test]
 
     # print "Filename: $base - $test"
 
@@ -279,7 +283,7 @@ proc dmd2dg { base test } {
     # Compilable files are successful if an output is generated.
     # Fail compilable are successful if an output is not generated.
     # Runnable must compile, link, and return 0 to be successful by default.
-    switch [file dirname $test] {
+    switch $type {
         runnable {
             if ![isnative] {
                 set out_line "// { dg-final { output-exists } }"
@@ -290,6 +294,16 @@ proc dmd2dg { base test } {
         compilable {
             set out_line "// { dg-final { output-exists } }"
             puts $fdout $out_line
+
+            # Check that Ddoc tests also generate a html file.
+            if [regexp -- "ddoc.*" $name] {
+                set ddocfile "[file rootname $name].html"
+                set out_line "// { dg-final { scan-file $ddocfile \"Generated by Ddoc from $test\" } }"
+                puts $fdout $out_line
+                # Cleanup extra generated files.
+                set out_line "// { dg-final { file delete $ddocfile } }"
+                puts $fdout $out_line
+            }
         }
 
         fail_compilation {
@@ -389,8 +403,12 @@ proc gdc-do-test { } {
             compilable {
                 for { set i 0 } { $i<[llength $options] } { incr i } {
                     set flags [lindex $options $i]
-                    #set dg-do-what-default "compile"
-                    set dg-do-what-default "assemble"
+                    # Compilable test may require checking another kind of output file.
+                    if [regexp -- "ddoc.*" $name] {
+                        set dg-do-what-default "compile"
+                    } else {
+                        set dg-do-what-default "assemble"
+                    }
                     gdc-dg-runtest $filename $flags $imports
                 }
             }

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

[Iain Buclaw]

On Sat, 1 Dec 2018 at 19:28, Iain Buclaw <ibuclaw@gdcproject.org> wrote:
>
> On Thu, 29 Nov 2018 at 15:12, Rainer Orth <ro@cebitec.uni-bielefeld.de> wrote:
> >
> > 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.
> >
>
> 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.

-- 
Iain

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

[Rainer Orth]

Hi Iain,

> On Sat, 1 Dec 2018 at 19:28, Iain Buclaw <ibuclaw@gdcproject.org> wrote:
>>
>> On Thu, 29 Nov 2018 at 15:12, Rainer Orth <ro@cebitec.uni-bielefeld.de> wrote:
>> >
>> > 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.
>> >
>>
>> 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.

Thanks.
        Rainer

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

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

[Iain Buclaw]

On Tue, 4 Dec 2018 at 14:49, Rainer Orth <ro@cebitec.uni-bielefeld.de> wrote:
>
> Hi Iain,
>
> > On Sat, 1 Dec 2018 at 19:28, Iain Buclaw <ibuclaw@gdcproject.org> wrote:
> >>
> >> On Thu, 29 Nov 2018 at 15:12, Rainer Orth <ro@cebitec.uni-bielefeld.de> wrote:
> >> >
> >> > 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.
> >> >
> >>
> >> 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