Here's a small puzzle, in which there are both a simple and cryptic combined. To make it easier, I've added a some multiple choice answers at the bottom.

Winner of the simple puzzle gets a free beer from me at dconf.
Winner of the cryptic puzzle gets a free meal.


Q: What is the explanation for this error when building std.bigint?
---
$ aarch64-linux-gnu-gdc -o std/bigint.o -Wall -Werror -g -frelease -O2 -nostdinc -pipe -Wno-deprecated -c std/bigint.d

std/uni.d:2627:50: error: template std.algorithm.searching.countUntil cannot deduce function from argument types !("a[0] > 0x80")(CodepointInterval[]), candidates are:
std/algorithm/searching.d:684:11: note: std.algorithm.searching.countUntil(alias pred = "a == b", R, Rs...)(R haystack, Rs needles) if (isForwardRange!R && Rs.length > 0 && isForwardRange!(Rs[0]) == isInputRange!(Rs[0]) && is(typeof(startsWith!pred(haystack, needles[0]))) && (Rs.length == 1 || is(typeof(countUntil!pred(haystack, needles[1..__dollar])))))
std/algorithm/searching.d:772:11: note: std.algorithm.searching.countUntil(alias pred = "a == b", R, N)(R haystack, N needle) if (isInputRange!R && is(typeof(binaryFun!pred(haystack.front, needle)) : bool))
std/algorithm/searching.d:841:11: note: std.algorithm.searching.countUntil(alias pred, R)(R haystack) if (isInputRange!R && is(typeof(unaryFun!pred(haystack.front)) : bool))
std/uni.d:1853:29: error: template instance std.uni.InversionList!(GcPolicy) error instantiating
---

A:
---
[1]: Template deduction/matching failed to find a suitable candidate for countUntil.
[2]: The ptrdiff_t and size_t types have a different size.
[3]: An untested version path had a semantic error.
[4]: An untested template instantiation had a missing member.
[5]: The template function core.varargs.va_arg does not exist.
[6]: A static assert was triggered in std.math.
[7]: The std.format module does not support 128-bit reals.
[8]: The compiler didn't add a predefined version for little/big endian.
[9]: The order that modules are imported on AArch64 unearthed a bug in the semantic pass.
---


Iain.

I don't have an ARMv8 or emulator to test on, so I'll take a wild guess. Is the answer 1,2,3,4,5,6,7,8,9 ?

-- 
Marco

On Monday, 2 May 2016 at 13:17:13 UTC, Marco Leise wrote:
> I don't have an ARMv8 or emulator to test on, so I'll take a wild guess. Is the answer 1,2,3,4,5,6,7,8,9 ?

You are not far off from being totally utterly wrong. :-)

On Monday, 2 May 2016 at 07:13:17 UTC, Iain Buclaw wrote:
> Here's a small puzzle, in which there are both a simple and cryptic combined. To make it easier, I've added a some multiple choice answers at the bottom.
> [...]
> std/uni.d:2627:50: error: template std.algorithm.searching.countUntil cannot deduce function from argument types !("a[0] > 0x80")(CodepointInterval[]), candidates are:
> [...]
> [1]: Template deduction/matching failed to find a suitable candidate for countUntil.
> [...]

1

On 5/2/16 3:13 AM, Iain Buclaw wrote:
> Here's a small puzzle, in which there are both a simple and cryptic
> combined. To make it easier, I've added a some multiple choice answers
> at the bottom.
>
> Winner of the simple puzzle gets a free beer from me at dconf.
> Winner of the cryptic puzzle gets a free meal.
>
>
> Q: What is the explanation for this error when building std.bigint?
> ---
> $ aarch64-linux-gnu-gdc -o std/bigint.o -Wall -Werror -g -frelease -O2
> -nostdinc -pipe -Wno-deprecated -c std/bigint.d
>
> std/uni.d:2627:50: error: template std.algorithm.searching.countUntil
> cannot deduce function from argument types !("a[0] >
> 0x80")(CodepointInterval[]), candidates are:
> std/algorithm/searching.d:684:11: note:
> std.algorithm.searching.countUntil(alias pred = "a == b", R, Rs...)(R
> haystack, Rs needles) if (isForwardRange!R && Rs.length > 0 &&
> isForwardRange!(Rs[0]) == isInputRange!(Rs[0]) &&
> is(typeof(startsWith!pred(haystack, needles[0]))) && (Rs.length == 1 ||
> is(typeof(countUntil!pred(haystack, needles[1..__dollar])))))
> std/algorithm/searching.d:772:11: note:
> std.algorithm.searching.countUntil(alias pred = "a == b", R, N)(R
> haystack, N needle) if (isInputRange!R &&
> is(typeof(binaryFun!pred(haystack.front, needle)) : bool))
> std/algorithm/searching.d:841:11: note:
> std.algorithm.searching.countUntil(alias pred, R)(R haystack) if
> (isInputRange!R && is(typeof(unaryFun!pred(haystack.front)) : bool))
> std/uni.d:1853:29: error: template instance
> std.uni.InversionList!(GcPolicy) error instantiating
> ---
>
> A:
> ---
> [1]: Template deduction/matching failed to find a suitable candidate for
> countUntil.

This answer is trivially true. It even says so in the error message :)

What I assume you mean is that one *should* match but there is a bug in the matching mechanism? I'd say no -- this would be too easy an answer

> [2]: The ptrdiff_t and size_t types have a different size.

Wow, it would be a copy-paste error of some sort? An interesting possibility. But I'm going to say no, I don't see how this comes into play for the template constraints.

> [3]: An untested version path had a semantic error.

This is a possibility, but not very likely (in terms of errors that are prone to occur).

> [4]: An untested template instantiation had a missing member.

This has my vote. I've had this bite me many times...

> [5]: The template function core.varargs.va_arg does not exist.

haha!

> [6]: A static assert was triggered in std.math.

No, but again possible. If this is the problem, it comes down to the issues with is(typeof(some code)) that have been discussed lately.

> [7]: The std.format module does not support 128-bit reals.

I'd say no, because I don't see how it relates to the error messages.

> [8]: The compiler didn't add a predefined version for little/big endian.

ugh. How are we to guess at your environment? ;) I'd say no.

> [9]: The order that modules are imported on AArch64 unearthed a bug in
> the semantic pass.

Possible. Still going with 4.

-Steve

On Monday, 2 May 2016 at 16:24:40 UTC, Steven Schveighoffer wrote:
> On 5/2/16 3:13 AM, Iain Buclaw wrote:
>> [5]: The template function core.varargs.va_arg does not exist.
>
> haha!
>

You may laugh, but while almost all of these answers listed are complete fantasy, a few listed did finally surface after I found out and stubbed what was causing this exact error when building about a third of all modules in phobos.

Also. Yes it is very possible for druntime to compile and pass the unittester without you noticing a problem such as this, as only std.format uses the va_arg function that accepts a TypeInfo parameter. (and there are no unittests in core.varargs :-)

--
Iain

On Monday, 2 May 2016 at 16:24:40 UTC, Steven Schveighoffer wrote:
> On 5/2/16 3:13 AM, Iain Buclaw wrote:
>> [2]: The ptrdiff_t and size_t types have a different size.
>
> Wow, it would be a copy-paste error of some sort? An interesting possibility. But I'm going to say no, I don't see how this comes into play for the template constraints.
>

While there may be an alias in object.d, I'd say it's purpose is purely cosmetic (and to prevent missing symbol errors).  It is the compiler that decides what types size_t, ptrdiff_t have.  And while there are targets where word and pointer sizes are different, GDC does not honour this however, as the D specification on these types (and D_LP64) trumps that.

--
Iain

On 5/2/16 2:25 PM, Iain Buclaw wrote:
> On Monday, 2 May 2016 at 16:24:40 UTC, Steven Schveighoffer wrote:
>> On 5/2/16 3:13 AM, Iain Buclaw wrote:
>>> [2]: The ptrdiff_t and size_t types have a different size.
>>
>> Wow, it would be a copy-paste error of some sort? An interesting
>> possibility. But I'm going to say no, I don't see how this comes into
>> play for the template constraints.
>>
>
> While there may be an alias in object.d, I'd say it's purpose is purely
> cosmetic (and to prevent missing symbol errors).  It is the compiler
> that decides what types size_t, ptrdiff_t have.  And while there are
> targets where word and pointer sizes are different, GDC does not honour
> this however, as the D specification on these types (and D_LP64) trumps
> that.

So you are saying that:

int * p;
int[] arr;
assert(typeof(p - p).sizeof == typeof(arr.length).sizeof);

could fail regardless of how object.d defines size_t and ptrdiff_t? I can't imagine much would work. Interesting note though.

I've worked with processors that have different word and pointer sizes, but they were all too weak to be able to use D (if you used betterc switch maybe).

-Steve

On Monday, 2 May 2016 at 19:14:59 UTC, Steven Schveighoffer wrote:
> On 5/2/16 2:25 PM, Iain Buclaw wrote:
>> On Monday, 2 May 2016 at 16:24:40 UTC, Steven Schveighoffer wrote:
>>> On 5/2/16 3:13 AM, Iain Buclaw wrote:
>>>> [2]: The ptrdiff_t and size_t types have a different size.
>>>
>>> Wow, it would be a copy-paste error of some sort? An interesting
>>> possibility. But I'm going to say no, I don't see how this comes into
>>> play for the template constraints.
>>>
>>
>> While there may be an alias in object.d, I'd say it's purpose is purely
>> cosmetic (and to prevent missing symbol errors).  It is the compiler
>> that decides what types size_t, ptrdiff_t have.  And while there are
>> targets where word and pointer sizes are different, GDC does not honour
>> this however, as the D specification on these types (and D_LP64) trumps
>> that.
>
> So you are saying that:
>
> int * p;
> int[] arr;
> assert(typeof(p - p).sizeof == typeof(arr.length).sizeof);
>
> could fail regardless of how object.d defines size_t and ptrdiff_t? I can't imagine much would work. Interesting note though.
>
> I've worked with processors that have different word and pointer sizes, but they were all too weak to be able to use D (if you used betterc switch maybe).
>

Yes, although I'm not aware of LDC doing this.  I can say that GDC will always pick int/uint or long/ulong.  Maybe at some point I should allow short/ushort for 16bit targets.

--
Iain