Re: Compilation failure
On 07/20/2012 01:53 PM, bearophile wrote: Timon Gehr: Usually bugs are reported by the guy who finds them, but here you go: http://d.puremagic.com/issues/show_bug.cgi?id=8400 Thank you, already fixed, it seems. Even if the fix is the opposite of what I have thought (I was thinking about forbidding global immutables too to be used as compile-time constants, while this fix turns local immutables too into enums. I hope this change doesn't cause a large mess). They are not enums. They are interpretable at compile time if their initializer is interpretable at compile time. This makes sense. This is a bug fix. Similar code already works.
Re: Compilation failure
Timon Gehr: Usually bugs are reported by the guy who finds them, but here you go: http://d.puremagic.com/issues/show_bug.cgi?id=8400 Thank you, already fixed, it seems. Even if the fix is the opposite of what I have thought (I was thinking about forbidding global immutables too to be used as compile-time constants, while this fix turns local immutables too into enums. I hope this change doesn't cause a large mess). Bye, bearophile
Re: Compilation failure
On 07/19/2012 12:42 AM, bearophile wrote: Timon Gehr: You are right; this is a bug. This discussion is not about an obscure language detail, it's a common situation. FWIW, I have never run across it before. So if you think this is a bug, then please Timon file it in Bugzilla. Usually bugs are reported by the guy who finds them, but here you go: http://d.puremagic.com/issues/show_bug.cgi?id=8400
Re: Compilation failure
Timon Gehr: You are right; this is a bug. This discussion is not about an obscure language detail, it's a common situation. So if you think this is a bug, then please Timon file it in Bugzilla. Bye, bearophile
Re: Compilation failure
On Wednesday, 18 July 2012 at 12:15:52 UTC, Lemonfiend wrote: On Wednesday, 11 July 2012 at 02:30:47 UTC, Timon Gehr wrote: On 07/11/2012 04:25 AM, ixid wrote: in some way it sees global immutables almost as enums This seems like a bad idea. Consistency of behaviour would seem to be a good principle to expect of a language. You are right; this is a bug. Has someone reported this bug? I can't seem to find it in the tracker. If not, how should I go about reporting it? Also, I don't think I'm clear enough about the differences between immutables, consts and enums to write a bug report about this.
Re: Compilation failure
On Wednesday, 11 July 2012 at 02:30:47 UTC, Timon Gehr wrote: On 07/11/2012 04:25 AM, ixid wrote: in some way it sees global immutables almost as enums This seems like a bad idea. Consistency of behaviour would seem to be a good principle to expect of a language. You are right; this is a bug. Has someone reported this bug? I can't seem to find it in the tracker. If not, how should I go about reporting it?
Re: Compilation failure
On 07/11/2012 04:25 AM, ixid wrote: in some way it sees global immutables almost as enums This seems like a bad idea. Consistency of behaviour would seem to be a good principle to expect of a language. You are right; this is a bug.
Re: Compilation failure
in some way it sees global immutables almost as enums This seems like a bad idea. Consistency of behaviour would seem to be a good principle to expect of a language.
Re: Compilation failure
On Sunday, 8 July 2012 at 22:10:32 UTC, bearophile wrote:
When tmp1 is defined globally, dmd is doing something
different, in some way it sees global immutables almost as
enums... I don't know if this is present in D specs.
You see it well with this test program:
immutable int[] A = [1];
template Foo(size_t n) {}
void main() {
alias Foo!(A.length) fooA; // OK
enum int[] B = [1];
alias Foo!(B.length) fooB; // OK
immutable int[] C = [1];
alias Foo!(C.length) fooC; // error
}
Bye,
bearophile
Thanks for the reply and explanation.
I would never have thought that the declaration scope (local vs
global) would have such an effect.. Is this specified anywhere?
Re: Compilation failure
On 07/08/2012 11:47 PM, Lemonfiend wrote:
Hi,
I seem to have run into a strange error..
When I put tmp1 outside the main loop, it compiles fine and gives the
expected output.
When tmp1 is put inside the main loop, the compiler seems to get stuck
in a loop?
I've tested it on: http://dlang.org/index.html
See error on bottom (lol)
#!/usr/bin/rdmd
import std.stdio;
//immutable int[] tmp1 = [1, 2]; // compiles
void main()
{
immutable int[] tmp1 = [1, 2]; // does not compile
int[tmp1.length] tmp2 = tmp1;
tmp2[] += 1;
writeln(tmp1);
writeln(tmp2);
}
I'd argue that this is a bug. The length of an immutable variable with
a constant initializer should be a constant expression.
Presumably this is caused by the compiler rewriting the array literal
into an allocation.
Re: Compilation failure
On Sunday, 8 July 2012 at 22:10:32 UTC, bearophile wrote:
When tmp1 is defined globally, dmd is doing something
different, in some way it sees global immutables almost as
enums... I don't know if this is present in D specs.
You see it well with this test program:
immutable int[] A = [1];
template Foo(size_t n) {}
void main() {
alias Foo!(A.length) fooA; // OK
enum int[] B = [1];
alias Foo!(B.length) fooB; // OK
immutable int[] C = [1];
alias Foo!(C.length) fooC; // error
}
Bye,
bearophile
Thanks for the reply and explanation.
I would never have thought that the declaration scope (local vs
global) would have such an effect.. Is this specified anywhere?
Re: Compilation failure
When tmp1 is defined globally, dmd is doing something
different, in some way it sees global immutables almost as
enums... I don't know if this is present in D specs.
You see it well with this test program:
immutable int[] A = [1];
template Foo(size_t n) {}
void main() {
alias Foo!(A.length) fooA; // OK
enum int[] B = [1];
alias Foo!(B.length) fooB; // OK
immutable int[] C = [1];
alias Foo!(C.length) fooC; // error
}
Bye,
bearophile
Re: Compilation failure
The large number of the same error message is small a compiler diagnostic bug, that should be reported in bugzilla. It was already reported by me, I have added your case: http://d.puremagic.com/issues/show_bug.cgi?id=8312 Bye, bearophile
Re: Compilation failure
When I put tmp1 outside the main loop, it compiles fine and
gives the expected output.
When tmp1 is put inside the main loop, the compiler seems to
get stuck in a loop?
//immutable int[] tmp1 = [1, 2]; // compiles
void main()
{
immutable int[] tmp1 = [1, 2]; // does not compile
int[tmp1.length] tmp2 = tmp1;
tmp2[] += 1;
Generally the int[tmp1.length] syntax tries to define a
fixed-sized array, but currently in D there are no
VariableLengthArrays of C99, there are only dynamic arrays and
fixed-sized arrays, so the size must be known at compile-time.
But when tmp1 is defined inside the main, it is a dynamic array,
so its length isn't a compile-time known value. This explains why
it doesn't compile if tmp1 is defined inside the main().
The large number of the same error message is small a compiler
diagnostic bug, that should be reported in bugzilla.
When tmp1 is defined globally, dmd is doing something different,
in some way it sees global immutables almost as enums... I don't
know if this is present in D specs.
Bye,
bearophile
Compilation failure
Hi,
I seem to have run into a strange error..
When I put tmp1 outside the main loop, it compiles fine and gives
the expected output.
When tmp1 is put inside the main loop, the compiler seems to get
stuck in a loop?
I've tested it on: http://dlang.org/index.html
See error on bottom (lol)
#!/usr/bin/rdmd
import std.stdio;
//immutable int[] tmp1 = [1, 2]; // compiles
void main()
{
immutable int[] tmp1 = [1, 2]; // does not compile
int[tmp1.length] tmp2 = tmp1;
tmp2[] += 1;
writeln(tmp1);
writeln(tmp2);
}
----
Compilation failure:
834.d(9): Error: Integer constant expression expected instead of
(tmp1 = [1,2]).length834.d(9): Error: Integer constant expression
expected instead of (tmp1 = [1,2]).length834.d(9): Error: Integer
constant expression expected instead of (tmp1 =
[1,2]).length834.d(9): Error: Integer constant expression
expected instead of (tmp1 = [1,2]).length834.d(9): Error: Integer
constant expression expected instead of (tmp1 =
[1,2]).length834.d(9): Error: Integer constant expression
expected instead of (tmp1 = [1,2]).length834.d(9): Error: Integer
constant expression expected instead of (tmp1 =
[1,2]).length834.d(9): Error: Integer constant expression
expected instead of (tmp1 = [1,2]).length834.d(9): Error: Integer
constant expression expected instead of (tmp1 =
[1,2]).length834.d(9): Error: Integer constant expression
expected instead of (tmp1 = [1,2]).length834.d(9): Error: Integer
constant expression expected instead of (tmp1 =
[1,2]).length834.d(9): Error: Integer constant expression
expected instead of (tmp1 = [1,2]).length834.d(9): Error: Integer
constant expression expected instead of (tmp1 =
[1,2]).length834.d(9): Error: Integer constant expression
expected instead of (tmp1 = [1,2]).length834.d(9): Error: Integer
constant expression expected instead of (tmp1 =
[1,2]).length834.d(9): Error: Integer constant expression
expected instead of (tmp1 = [1,2]).length834.d(9): Error: Integer
constant expression expected instead of (tmp1 =
[1,2]).length834.d(9): Error: Integer constant expression
expected instead of (tmp1 = [1,2]).length834.d(9): Error: Integer
constant expression expected instead of (tmp1 =
[1,2]).length834.d(9): Error: Integer constant expression
expected instead of (tmp1 = [1,2]).length834.d(9): Error: Integer
constant expression expected instead of (tmp1 =
[1,2]).length834.d(9): Error: Integer constant expression
expected instead of (tmp1 = [1,2]).length834.d(9): Error: Integer
constant expression expected instead of (tmp1 =
[1,2]).length834.d(9): Error: Integer constant expression
expected instead of (tmp1 = [1,2]).length834.d(9): Error: Integer
constant expression expected instead of (tmp1 =
[1,2]).length834.d(9): Error: Integer constant expression
expected instead of (tmp1 = [1,2]).length834.d(9): Error: Integer
constant expression expected instead of (tmp1 =
[1,2]).length834.d(9): Error: Integer constant expression
expected instead of (tmp1 = [1,2]).length834.d(9): Error: Integer
constant expression expected instead of (tmp1 =
[1,2]).length834.d(9): Error: Integer constant expression
expected instead of (tmp1 = [1,2]).length834.d(9): Error: Integer
constant expression expected instead of (tmp1 =
[1,2]).length834.d(9): Error: Integer constant expression
expected instead of (tmp1 = [1,2]).length834.d(9): Error: Integer
constant expression expected instead of (tmp1 =
[1,2]).length834.d(9): Error: Integer constant expression
expected instead of (tmp1 = [1,2]).length834.d(9): Error: Integer
constant expression expected instead of (tmp1 =
[1,2]).length834.d(9): Error: Integer constant expression
expected instead of (tmp1 = [1,2]).length834.d(9): Error: Integer
constant expression expected instead of (tmp1 =
[1,2]).length834.d(9): Error: Integer constant expression
expected instead of (tmp1 = [1,2]).length834.d(9): Error: Integer
constant expression expected instead of (tmp1 =
[1,2]).length834.d(9): Error: Integer constant expression
expected instead of (tmp1 = [1,2]).length834.d(9): Error: Integer
constant expression expected instead of (tmp1 =
[1,2]).length834.d(9): Error: Integer constant expression
expected instead of (tmp1 = [1,2]).length834.d(9): Error: Integer
constant expression expected instead of (tmp1 =
[1,2]).length834.d(9): Error: Integer constant expression
expected instead of (tmp1 = [1,2]).length834.d(9): Error: Integer
constant expression expected instead of (tmp1 =
[1,2]).length834.d(9): Error: Integer constant expression
expected instead of (tmp1 = [1,2]).length834.d(9): Error: Integer
constant expression expected instead of (tmp1 =
[1,2]).length834.d(9): Error: Integer constant expression
expected instead of (tmp1 = [1,2]).length834.d(9): Error: Integer
constant expression expected instead of (tmp1 =
[1,2]).length834.d(9): Error: Integer constant expression
exp
Re: Assert compilation failure with certain message
I thought you were just looking for a static assert with a custom message?
Re: Assert compilation failure with certain message
Andrej Mitrovic napisał:
> I've managed to screw up the colon placement though, here's a quick fix:
>
> import std.stdio;
> import std.conv;
>
> void staticAssert(alias exp, string message, string file = __FILE__,
> int line = __LINE__)()
> {
> static if (!exp)
> {
> pragma(msg, file ~ "(" ~ to!string(line) ~ "): " ~
> "staticAssert: " ~ to!string(message));
> assert(0);
> }
> }
>
> void main()
> {
> enum x = false;
> staticAssert!(x, "Oh no we failed!");
>
> int y;
> }
How does it help to find out that compilation tripped on a specific static
assertion?
--
Tomek
Re: Assert compilation failure with certain message
Tomek S.: > Static catch, yeah. But I'd be content with traits__(fails, expr, msg) which > seems tractable. Asking for new features in this newsgroup is not so useful. You may add it to bugzilla... Bye, bearophile
Re: Assert compilation failure with certain message
I've managed to screw up the colon placement though, here's a quick fix:
import std.stdio;
import std.conv;
void staticAssert(alias exp, string message, string file = __FILE__,
int line = __LINE__)()
{
static if (!exp)
{
pragma(msg, file ~ "(" ~ to!string(line) ~ "): " ~
"staticAssert: " ~ to!string(message));
assert(0);
}
}
void main()
{
enum x = false;
staticAssert!(x, "Oh no we failed!");
int y;
}
Re: Assert compilation failure with certain message
How's this?
import std.stdio;
import std.conv;
void staticAssert(alias exp, string message, string file = __FILE__,
int line = __LINE__)()
{
static if (!exp)
{
pragma(msg, file ~ ":(" ~ to!string(line) ~ ") " ~
"staticAssert: " ~ to!string(message));
assert(0);
}
}
void main()
{
enum x = false;
staticAssert!(x, "Oh no we failed!");
int y;
}
Re: Assert compilation failure with certain message
bearophile napisał: > > Is there a way to statically assert compilation of an expression failed > > *with a certain message*? I want to check > > my static asserts trip when they should. > > I have asked something like this a lot of time ago, but I don't know a way to > do it. You are able to statically > assert that some code doesn't compile, but I don't know how to assert that a > certain message gets produced. You are > asking for a specific static catch :-) Static catch, yeah. But I'd be content with traits__(fails, expr, msg) which seems tractable. -- Tomek
Re: Assert compilation failure with certain message
On Thursday, February 10, 2011 16:12:01 Tomek Sowiński wrote: > Is there a way to statically assert compilation of an expression failed > *with a certain message*? I want to check my static asserts trip when they > should. You mean like static assert(0, "We have a failure, Captain!"); If a static assert fails, it's obvious. Compilation fails. Now, if you're trying to assert something like that a particular template instantiation fails, the use static assert(!__traits(compiles, exp)); where exp is the expression being tested. - Jonathan M Davis
Re: Assert compilation failure with certain message
Tomek Sowiñski: > Is there a way to statically assert compilation of an expression failed *with > a certain message*? I want to check my static asserts trip when they should. I have asked something like this a lot of time ago, but I don't know a way to do it. You are able to statically assert that some code doesn't compile, but I don't know how to assert that a certain message gets produced. You are asking for a specific static catch :-) Bye, bearophile
Assert compilation failure with certain message
Is there a way to statically assert compilation of an expression failed *with a certain message*? I want to check my static asserts trip when they should. -- Tomek
