Compiler bug ? -preview=intpromote and Integral promotion rules not being followed for unary + - ~ operators

I have a container which provides access to data via a handle. For book keeping I calculate some bitmasks. Previously, when the handle type as well as the constants were uint, everything compiled fine. Today I added a template parameter to be able to specify the handle type and I ran into this

Re: Difference in compiletime vs compiletime or compiler bug?

On Friday, 27 December 2019 at 18:51:31 UTC, Adam D. Ruppe wrote: On Friday, 27 December 2019 at 18:49:32 UTC, Sjoerd Nijboer wrote: Should concatenating the list and mixing that in work too? yeah that'd work too. As long as all the overloads are coming from the same source, D allows it.

Re: Difference in compiletime vs compiletime or compiler bug?

On Friday, 27 December 2019 at 18:49:32 UTC, Sjoerd Nijboer wrote: Should concatenating the list and mixing that in work too? yeah that'd work too. As long as all the overloads are coming from the same source, D allows it. but if you add something manually in the struct then you have two

Re: Difference in compiletime vs compiletime or compiler bug?

On Friday, 27 December 2019 at 18:34:49 UTC, Adam D. Ruppe wrote: On Friday, 27 December 2019 at 18:22:10 UTC, Sjoerd Nijboer wrote: When calling the mixin directly instead of through the template mixin it breaks with thesame error message. What exactly did you do here? I meant to say that

Re: Difference in compiletime vs compiletime or compiler bug?

); } } works for me... I don't know if this an actual compiler bug or if this is me not properly understanding D. This is a case of the function hijacking rules biting you: https://dlang.org/articles/hijack.html template mixins take things in two different scopes: mix!one_string mix

Difference in compiletime vs compiletime or compiler bug?

e mixin it breaks with thesame error message. I don't know if this an actual compiler bug or if this is me not properly understanding D. I'm using DMD64 D Compiler v2.089.1 Any help is appreciated.

Re: needing to change the order of things at module level = compiler bug, right?

On Thursday, 12 December 2019 at 06:23:31 UTC, Basile B. wrote: Still worth opening an issue. https://issues.dlang.org/show_bug.cgi?id=20443 Thanks, Basile. I've added additional information from the github thread where the sumtype author helpfully looked into the problem.

Re: needing to change the order of things at module level = compiler bug, right?

On Sunday, 8 December 2019 at 18:13:59 UTC, DanielG wrote: On Sunday, 8 December 2019 at 18:01:03 UTC, Steven Schveighoffer wrote: Yes, if it can compile when you move things around, and the result is *correct* (very important characteristic) Indeed, everything's working as intended when

Re: needing to change the order of things at module level = compiler bug, right?

On Sunday, 8 December 2019 at 18:01:03 UTC, Steven Schveighoffer wrote: Yes, if it can compile when you move things around, and the result is *correct* (very important characteristic) Indeed, everything's working as intended when rearranged. Thanks!

Re: needing to change the order of things at module level = compiler bug, right?

On 12/8/19 11:43 AM, DanielG wrote: I dustmite'd down my problem code, and it seems just changing the order of declarations makes the error go away. Specifically, moving a class declaration from the bottom of the file, to the top, allows it to compile. I also commented on two other things that

needing to change the order of things at module level = compiler bug, right?

I dustmite'd down my problem code, and it seems just changing the order of declarations makes the error go away. Specifically, moving a class declaration from the bottom of the file, to the top, allows it to compile. I also commented on two other things that can be changed to make it work -

static if, compiler bug?

port off_t not found I cannot explain this error, because off_t is defined in both cases of the static if. Even if I change it to: static if ( true ) alias long off_t; I get the same error. Is this a compiler bug? Kind regards André

Re: Compiler bug?

and some doc: http://dlang.org/spec/function.html#function-inheritance On Wed, Aug 16, 2017 at 7:45 AM, Daniel Kozak wrote: > No it is not a bug, there is no s() in B, you can fix this by adding: > > alias s = A.s; > > to class B > > On Wed, Aug 16, 2017 at 7:21 AM, apz28 via

Re: Compiler bug?

No it is not a bug, there is no s() in B, you can fix this by adding: alias s = A.s; to class B On Wed, Aug 16, 2017 at 7:21 AM, apz28 via Digitalmars-d-learn < digitalmars-d-learn@puremagic.com> wrote: > abstract class A > { > string _s; > > @property: > final string s() >

Compiler bug?

abstract class A { string _s; @property: final string s() { return _s; } A s(string x) { _s = x; return this; } } class B : A { @property: final override A s(string

Re: Weird template error in Phobos (after editing) that I can't quite get. Compiler bug?

On Wednesday, 22 March 2017 at 14:06:56 UTC, Atila Neves wrote: isInputRange looks like this: template isInputRange(R) { enum bool isInputRange = is(typeof( (inout int = 0) { R r = R.init; // can define a range object if (r.empty) {} // can test for empty

Weird template error in Phobos (after editing) that I can't quite get. Compiler bug?

isInputRange looks like this: template isInputRange(R) { enum bool isInputRange = is(typeof( (inout int = 0) { R r = R.init; // can define a range object if (r.empty) {} // can test for empty r.popFront; // can invoke popFront() auto h =

Re: Implementing SmartPtr - compiler bug?

On Monday, 27 October 2014 at 18:42:11 UTC, Marc Schütz wrote: On Monday, 27 October 2014 at 16:58:56 UTC, Szymon Gatner wrote: On Monday, 27 October 2014 at 14:04:53 UTC, Marc Schütz wrote: On Monday, 27 October 2014 at 12:40:17 UTC, Shachar Shemesh wrote: On 27/10/14 11:31, Szymon Gatner

Re: Implementing SmartPtr - compiler bug?

On Tuesday, 28 October 2014 at 08:36:07 UTC, Szymon Gatner wrote: On Monday, 27 October 2014 at 18:42:11 UTC, Marc Schütz wrote: On Monday, 27 October 2014 at 16:58:56 UTC, Szymon Gatner wrote: On Monday, 27 October 2014 at 14:04:53 UTC, Marc Schütz wrote: On Monday, 27 October 2014 at

Implementing SmartPtr - compiler bug?

understanding, array = array.init should always be equivalent to array[] = typeof(array[0]).init for static arrays. Am I missing something? Is this a compiler bug? Thanks, Shachar

Re: Implementing SmartPtr - compiler bug?

that this is definitely compiler bug. if dmd insists on postbliting, it should at least call destructors for all array elements, not only for the first one four times. ;-) signature.asc Description: PGP signature

Re: Implementing SmartPtr - compiler bug?

!Foo.init makes the second assert pass. To the best of my understanding, array = array.init should always be equivalent to array[] = typeof(array[0]).init for static arrays. Am I missing something? Is this a compiler bug? Thanks, Shachar You have created dynamic array of SmartPtrs

Re: Implementing SmartPtr - compiler bug?

On Mon, 27 Oct 2014 09:11:33 + Szymon Gatner via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: You have created dynamic array of SmartPtrs. nope. it's stack-allocated array. signature.asc Description: PGP signature

Re: Implementing SmartPtr - compiler bug?

On Monday, 27 October 2014 at 09:21:14 UTC, ketmar via Digitalmars-d-learn wrote: On Mon, 27 Oct 2014 09:11:33 + Szymon Gatner via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: You have created dynamic array of SmartPtrs. nope. it's stack-allocated array. Right, sorry.

Re: Implementing SmartPtr - compiler bug?

On 27/10/14 11:31, Szymon Gatner wrote: Right, sorry. Tho I admit I made assumptions since that was not the full code. I've opened a bug. It has a fully contained sample (that does not, in fact, implement smartptr). https://issues.dlang.org/show_bug.cgi?id=13661

Re: Implementing SmartPtr - compiler bug?

On Monday, 27 October 2014 at 12:40:17 UTC, Shachar Shemesh wrote: On 27/10/14 11:31, Szymon Gatner wrote: Right, sorry. Tho I admit I made assumptions since that was not the full code. I've opened a bug. It has a fully contained sample (that does not, in fact, implement smartptr).

Re: Implementing SmartPtr - compiler bug?

On Monday, 27 October 2014 at 14:04:53 UTC, Marc Schütz wrote: On Monday, 27 October 2014 at 12:40:17 UTC, Shachar Shemesh wrote: On 27/10/14 11:31, Szymon Gatner wrote: Right, sorry. Tho I admit I made assumptions since that was not the full code. I've opened a bug. It has a fully

Re: Implementing SmartPtr - compiler bug?

On Monday, 27 October 2014 at 16:58:56 UTC, Szymon Gatner wrote: On Monday, 27 October 2014 at 14:04:53 UTC, Marc Schütz wrote: On Monday, 27 October 2014 at 12:40:17 UTC, Shachar Shemesh wrote: On 27/10/14 11:31, Szymon Gatner wrote: Right, sorry. Tho I admit I made assumptions since that

Re: templates, enums, CT reflection: compiler bug or not?

no one any ideas? well, i filed two bug reports for now: https://d.puremagic.com/issues/show_bug.cgi?id=12532 https://d.puremagic.com/issues/show_bug.cgi?id=12533

templates, enums, CT reflection: compiler bug or not?

. so am i being stupid or is it a compiler bug? cheers, det ===CODE=== module demo; template valid(string mem){ pragma(msg, instantiation of valid with: ~mem); static if( !__traits( compiles, mixin(mem) ) ){ enum valid = false; }else{ enum valid = true

Compiler bug ?

Hello guys! It seems that it is bug. And critical for me. http://dpaste.1azy.net/b93f5776 Regards.

Re: Compiler bug ?

On Sunday, 9 June 2013 at 13:37:45 UTC, Temtaime wrote: Hello guys! It seems that it is bug. And critical for me. http://dpaste.1azy.net/b93f5776 Regards. The code should be rejected. It's a compiler bug. But, you can do what you want as follows. import std.stdio, std.typetuple; struct

Re: Compiler bug ?

Oh, i see. Great thanks!

Re: Compiler bug ?

Yes, it's strange. Using alias doesn't lead to this.

Compiler bug? regression for the template function call syntax

Hi all, Not sure if this is a bug so thought I'd post here. It is very common to use a function template without the call () expecting that it will be called. However with the latest compilers hibernated only compiles when one leaves out the -property dmd command line option. The call:

Re: Compiler bug? regression for the template function call syntax

On 05/31/2013 07:32 AM, rmc wrote: It is very common to use a function template without the call () expecting that it will be called. Non-templated functions too. However with the latest compilers hibernated only compiles when one leaves out the -property dmd command line option. I think

Re: Compiler bug? regression for the template function call syntax

On Friday, May 31, 2013 08:27:19 Ali Çehreli wrote: I think it is the same issue with non-templated functions. The best thing to do is to forget about the -property switch. I did about a year ago and never looked back. :) Given the most recent discussions on @property, I think that it's a

Re: Is this a compiler bug, or a breaking fix/enhancement?

On Wednesday, 29 May 2013 at 04:44:16 UTC, estew wrote: Hi All, I updated to dmd 2.063 today and all has been going smoothly until I decided to try out msgpack.d. I got an error compiling the msgpack.d unittest, so out of interest I decided to check this using dmd2.062 and it compiled and

Re: Is this a compiler bug, or a breaking fix/enhancement?

This is a compiler regression in 2.063 release. http://d.puremagic.com/issues/show_bug.cgi?id=10197 Kenji Hara Thanks for looking into it. Stewart

Is this a compiler bug, or a breaking fix/enhancement?

Hi All, I updated to dmd 2.063 today and all has been going smoothly until I decided to try out msgpack.d. I got an error compiling the msgpack.d unittest, so out of interest I decided to check this using dmd2.062 and it compiled and ran fine. I admit I don't really understand whether the

Re: Is this a compiler bug, or a breaking fix/enhancement?

Here's a link to the msgpack.d source: https://github.com/msgpack/msgpack-d/blob/master/src/msgpack.d And the error is on line 3211, not 3215 as mentioned in the previous post. Thanks, Stewart

Re: Compiler bug ?

On 05/17/2013 07:19 PM, bearophile wrote: Jonathan M Davis: However, if it _never_ makes sense to declare a variable beginning with two underscores, I don't know why the compiler wouldn't forbid it other than the fact that it probably inserts such variables prior to when it would do the

Re: Compiler bug ?

Timon Gehr: It is trivial to catch them in the parser. So the question is: is it right to catch them all? :-) Bye, bearophile

Re: Compiler bug ?

On 05/18/2013 11:50 AM, bearophile wrote: Timon Gehr: It is trivial to catch them in the parser. So the question is: is it right to catch them all? :-) I don't think so. Double underscores are reserved for the implementation, which includes the standard library. I don't think the compiler

Compiler bug ?

struct A { int opBinary(string op)(A) { k++; return 0; } } struct B { A __a; alias __a this; } void main() { B b; auto c = b * b; } This code doesn't compiles with an error: Error: 'b' is not of arithmetic type, it is a B If i remove k++, then it's OK. It

Re: Compiler bug ?

I don't see where k comes from? And it's always a bad idea to prefix a variable with '__', because this is reserved to the compiler.

Re: Compiler bug ?

On Friday, 17 May 2013 at 14:12:10 UTC, Namespace wrote: I don't see where k comes from? I think the point is that it comes from nowhere. Compiler incorectly omits two errors from output: Error undefined indentifier and template instance error instantiation. This should go to bugzilla.

Re: Compiler bug ?

Yes, i want to see 'undeclared variable' error, but the compiler omits function declaration instead. And why i shouldn't use __? I think it's ordinary identifier.

Re: Compiler bug ?

Temtaime: This code doesn't compiles with an error: Error: 'b' is not of arithmetic type, it is a B If i remove k++, then it's OK. It seems that compiler omitting the function if there an error in it. It's a bad error message, but it's correct, because k doesn't exists. This error message

Re: Compiler bug ?

Maxim Fomin: If it alwalys a bad idea, compiler should not accept such code. Ideally you are right. But I think sometimes you want to use those reserved names... So I don't know. Bye, bearophile

Re: Compiler bug ?

On Friday, 17 May 2013 at 14:35:35 UTC, Maxim Fomin wrote: On Friday, 17 May 2013 at 14:12:10 UTC, Namespace wrote: I don't see where k comes from? I think the point is that it comes from nowhere. Compiler incorectly omits two errors from output: Error undefined indentifier and template

Re: Compiler bug ?

On 05/17/2013 07:40 AM, Temtaime wrote: Yes, i want to see 'undeclared variable' error, but the compiler omits function declaration instead. And why i shouldn't use __? I think it's ordinary identifier. Iden­ti­fiers start­ing with __ (two un­der­scores) are re­served.

Re: Compiler bug ?

On 05/17/2013 09:35 AM, Maxim Fomin wrote: On Friday, 17 May 2013 at 14:12:10 UTC, Namespace wrote: I don't see where k comes from? I think the point is that it comes from nowhere. Compiler incorectly omits two errors from output: Error undefined indentifier and template instance error

Re: Compiler bug ?

On Friday, May 17, 2013 16:40:23 Temtaime wrote: Yes, i want to see 'undeclared variable' error, but the compiler omits function declaration instead. And why i shouldn't use __? I think it's ordinary identifier. Identifiers begining with two underscores are reserved by the compiler, which

Re: Compiler bug ?

On Friday, May 17, 2013 11:59:38 1100110 wrote: On 05/17/2013 09:35 AM, Maxim Fomin wrote: If it alwalys a bad idea, compiler should not accept such code. It is not the D way to forbid you from shooting yourself in the foot. goto, catch(Throwable th), there are plenty more examples. D

Re: Compiler bug ?

Jonathan M Davis: However, if it _never_ makes sense to declare a variable beginning with two underscores, I don't know why the compiler wouldn't forbid it other than the fact that it probably inserts such variables prior to when it would do the semantic analysis to check whether variables

Re: Compiler bug ?

On Friday, May 17, 2013 19:19:46 bearophile wrote: I think to answer this issue we need someone that knows more about the DMD compiler (as Kenji Hara). I think that if we want to forbid those variables in user code, then probably there is a way do to it. Oh, I'm sure that it would be

Re: Compiler bug ?

On Friday, 17 May 2013 at 17:08:31 UTC, Jonathan M Davis wrote: On Friday, May 17, 2013 11:59:38 1100110 wrote: On 05/17/2013 09:35 AM, Maxim Fomin wrote: If it alwalys a bad idea, compiler should not accept such code. It is not the D way to forbid you from shooting yourself in the foot.

Re: Compiler bug ?

On 05/17/2013 12:27 PM, Jonathan M Davis wrote: On Friday, May 17, 2013 19:19:46 bearophile wrote: I think to answer this issue we need someone that knows more about the DMD compiler (as Kenji Hara). I think that if we want to forbid those variables in user code, then probably there is a way

Re: Compiler bug ?

On Friday, 17 May 2013 at 14:35:35 UTC, Maxim Fomin wrote: If it alwalys a bad idea, compiler should not accept such code. I'm pretty sure the answer is: Compilers can have different extensions, it would be bad for a compiler to reject code which is valid by another compiler. That said, I

ref return function using foreach ref result segfaults. Compiler bug?

Hard to describe this problem, see code and read comments below. class A { private int _v; this( int a_v ) { _v = a_v; } @property size_t length() { return 1; } int opApply( int delegate( ref int a_v ) a_dg ) { int result = 0; for (

Re: ref return function using foreach ref result segfaults. Compiler bug?

On Tuesday, 13 November 2012 at 08:50:16 UTC, Rob T wrote: Hard to describe this problem, see code and read comments below. class A { private int _v; this( int a_v ) { _v = a_v; } @property size_t length() { return 1; } int opApply( int delegate(

Re: ref return function using foreach ref result segfaults. Compiler bug?

On Tuesday, 13 November 2012 at 12:31:26 UTC, Kenji Hara wrote: This issue looks like bug8093. http://d.puremagic.com/issues/show_bug.cgi?id=8093 And the code works correctly in git head (dmd2.061alpha). Therefore, I think that the bug is fixed very recently. Kenji Hara Thanks for the

Re: floating-WTF - Compiler-BUG with 64bit

On Sunday, January 29, 2012 08:43:54 sclytrack wrote: Prior to filing the bug I tried to compile dmd from source. I have now succeeded. The only problem I had was a missing symbolic link libstdc++.so and this in Ubuntu 11.10. So I just created it. /usr/lib32/libstdc++.so -

Re: floating-WTF - Compiler-BUG with 64bit

On 01/25/2012 01:12 AM, Timon Gehr wrote: On 01/24/2012 10:28 PM, %u wrote: Shouldn't this go into 'digitalmars.D' ? It should go straight to the bug tracker. Issue 7391 - floating wtf dmd 2.057 64

Re: floating-WTF - Compiler-BUG with 64bit

On 01/28/2012 04:56 PM, sclytrack wrote: On 01/25/2012 01:12 AM, Timon Gehr wrote: On 01/24/2012 10:28 PM, %u wrote: Shouldn't this go into 'digitalmars.D' ? It should go straight to the bug tracker. Issue 7391 - floating wtf dmd 2.057 64 Thanks!

Re: floating-WTF - Compiler-BUG with 64bit

I've already reported, and it's been fixed in the latest: http://d.puremagic.com/issues/show_bug.cgi?id=7376 On Sat, Jan 28, 2012 at 9:56 AM, sclytrack sclytr...@fake.com wrote: On 01/25/2012 01:12 AM, Timon Gehr wrote: On 01/24/2012 10:28 PM, %u wrote: Shouldn't this go into

Re: floating-WTF - Compiler-BUG with 64bit

On Sat, Jan 28, 2012 at 2:04 PM, sclytrack sclytr...@hotmail.com wrote: Now I've waisted Walter's precious time. I feel so sad now :-( I should have made a post about the fact that I had already bug reported it, but I forgot. Sorry.

Re: floating-WTF - Compiler-BUG with 64bit

Prior to filing the bug I tried to compile dmd from source. I have now succeeded. The only problem I had was a missing symbolic link libstdc++.so and this in Ubuntu 11.10. So I just created it. /usr/lib32/libstdc++.so - /usr/lib/i386-linux-gnu/libstdc++.so.6 Then make -f posix and in the

Re: floating-WTF - Compiler-BUG with 64bit

Am 24.01.2012 18:49, schrieb sclytrack: dmd 2.057 give this result under windows/32bit calculate1: 1.5 1.5 calculate2: 1.5 1.5 calculate3: 1.5 1.5 so its seems to be an x64 compiler bug Yes, I missed my lessons in clear communication

Re: floating-WTF - Compiler-BUG with 64bit

How did you compile it? As in my original post, it matters how you compile it. In this case (I'm on a 64-bit GNU/Linux system), compiling with '-inline' doesn't trigger the bug.

Re: floating-WTF - Compiler-BUG with 64bit

Am 24.01.2012 19:13, schrieb Caligo: How did you compile it? As in my original post, it matters how you compile it. In this case (I'm on a 64-bit GNU/Linux system), compiling with '-inline' doesn't trigger the bug. im on win7 (64bit) - but the windows dmd2.057 isn't able to produce x64 code

Re: floating-WTF - Compiler-BUG with 64bit

Shouldn't this go into 'digitalmars.D' ?

Re: floating-WTF - Compiler-BUG with 64bit

On 01/24/2012 10:28 PM, %u wrote: Shouldn't this go into 'digitalmars.D' ? It should go straight to the bug tracker.

Compiler bug? Functions as Array Properties doesn't work with nested functions

The spec doesn't mention anything about nested functions here. This works void foo(int[] a, int x) { }; void main() { int[] array; foo(array, 3); array.foo(3); } But this gives undefined identifier module t.foo void main() { void foo(int[] a, int x) { };