[Issue 6534] New: const struct definition inside functions too
http://d.puremagic.com/issues/show_bug.cgi?id=6534
Summary: const struct definition inside functions too
Product: D
Version: D2
Platform: x86
OS/Version: Windows
Status: NEW
Keywords: rejects-valid
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2011-08-19 23:22:23 PDT ---
void foo() {
const struct Bar {}
}
void main() {}
DMD 2.055beta:
test.d(2): basic type expected, not struct
test.d(2): no identifier for declarator int
test.d(2): semicolon expected, not 'struct'
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6534] const struct definition inside functions too
http://d.puremagic.com/issues/show_bug.cgi?id=6534
--- Comment #1 from bearophile_h...@eml.cc 2011-08-19 23:42:15 PDT ---
The same happens with static structs:
void foo() {
static const struct Bar {}
}
void main() {}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6535] New: RDMD outputs broken library files
http://d.puremagic.com/issues/show_bug.cgi?id=6535
Summary: RDMD outputs broken library files
Product: D
Version: D2
Platform: x86_64
OS/Version: Linux
Status: NEW
Severity: major
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: past...@gmail.com
--- Comment #0 from GreatEmerald past...@gmail.com 2011-08-20 01:00:22 PDT ---
When trying to compile a static library with RDMD, the output file is always 72
bytes long, which of course is not valid. Using DMD to compile the library
works correctly.
To reproduce, I use this basic D file:
===
module lib;
import std.stdio;
void libraryFunction()
{
writeln(You have executed the library function!);
}
===
If I try to compile it with RDMD using this syntax:
===
rdmd --build-only -lib lib.d
===
I get a lib.a file that is 72 bytes long. However, if I use the standalone DMD
like this:
===
dmd -lib lib.d
===
The resulting file is 43.5 kibibytes of size and valid. If I make RDMD chatty
and enable both standard and informational warnings, it shows that a
lib.d.X file is created in the /tmp/.rdmd
directory and is of 43.5 kibibytes size. I assume it is the correct file (the
size matches exactly) that somehow doesn't get copied to the directory I am
building the library in.
I am using RDMD build 20110706, DMD64 v2.054, openSUSE 11.4 x86_64.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6528] Private module functions optimizations
http://d.puremagic.com/issues/show_bug.cgi?id=6528
--- Comment #1 from bearophile_h...@eml.cc 2011-08-20 01:14:33 PDT ---
Another optimization example:
private void foo(int[] a) {}
void main() {
int[100] array;
foo(array);
}
Converted to:
private void foo(ref int[100] a) {}
void main() {
int[100] array;
foo(array);
}
--
The optimization is possible if foo has more than one call from the module, if
the body of foo is short:
private void foo(int[] a) {
// this is a short function
}
void main() {
int[100] array1;
foo(array1);
int[200] array2;
foo(array2);
}
Converted to:
private void foo(size_t N)(ref int[N] a) {
// this is a short function
}
void main() {
int[100] array1;
foo(array1);
int[200] array2;
foo(array2);
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6536] New: in operator for inclusivity in array index range
http://d.puremagic.com/issues/show_bug.cgi?id=6536
Summary: in operator for inclusivity in array index range
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2011-08-20 03:51:05 PDT ---
This is a low-priority enhancement request. What's discussed here is not
exceptionally useful, it's just a small convenience.
In Python programs a quite common operation is to verify an item is present
inside a short list:
L = [3, 7, 11]
x = 7
x in L
True
In Bugzilla there is an old enhancement request that asks for something similar
with the in operator on the built-in D arrays. So far it was not accepted,
despite its usefulness because:
- In associative arrays in searches on keys (indexes), while on arrays it has
to search on values. This difference in semantics is perceived as a problem
(despite it is not a problem in Python).
- in is meant to be a O(ln n) operator or faster.
One proposal was to accept in operator only on arrays with a length known at
compile-time, usually short arrays (like in the Python example above). This is
still a linear search, but it's bounded. This is a rather useful operation.
Here I propose something different. To define the in operator for the
built-in arrays to search on the indexes. The in operator is too much good to
waste. This search has the same semantics as the in for associative arrays,
and it's always O(1). Despite this is not nearly as useful as searching among
the array contents, it's useful still, there are some use cases.
A simple use case is for pre-conditions, like:
void foo(int[] array, int x)
in {
assert(x = 0 x array.length);
} body {}
That assert becomes:
assert(x in array);
This is simpler to read, shorter, and less bug prone. The less bug-prone aspect
of this syntax is not of secondary importance, because such compound tests are
often source of small bugs.
A problem of this syntax is that Python (and other) programmers expect x in
array to search among the array values. This requires a bit of mental
retraining.
It's useful for loop invariants:
foreach (i; 0 .. N) {
// code here
const aux_index = some expression;
assert(aux_index = 0 aux_index array.length);
}
It becomes (this also avoids the need of a temporary variable that becomes
useless in release mode builds):
foreach (i; 0 .. N) {
// code here
assert((some expression) in array);
}
Another use case is for operations done on neighbours of every item of an array
(here a 2D array):
bool hasGoodNeighbours(int[][] table, int row, int col) {
foreach (rs; -1 .. 2)
foreach (cs; -1 .. 2)
if ((r + rs) = 0 (r + rs) table.length
(c + cs) = 0 (c + cs) table[0].length
isBad(table[r + rs][c + cs])
return false;
return true;
}
(This code assumes all the rows have the same length, here I have omitted the
pre-condition that verifies this).
The rs and cs allow to scan the 3x3 neighbourhood of every table item. But the
code needs tests to avoid going outside the matrix for the cells on the frame
of the matrix.
With the proposed idea the code becomes shorter and more readable:
bool hasGoodNeighbours(int[][] table, int row, int col) {
foreach (rs; -1 .. 2)
foreach (cs; -1 .. 2)
if ((r + rs) in table (c + cs) in table[0]
isBad(table[r + rs][c + cs])
return false;
return true;
}
I have had to use in table[0] because this proposed idea is just for single
arrays.
In a higher level language you specify where you are searching for, in domain
or codomain. So given a matrix A, you write (this is just a made up syntax, but
something similar is possible in Chapel language, where A is a generic
collection):
xy in A.domain
x in A.codomain
In the first case xy is a (x, y) tuple, that is verified to be a valid index
for the matrix. In the second case the x is an item that is verified to be
contained inside the 2D matrix. This is short and not semantically ambiguous.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 1433] in array / slice / range / enum / ...
http://d.puremagic.com/issues/show_bug.cgi?id=1433 bearophile_h...@eml.cc changed: What|Removed |Added CC||bearophile_h...@eml.cc --- Comment #1 from bearophile_h...@eml.cc 2011-08-20 03:53:18 PDT --- As alternative see bug 6536 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6537] New: OS X optimizer bug (?)
http://d.puremagic.com/issues/show_bug.cgi?id=6537
Summary: OS X optimizer bug (?)
Product: D
Version: D2
Platform: x86
OS/Version: Mac OS X
Status: NEW
Severity: major
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: c...@klickverbot.at
--- Comment #0 from klickverbot c...@klickverbot.at 2011-08-20 06:47:28 PDT
---
to!string() seems to produce wrong results with -O using current DMD here on my
OS X Lion box:
---
import std.conv;
import std.stdio;
void main() {
writefln(%s %s, long.min, to!string(long.min));
}
---
If I build the snippet without compiler flags, it prints (as expected):
-9223372036854775808 -9223372036854775808
If I add -O, however, the output becomes:
-9223372036854775808 -9223372032559808512
It seems like the lower 32 bits are zeroed out in the to!string() version (the
problem occurs also when to!string is used in isolation, the writefln is just
for demonstrative purposes).
Interestingly, this only occurs on my OS X box, I can't reproduce this in a
Linux VM (neither on x86 nor x86_64).
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6538] New: Invalid template constraints crash compiler
http://d.puremagic.com/issues/show_bug.cgi?id=6538
Summary: Invalid template constraints crash compiler
Product: D
Version: D2
Platform: Other
OS/Version: Windows
Status: NEW
Keywords: ice-on-invalid-code
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: dsim...@yahoo.com
--- Comment #0 from David Simcha dsim...@yahoo.com 2011-08-20 06:57:00 PDT ---
The following code crashes the compiler on Windows:
template allSatisfy(alias F, T...)
{
enum bool allSatisfy = true;
}
template isIntegral(T)
{
enum bool isIntegral = true;
}
// This is invalid because allSatisfy is passed sizes, not I.
void foo(I...)(I sizes)
if(allSatisfy!(isIntegral, sizes)) {}
void main() {
auto arr = foo(42, 86);
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6537] OS X optimizer bug (?)
http://d.puremagic.com/issues/show_bug.cgi?id=6537 klickverbot c...@klickverbot.at changed: What|Removed |Added Keywords||wrong-code --- Comment #1 from klickverbot c...@klickverbot.at 2011-08-20 07:02:42 PDT --- This also happens when explicitly using GCC 4.2, so it's not a case of DMD getting miscompiled by LLVM-GCC/Clang. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6537] OS X optimizer bug (?)
http://d.puremagic.com/issues/show_bug.cgi?id=6537 Jacob Carlborg d...@me.com changed: What|Removed |Added CC||d...@me.com --- Comment #2 from Jacob Carlborg d...@me.com 2011-08-20 08:26:16 PDT --- I can reproduce it on Mac OS X 10.6.8. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6537] OS X optimizer bug (?)
http://d.puremagic.com/issues/show_bug.cgi?id=6537 klickverbot c...@klickverbot.at changed: What|Removed |Added Severity|major |critical --- Comment #3 from klickverbot c...@klickverbot.at 2011-08-20 08:28:40 PDT --- Thanks Jacob, raising the importance to critical. It seems to happen for numbers smaller than int.min, but I haven't scanned the whole range or anything. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6537] OS X optimizer bug (?)
http://d.puremagic.com/issues/show_bug.cgi?id=6537 --- Comment #5 from Jacob Carlborg d...@me.com 2011-08-20 08:53:54 PDT --- I'm using the 2.054 release. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6539] New: Incomprehensible error message with failed template instantiation
http://d.puremagic.com/issues/show_bug.cgi?id=6539
Summary: Incomprehensible error message with failed template
instantiation
Product: D
Version: D2
Platform: Other
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: andrej.mitrov...@gmail.com
--- Comment #0 from Andrej Mitrovic andrej.mitrov...@gmail.com 2011-08-20
15:16:05 PDT ---
foo.d:
struct Rectangle(T) {}
bar.d:
bool Rectangle(bool, int, int, int, int);
main.d:
module main;
import foo;
import bar;
void test(Rectangle rect)
{
}
$ rdmd main.d
main.d(6): Error: overloadset __anonymous is used as a type
I've had this happen where I've used CairoD and WindowsAPI together. A
templated struct and a function have the same name in different modules.
My error is that I forgot to instantiate the template with a type, like so:
void test(Rectangle!int rect)
{
}
But the error message doesn't help one bit.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6540] New: Default struct constructor problem
http://d.puremagic.com/issues/show_bug.cgi?id=6540
Summary: Default struct constructor problem
Product: D
Version: D2
Platform: x86
OS/Version: Windows
Status: NEW
Keywords: rejects-valid
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2011-08-20 15:27:16 PDT ---
I don't understand what's happening here, but I think there is something wrong:
struct V3 {
double[3] v;
void foo() {
auto v2 = v[] / 2;
V3 r = V3(v2); // line 5
}
}
void main() {}
DMD 2.055beta gives:
test.d(5): Error: cannot implicitly convert expression (v2) of type double[] to
double
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6541] New: using synchronized on a templated method crashes the compiler
http://d.puremagic.com/issues/show_bug.cgi?id=6541 Summary: using synchronized on a templated method crashes the compiler Product: D Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: transmethyl+...@gmail.com --- Comment #0 from wolfwood transmethyl+...@gmail.com 2011-08-20 19:06:06 PDT --- Created an attachment (id=1019) a testcase for compiling a static synchronized method seems related to issue 5664, but not as trivial a fix. attached code show how a normal static synchronized method compiles just fine, but a templated version fails. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
