www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - My favourite game: DMD guess the error reason.

reply Iain Buclaw <ibuclaw gdcproject.org> writes:
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.
May 02 2016
next sibling parent reply Marco Leise <Marco.Leise gmx.de> writes:
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
May 02 2016
parent Iain Buclaw <ibuclaw gdcproject.org> writes:
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. :-)
May 02 2016
prev sibling next sibling parent Lass Safin <lasssafin gmail.com> writes:
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
May 02 2016
prev sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
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
May 02 2016
next sibling parent Iain Buclaw <ibuclaw gdcproject.org> writes:
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
May 02 2016
prev sibling parent reply Iain Buclaw <ibuclaw gdcproject.org> writes:
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
May 02 2016
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
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
May 02 2016
parent Iain Buclaw <ibuclaw gdcproject.org> writes:
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
May 02 2016