digitalmars.D - My favourite game: DMD guess the error reason.
- Iain Buclaw (47/48) May 02 2016 Here's a small puzzle, in which there are both a simple and
- Marco Leise (4/4) May 02 2016 I don't have an ARMv8 or emulator to test on, so I'll take a
- Iain Buclaw (2/4) May 02 2016 You are not far off from being totally utterly wrong. :-)
- Lass Safin (2/14) May 02 2016 1
- Steven Schveighoffer (17/58) May 02 2016 This answer is trivially true. It even says so in the error message :)
- Iain Buclaw (11/14) May 02 2016 You may laugh, but while almost all of these answers listed are
- Iain Buclaw (9/14) May 02 2016 While there may be an alias in object.d, I'd say it's purpose is
- Steven Schveighoffer (11/25) May 02 2016 So you are saying that:
- Iain Buclaw (6/40) May 02 2016 Yes, although I'm not aware of LDC doing this. I can say that
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
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
Iain Buclaw <ibuclaw gdcproject.org> 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
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
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
On Monday, 2 May 2016 at 16:24:40 UTC, Steven Schveighoffer wrote:On 5/2/16 3:13 AM, Iain Buclaw wrote: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[5]: The template function core.varargs.va_arg does not exist.haha!
May 02 2016
On Monday, 2 May 2016 at 16:24:40 UTC, Steven Schveighoffer wrote:On 5/2/16 3:13 AM, Iain Buclaw wrote: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[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.
May 02 2016
On 5/2/16 2:25 PM, Iain Buclaw wrote:On Monday, 2 May 2016 at 16:24:40 UTC, Steven Schveighoffer wrote: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). -SteveOn 5/2/16 3:13 AM, Iain Buclaw wrote: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.[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.
May 02 2016
On Monday, 2 May 2016 at 19:14:59 UTC, Steven Schveighoffer wrote:On 5/2/16 2:25 PM, Iain Buclaw wrote: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. -- IainOn Monday, 2 May 2016 at 16:24:40 UTC, Steven Schveighoffer wrote: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).On 5/2/16 3:13 AM, Iain Buclaw wrote: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.[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.
May 02 2016