[Issue 8825] Wrong line number of error message
http://d.puremagic.com/issues/show_bug.cgi?id=8825 --- Comment #2 from github-bugzi...@puremagic.com 2013-09-21 00:50:08 PDT --- Commit pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/3ad9c76c0d553b20f417f166ee9e35cc1d7994ee fix Issue 8825 - Wrong line number of error message - Each tokens should have its own 'loc'. - Rename `Lexer::loc` to `scanloc` to avoid misuse of lookahead-loc. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11080] assert(`string`) should be forbidden
http://d.puremagic.com/issues/show_bug.cgi?id=11080 monarchdo...@gmail.com changed: What|Removed |Added CC||monarchdo...@gmail.com --- Comment #1 from monarchdo...@gmail.com 2013-09-21 01:50:42 PDT --- Not sure it's valid: What you are seeing is basically a dynamic array implicitly decaying to its pointer / boolean in a conditional clause. Some (myself included) judge this feature should be deprecated anyways. For example, this would be a legit use of assert(string): string s; assert(s); So, overall, I think you are seeing a special case of a more generic problem, eg: while (hello) ... if (hello) ... auto k = hello ? ... : ... ; All of the above I judge ambiguous. I couldn't find any relevant entries about this, but the issue *has* been beaten to death on the forums: http://forum.dlang.org/thread/bwgnbflygowctlisi...@forum.dlang.org Enjoy :) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11081] New: Win64: duplicate COMDAT with failed compilation with lambdas
http://d.puremagic.com/issues/show_bug.cgi?id=11081
Summary: Win64: duplicate COMDAT with failed compilation with
lambdas
Product: D
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: regression
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: r.sagita...@gmx.de
--- Comment #0 from Rainer Schuetze r.sagita...@gmx.de 2013-09-21 02:52:59
PDT ---
With current git-HEAD, this code snippet extracted from the std.exception
unittests:
T ifThrown2(E : Throwable, T)(T delegate(E) errorHandler)
{
return errorHandler();
}
unittest
{
static if (__traits(compiles, ifThrown2!Exception(e = 0)))
{
}
static if (__traits(compiles, ifThrown2!Exception(e = 0)))
{
}
}
compiled with dmd -m64 -unittest -main results in:
test.obj : fatal error LNK1179: invalid or corrupt file: duplicate COMDAT
'_D4te
st15__unittestL32_5FZv17__T0TC9ExceptionZ0MFNaNbNfC9ExceptionZi'
This does not happen with dmd 2.063. The code actually does not compile, so it
seems that broken code is emitted to the object file.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11080] assert(`string`) should be forbidden
http://d.puremagic.com/issues/show_bug.cgi?id=11080 Maxim Fomin ma...@maxim-fomin.ru changed: What|Removed |Added CC||ma...@maxim-fomin.ru --- Comment #2 from Maxim Fomin ma...@maxim-fomin.ru 2013-09-21 03:01:19 PDT --- I think banning assert(Any array literal); makes sense as it is always true and may hide programmer error of forgetting to place some condition before string. Empty array literal is a special case - it is currently implemented as pair null + 0 size. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11080] assert(`string`) should be forbidden
http://d.puremagic.com/issues/show_bug.cgi?id=11080 --- Comment #3 from Temtaime temta...@gmail.com 2013-09-21 04:26:39 PDT --- D allows implicit convertion from an array to bool ? It's... strange. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11081] Win64: duplicate COMDAT with failed compilation with lambdas
http://d.puremagic.com/issues/show_bug.cgi?id=11081 Rainer Schuetze r.sagita...@gmx.de changed: What|Removed |Added Keywords||pull --- Comment #1 from Rainer Schuetze r.sagita...@gmx.de 2013-09-21 04:33:22 PDT --- https://github.com/D-Programming-Language/dmd/pull/2578 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11080] assert(`string`) should be forbidden
http://d.puremagic.com/issues/show_bug.cgi?id=11080 Temtaime temta...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #5 from Temtaime temta...@gmail.com 2013-09-21 04:39:26 PDT --- Okay. Then it's my mistake. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11080] assert(`string`) should be forbidden
http://d.puremagic.com/issues/show_bug.cgi?id=11080 bearophile_h...@eml.cc changed: What|Removed |Added CC||bearophile_h...@eml.cc --- Comment #4 from bearophile_h...@eml.cc 2013-09-21 04:38:30 PDT --- (In reply to comment #3) D allows implicit convertion from an array to bool ? It's... strange. Right, I think this bug report should be closed. The design bug to fix is to refuse the implicit convertion from a dynamic array to bool (and perhaps there is already a bug report open on that). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4733] Possible bugs caused by dynamic arrays in boolean evaluation context
http://d.puremagic.com/issues/show_bug.cgi?id=4733 --- Comment #4 from bearophile_h...@eml.cc 2013-09-21 05:19:09 PDT --- See also issue 11080, that asks to disallow this bug-prone construct: assert(something going wrong); -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11080] assert(`string`) should be forbidden
http://d.puremagic.com/issues/show_bug.cgi?id=11080 --- Comment #6 from bearophile_h...@eml.cc 2013-09-21 05:15:43 PDT --- The bug report is mine, you could vote it: http://d.puremagic.com/issues/show_bug.cgi?id=4733 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11080] assert(`string`) should be forbidden
http://d.puremagic.com/issues/show_bug.cgi?id=11080 bearophile_h...@eml.cc changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Comment #7 from bearophile_h...@eml.cc 2013-09-21 05:18:39 PDT --- (In reply to comment #5) Okay. Then it's my mistake. On the other hand Issue 4733 is opened since three years, so I don't know if Walter Andrei agree with it. If Issue 4733 gets refused then adding a warning or error for assert(something) is a good idea. So I thin it's better to keep this open until there's an official answer on Issue 4733. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8851] std.string.join should allow 'char' as joiner
http://d.puremagic.com/issues/show_bug.cgi?id=8851 bearophile_h...@eml.cc changed: What|Removed |Added CC||bearophile_h...@eml.cc --- Comment #9 from bearophile_h...@eml.cc 2013-09-21 05:27:57 PDT --- See also Issue 5542 that is different but related. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9207] std.array.join of immutable(string[])
http://d.puremagic.com/issues/show_bug.cgi?id=9207 bearophile_h...@eml.cc changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #3 from bearophile_h...@eml.cc 2013-09-21 05:27:00 PDT --- *** This issue has been marked as a duplicate of issue 7690 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7690] std.string.join of const string array too
http://d.puremagic.com/issues/show_bug.cgi?id=7690 --- Comment #3 from bearophile_h...@eml.cc 2013-09-21 05:27:00 PDT --- *** Issue 9207 has been marked as a duplicate of this issue. *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11083] New: Whole global matrix initialization
http://d.puremagic.com/issues/show_bug.cgi?id=11083
Summary: Whole global matrix initialization
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 2013-09-21 05:34:08 PDT ---
I am not sure if this is an enhancement request, but I'd like to initialized
the whole module-level 'a' to a given value:
double[2][2] a = 0.0; // error
void main() {
double[2][2] b = 0.0; // OK
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11082] New: std.algorithm.join of a dynamic array of fixed-size arrays
http://d.puremagic.com/issues/show_bug.cgi?id=11082
Summary: std.algorithm.join of a dynamic array of fixed-size
arrays
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: rejects-valid
Severity: enhancement
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2013-09-21 05:30:56 PDT ---
import std.algorithm: join;
void main() {
int[2][] a = [[1, 2]];
join(a);
}
test.d(4): Error: template std.array.join does not match any function template
declaration. Candidates are:
...\dmd2\src\phobos\std\array.d(1449):std.array.join(RoR, R)(RoR ror, R
sep) if (isInputRange!RoR isInputRange!(ElementType!RoR) isInputRange!R
is(Unqual!(ElementType!(ElementType!RoR)) == Unqual!(ElementType!R)))
...\dmd2\src\phobos\std\array.d(1496):std.array.join(RoR)(RoR ror) if
(isInputRange!RoR isInputRange!(ElementType!RoR))
test.d(4): Error: template std.array.join(RoR, R)(RoR ror, R sep) if
(isInputRange!RoR isInputRange!(ElementType!RoR) isInputRange!R
is(Unqual!(ElementType!(ElementType!RoR)) == Unqual!(ElementType!R))) cannot
deduce template function from argument types !()(int[2][])
See also Issue 7690
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11084] New: std.algorithm.scan
http://d.puremagic.com/issues/show_bug.cgi?id=11084
Summary: std.algorithm.scan
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2013-09-21 05:47:16 PDT ---
I suggest to add to Phobos a function that returns a range, with usage very
similar to std.algorithm.reduce, that returns all the intermediate values.
An example from Haskell:
Prelude [1 .. 10]
[1,2,3,4,5,6,7,8,9,10]
Prelude scanl (+) 0 [1 .. 10]
[0,1,3,6,10,15,21,28,36,45,55]
Prelude scanr (+) 0 [1 .. 10]
[55,54,52,49,45,40,34,27,19,10,0]
That is also related to the FoldList of Mathematica:
http://reference.wolfram.com/mathematica/ref/FoldList.html
In D it could work like this:
iota(1, 11).scan!q{a + b}(0).writeln
==
[0, 1, 3, 6, 10, 15, 21, 28, 36, 45, 55]
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11084] std.algorithm.scan
http://d.puremagic.com/issues/show_bug.cgi?id=11084 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added CC||andrej.mitrov...@gmail.com --- Comment #1 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-09-21 05:52:21 PDT --- Intermediate? Can you be more specific? What exact steps does that scan!() call make? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11083] Whole global matrix initialization
http://d.puremagic.com/issues/show_bug.cgi?id=11083 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added CC||andrej.mitrov...@gmail.com --- Comment #1 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-09-21 05:54:13 PDT --- (In reply to comment #0) double[2][2] a = 0.0; // error I think it's actually just a bug that it's not accepted. Workaround: double[2][2] a = [0.0]; -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11085] New: Refused power vector operation of composed expression
http://d.puremagic.com/issues/show_bug.cgi?id=11085
Summary: Refused power vector operation of composed expression
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 2013-09-21 05:52:49 PDT ---
import std.math;
void main() {
double[3] a, b, c;
b[] = a[] ^^ 2; // OK
c[] = (a[] + b[]) * 2; // OK
c[] = (a[] + b[]) ^^ 2; // Error
}
DMD 2.064 alpha gives:
test.d(6): Error: incompatible types for ((a[] + b[]) ^^ (cast(double)2)):
'double[]' and 'double'
(Another problem is that the exponent should not be converted to double.)
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11082] std.algorithm.join of a dynamic array of fixed-size arrays
http://d.puremagic.com/issues/show_bug.cgi?id=11082 Peter Alexander peter.alexander...@gmail.com changed: What|Removed |Added CC||peter.alexander...@gmail.co ||m --- Comment #1 from Peter Alexander peter.alexander...@gmail.com 2013-09-21 05:54:01 PDT --- join works on a range of ranges, but here you have a range of static arrays, which are not ranges. I'm not sure if this is a valid enhancement. I'm not a fan of making special allowances for static arrays. If you had an array of containers it wouldn't work either. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11084] std.algorithm.scan
http://d.puremagic.com/issues/show_bug.cgi?id=11084 --- Comment #2 from bearophile_h...@eml.cc 2013-09-21 06:04:43 PDT --- (In reply to comment #1) Intermediate? Can you be more specific? What exact steps does that scan!() call make? The Haskell scanl is a very simple function, it acts very much like reduce, but instead of returning just the last result, it returns them all: scanl f z [x1, x2, ...] == [z, z `f` x1, (z `f` x1) `f` x2, ...] Its whole Haskell implementation in the Haskell Prelude: scanl :: (a - b - a) - a - [b] - [a] scanl f q ls = q : (case ls of [] - [] x:xs - scanl f (f q x) xs) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11082] std.algorithm.join of a dynamic array of fixed-size arrays
http://d.puremagic.com/issues/show_bug.cgi?id=11082
--- Comment #2 from bearophile_h...@eml.cc 2013-09-21 06:14:46 PDT ---
(In reply to comment #1)
join works on a range of ranges, but here you have a range of static arrays,
which are not ranges.
I don't care how you call those things inside the outer array, I call them
fixed sized arrays, they are language built-ins, and sometimes I have had to
collect them in a larger dynamic array. I have written a join function to join
them in my own code, and I think such functionality should be present in
Phobos. I see no good reason to keep such so basic functionality out of Phobos
and inside my own libraries.
Workarounds like this one are a waste of efficiency and they are noisy:
import std.algorithm: join;
import std.stdio, std.algorithm;
void main() {
int[2][] data = [[1, 2]];
data.map!q{ a[] }.join.writeln;
}
Also, that code doesn't work, you could avoid that trap with a dup:
import std.algorithm: join;
import std.stdio, std.algorithm;
void main() {
int[2][] data = [[1, 2]];
data.map!(a = a.dup).join.writeln;
}
I'm not sure if this is a valid enhancement. I'm not a fan of making special
allowances for static arrays.
C++, Ada and Rust languages show that if you want an efficient system language
you should encourage and help programmers avoid dynamic allocations where
possible. Fixed sized arrays help reduce heap allocations, and they should be
supported as much as possible by Phobos, instead of making them second-class
citizens. It's not a problem of those arrays, it's a problem of the Range
abstraction.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10277] Incorrect error file and line on redeclaration of TypeInfo
http://d.puremagic.com/issues/show_bug.cgi?id=10277 --- Comment #4 from github-bugzi...@puremagic.com 2013-09-21 06:15:07 PDT --- Commit pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/9837043cfc75a37d4a79941cc5b401e19213088d Merge pull request #1592 from rainers/demangle_local fix issues 10277 6045:improve demangling for function local symbols -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6045] Unable to demangle symbols
http://d.puremagic.com/issues/show_bug.cgi?id=6045 --- Comment #4 from github-bugzi...@puremagic.com 2013-09-21 06:15:13 PDT --- Commit pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/9837043cfc75a37d4a79941cc5b401e19213088d Merge pull request #1592 from rainers/demangle_local fix issues 10277 6045:improve demangling for function local symbols -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11082] std.algorithm.join of a dynamic array of fixed-size arrays
http://d.puremagic.com/issues/show_bug.cgi?id=11082 --- Comment #3 from Peter Alexander peter.alexander...@gmail.com 2013-09-21 06:37:47 PDT --- (In reply to comment #2) (In reply to comment #1) I'm not sure if this is a valid enhancement. I'm not a fan of making special allowances for static arrays. C++, Ada and Rust languages show that if you want an efficient system language you should encourage and help programmers avoid dynamic allocations where possible. Fixed sized arrays help reduce heap allocations, and they should be supported as much as possible by Phobos, instead of making them second-class citizens. It's not a problem of those arrays, it's a problem of the Range abstraction. I agree, and I use static arrays all the time, so I understand your frustrations. However, they are not second class citizens, at least not anymore than Array, SList, or any other container. The issue is that dynamic arrays are more than first-class citizens, they are a freak type that is strange combination of container and range. I do not look forward to having to write special overloads for every range-operating function that also accepts containers. It is impractical and a maintenance nightmare. There needs to be a better solution, so I would suggest we either find a way of automating this transform, or just live with the minor inconvenience of working with containers instead of ranges. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11080] assert(`string`) should be forbidden
http://d.puremagic.com/issues/show_bug.cgi?id=11080 --- Comment #8 from Maxim Fomin ma...@maxim-fomin.ru 2013-09-21 08:23:52 PDT --- (In reply to comment #7) (In reply to comment #5) Okay. Then it's my mistake. On the other hand Issue 4733 is opened since three years, so I don't know if Walter Andrei agree with it. If Issue 4733 gets refused then adding a warning or error for assert(something) is a good idea. So I thin it's better to keep this open until there's an official answer on Issue 4733. This may be a separate issue. For example, the problem you pointed out can be solved by rewriting array conditional evoluation to return length and not ptr which still technically allows to write assert(). In such case this isssue still has some value. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10277] Incorrect error file and line on redeclaration of TypeInfo
http://d.puremagic.com/issues/show_bug.cgi?id=10277 --- Comment #5 from github-bugzi...@puremagic.com 2013-09-21 09:17:08 PDT --- Commit pushed to master at https://github.com/D-Programming-Language/druntime https://github.com/D-Programming-Language/druntime/commit/64ae912e8e89840a0ed14fc149c10fe6bfb8e169 Merge pull request #611 from rainers/demangle_local fix issues 10277 6045:improve demangling for function local symbols -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6045] Unable to demangle symbols
http://d.puremagic.com/issues/show_bug.cgi?id=6045 --- Comment #5 from github-bugzi...@puremagic.com 2013-09-21 09:17:19 PDT --- Commit pushed to master at https://github.com/D-Programming-Language/druntime https://github.com/D-Programming-Language/druntime/commit/64ae912e8e89840a0ed14fc149c10fe6bfb8e169 Merge pull request #611 from rainers/demangle_local fix issues 10277 6045:improve demangling for function local symbols -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11081] Win64: duplicate COMDAT with failed compilation with lambdas
http://d.puremagic.com/issues/show_bug.cgi?id=11081 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||link-failure --- Comment #2 from Kenji Hara k.hara...@gmail.com 2013-09-21 09:52:11 PDT --- (In reply to comment #1) https://github.com/D-Programming-Language/dmd/pull/2578 Another one: https://github.com/D-Programming-Language/dmd/pull/2579 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11086] New: dmd segfault
http://d.puremagic.com/issues/show_bug.cgi?id=11086
Summary: dmd segfault
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: pyc...@qq.com
--- Comment #0 from Zhouxuan pyc...@qq.com 2013-09-21 10:18:10 PDT ---
//test.d
struct A
{
foo!(A) l1,l2;
}
dmd -main test.d will segfault
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11086] dmd segfault
http://d.puremagic.com/issues/show_bug.cgi?id=11086 monarchdo...@gmail.com changed: What|Removed |Added CC||monarchdo...@gmail.com Severity|normal |regression --- Comment #1 from monarchdo...@gmail.com 2013-09-21 10:34:27 PDT --- This is a 2.061 = 2.062 regression: 2.061: //--- main.d(3): Error: template instance foo!(A) template 'foo' is not defined main.d(3): Error: foo!(A) is used as a type main.d(3): Error: foo!(A) is used as a type END //--- 2.062: //--- main.d(3): Error: template instance foo!(A) template 'foo' is not defined main.d(3): Error: foo!(A) is used as a type CRASH //--- -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11080] assert(`string`) should be forbidden
http://d.puremagic.com/issues/show_bug.cgi?id=11080 --- Comment #9 from monarchdo...@gmail.com 2013-09-21 10:31:41 PDT --- (In reply to comment #8) This may be a separate issue. For example, the problem you pointed out can be solved by rewriting array conditional evoluation to return length and not ptr which still technically allows to write assert(). In such case this isssue still has some value. I don't really such much value in banning string literals in asserts. For starters, it is awfully specific. Second, I have trouble seeing why literals get such a special treatment, when assert(format(error)) is just as wrong. It'd be creating new rules to catch an error that virtually never happens anyways, and catches it un-reliably to boot. Finally, a valid use case I can see would be a user wanting to check that an empty string *actually does* implicitly evaluate to non null: static assert (, Error! string to bool evaluation rules have changed!); Chances are `assert(hello)` was wrong useage yes, but I think it hardly warrants new language rules... ...rules you wouldn't be able to apply to normal functions. For example an enforce that refuses array literals. Can't happen. A good rule of thumb is that if a built-in can do it, so should a user-built. This would not be the case for this new rule. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11080] assert(`string`) should be forbidden
http://d.puremagic.com/issues/show_bug.cgi?id=11080 Jonathan M Davis jmdavisp...@gmx.com changed: What|Removed |Added CC||jmdavisp...@gmx.com --- Comment #10 from Jonathan M Davis jmdavisp...@gmx.com 2013-09-21 10:43:48 PDT --- To completely accurate, strings do not implicitly convert to bool. Rather, in conditions, the compiler inserts cast(bool). So, in conditions, anything which can be explicitly cast to bool appears to be implicitly cast (when in fact it's explicitly cast), but outside of conditions, there is not such conversion. e.g. bool b = foo; will fail to compile. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11082] std.algorithm.join of a dynamic array of fixed-size arrays
http://d.puremagic.com/issues/show_bug.cgi?id=11082 Jonathan M Davis jmdavisp...@gmx.com changed: What|Removed |Added CC||jmdavisp...@gmx.com --- Comment #4 from Jonathan M Davis jmdavisp...@gmx.com 2013-09-21 10:48:34 PDT --- We're just asking for trouble if we try and treat containers as ranges. We have enough trouble with dynamic arrays, and they're only pseudo-containers. static arrays are _not_ ranges, should not be treated as such, and _cannot_ be treated as such. You'd have to special case algorithms to handle them, because they violate the range API by their very nature. And it's trivial enough to slice static arrays - even when they're inside a dynamic array - that I really don't think that it's worth complicating things with special cases for static arrays. I think that it's bad enough that static arrays are implicitly sliced when passed to a function which takes a dynamic array, as that's inherently unsafe. What you're asking for just makes that problem worse. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11080] assert(`string`) should be forbidden
http://d.puremagic.com/issues/show_bug.cgi?id=11080 --- Comment #11 from Maxim Fomin ma...@maxim-fomin.ru 2013-09-21 10:52:16 PDT --- (In reply to comment #9) (In reply to comment #8) This may be a separate issue. For example, the problem you pointed out can be solved by rewriting array conditional evoluation to return length and not ptr which still technically allows to write assert(). In such case this isssue still has some value. I don't really such much value in banning string literals in asserts. For starters, it is awfully specific. Second, I have trouble seeing why literals get such a special treatment, when assert(format(error)) is just as wrong. It'd be creating new rules to catch an error that virtually never happens anyways, and catches it un-reliably to boot. Assert(string) is a bug. There should be no discussion here. format(error) is not an array literal, so it is irrelevant. Finally, a valid use case I can see would be a user wanting to check that an empty string *actually does* implicitly evaluate to non null: static assert (, Error! string to bool evaluation rules have changed!); Ideally this should be documented and not be a subject to change. Anyway, one can test ptr and length properties. Chances are `assert(hello)` was wrong useage yes, but I think it hardly warrants new language rules... Assert(hello) is an uncoditional bug - no need to calculate any chances. ...rules you wouldn't be able to apply to normal functions. For example an enforce that refuses array literals. Can't happen. Enforce is irrelevant. A good rule of thumb is that if a built-in can do it, so should a user-built. This would not be the case for this new rule. Built-in can not, but user-built can. This does not get into a conflict with if a built-in can do it, so should a user-built. (Arguments based on rules of thumb coming from nowhere are hard to value). Contra point - dmd rejects some potentially broken code, for example 'l' suffix for integer literal and assignment in condition evaluation - which even is not necessarily a bug. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11080] assert(`string`) should be forbidden
http://d.puremagic.com/issues/show_bug.cgi?id=11080
--- Comment #12 from monarchdo...@gmail.com 2013-09-21 10:58:23 PDT ---
(In reply to comment #11)
Assert(string) is a bug. There should be no discussion here.
Why is it a bug? That's the discussion we're having. An array literal that
evaluates to null *will* trigger it. A user can test it.
void main()
{
enum string s1 = string;
enum string s2 = null;
assert( s1);
assert(!s2);
assert( );
assert(!string.init);
}
These all seem like legit use cases to me.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11080] assert(`string`) should be forbidden
http://d.puremagic.com/issues/show_bug.cgi?id=11080 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added CC||andrej.mitrov...@gmail.com --- Comment #13 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-09-21 11:08:02 PDT --- (In reply to comment #12) (In reply to comment #11) These all seem like legit use cases to me. Banning assert() just seems like a pointless special case, we should either disallow implicit conversion to bool or drop the issue altogether. Adding a special rule for assert is a bad idea, we already have enough special rules like assert(0). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11087] std.stdio.File.write implicitly converts Unix newlines to Windows newlines
http://d.puremagic.com/issues/show_bug.cgi?id=11087 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added Summary|std.file.File.write |std.stdio.File.write |implicitly converts Unix|implicitly converts Unix |newlines to Windows |newlines to Windows |newlines|newlines --- Comment #1 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-09-21 11:16:41 PDT --- Fixed title. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11087] std.stdio.File.write implicitly converts Unix newlines to Windows newlines
http://d.puremagic.com/issues/show_bug.cgi?id=11087 --- Comment #2 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-09-21 11:16:59 PDT --- Bug found by Orvid. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11087] New: std.file.File.write implicitly converts Unix newlines to Windows newlines
http://d.puremagic.com/issues/show_bug.cgi?id=11087
Summary: std.file.File.write implicitly converts Unix newlines
to Windows newlines
Product: D
Version: D2
Platform: All
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: andrej.mitrov...@gmail.com
--- Comment #0 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-09-21
11:16:20 PDT ---
-
import std.file;
import std.stdio;
void main()
{
std.file.write(test1.txt, a\nb);
auto file2 = File(test2.txt, w);
file2.write(a\nb);
file2.close();
auto res1 = cast(byte[])std.file.read(test1.txt);
auto res2 = cast(byte[])std.file.read(test2.txt);
writeln(res1); // writes [97, 10, 98]
writeln(res2); // writes [97, 13, 10, 98]
}
-
The first file has a \n, but the second file has a \r\n. There is no
documentation saying that File's write method does this internally.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 9776] Make raw write mode the default
http://d.puremagic.com/issues/show_bug.cgi?id=9776
--- Comment #2 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-09-21
11:20:33 PDT ---
Simple test-case from Issue 11087:
-
import std.file;
import std.stdio;
void main()
{
std.file.write(test1.txt, a\nb);
auto file2 = File(test2.txt, w);
file2.write(a\nb);
file2.close();
auto res1 = cast(byte[])std.file.read(test1.txt);
auto res2 = cast(byte[])std.file.read(test2.txt);
writeln(res1); // writes [97, 10, 98]
writeln(res2); // writes [97, 13, 10, 98]
}
-
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 9776] Make raw write mode the default
http://d.puremagic.com/issues/show_bug.cgi?id=9776 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added CC||andrej.mitrov...@gmail.com --- Comment #1 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-09-21 11:20:06 PDT --- *** Issue 11087 has been marked as a duplicate of this issue. *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11087] std.stdio.File.write implicitly converts Unix newlines to Windows newlines
http://d.puremagic.com/issues/show_bug.cgi?id=11087 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #3 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-09-21 11:20:05 PDT --- *** This issue has been marked as a duplicate of issue 9776 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11080] assert(`string`) should be forbidden
http://d.puremagic.com/issues/show_bug.cgi?id=11080 --- Comment #15 from Jonathan M Davis jmdavisp...@gmx.com 2013-09-21 11:28:57 PDT --- Why is it a bug? I think that the argument is that no one would ever want to assert than an array literal is true, because it's a given that it is. And if it's never something that programmers are going to want to do, and there's significant risk in doing that instead of assert(cond, msg); then it should be banned in order to avoid that particular mistake. That being said, I don't think that it's worth adding a special case to the compiler for this. We should avoid special casing stuff as much as we reasonably can, and I don't think that this problem is anywhere near big enough to merit one. I assume that Temtaime ran into this problem, because (s)he reported it, but I have never run into it - either in my own code or in anyone else's code - and I've never even heard of anyone running it before this. So, while clearly it has caused a problem for at least one person, I seriously question that it's much of a problem in general. Worst case, it sounds like the sort of thing that should be solved by a lint-like tool. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11080] assert(`string`) should be forbidden
http://d.puremagic.com/issues/show_bug.cgi?id=11080 bearophile_h...@eml.cc changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID --- Comment #14 from bearophile_h...@eml.cc 2013-09-21 11:27:21 PDT --- (In reply to comment #12) enum string s1 = string; enum string s2 = null; assert( s1); assert(!s2); assert( ); assert(!string.init); } These all seem like legit use cases to me. Using the bang (!) forces a explicit boolean conversion, that's different from implicit conversion from string to bool. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11082] std.algorithm.join of a dynamic array of fixed-size arrays
http://d.puremagic.com/issues/show_bug.cgi?id=11082
--- Comment #5 from bearophile_h...@eml.cc 2013-09-21 11:30:06 PDT ---
(In reply to comment #4)
You'd have to special case algorithms to handle them, because
they violate the range API by their very nature.
Right, I am asking for a specialization of join. It's worth doing.
And it's trivial enough to
slice static arrays - even when they're inside a dynamic array -
This code is buggy:
import std.algorithm: join;
import std.stdio, std.algorithm;
void main() {
int[2][] data = [[1, 2]];
data.map!q{ a[] }.join.writeln;
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11082] std.algorithm.join of a dynamic array of fixed-size arrays
http://d.puremagic.com/issues/show_bug.cgi?id=11082
--- Comment #6 from Peter Alexander peter.alexander...@gmail.com 2013-09-21
11:36:14 PDT ---
(In reply to comment #5)
(In reply to comment #4)
You'd have to special case algorithms to handle them, because
they violate the range API by their very nature.
Right, I am asking for a specialization of join. It's worth doing.
But is it worth doing for every other algorithm, and every container type? If
not, why not? If so, I'd say that's too much to ask.
And it's trivial enough to
slice static arrays - even when they're inside a dynamic array -
This code is buggy:
import std.algorithm: join;
import std.stdio, std.algorithm;
void main() {
int[2][] data = [[1, 2]];
data.map!q{ a[] }.join.writeln;
}
You have to do:
data.map!((ref a = a[])).join.writeln;
Unfortunately shorthand lambdas and unaryFun default to pass-by-value, so you
get a stack copy of your static array, which you then slice just as it goes out
of scope.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11080] assert(`string`) should be forbidden
http://d.puremagic.com/issues/show_bug.cgi?id=11080 --- Comment #16 from bearophile_h...@eml.cc 2013-09-21 11:37:28 PDT --- (In reply to comment #15) That being said, I don't think that it's worth adding a special case to the compiler for this. There is a much better and more general solution, from Issue 4733 . -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11088] New: Diagnostics for enum member overflows should improve
http://d.puremagic.com/issues/show_bug.cgi?id=11088
Summary: Diagnostics for enum member overflows should improve
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: diagnostic, pull
Severity: normal
Priority: P2
Component: DMD
AssignedTo: andrej.mitrov...@gmail.com
ReportedBy: andrej.mitrov...@gmail.com
--- Comment #0 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-09-21
12:18:48 PDT ---
-
enum E {
A = int.max,
B
}
-
test.d(3): Error: enum member test.E.B overflow of enum value cast(E)2147483647
It should be:
test.d(3): Error: enum member test.E.B initialization with (E.A + 1) causes
overflow for type 'int'
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11088] Diagnostics for enum member overflows should improve
http://d.puremagic.com/issues/show_bug.cgi?id=11088 --- Comment #1 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-09-21 12:23:49 PDT --- https://github.com/D-Programming-Language/dmd/pull/2581 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11082] std.algorithm.join of a dynamic array of fixed-size arrays
http://d.puremagic.com/issues/show_bug.cgi?id=11082
--- Comment #7 from bearophile_h...@eml.cc 2013-09-21 13:18:09 PDT ---
(In reply to comment #6)
But is it worth doing for every other algorithm, and every container type?
Probably not. But I think it's worth doing for a small subset of algorithms, as
std.algorithm.join.
Regarding containers, fixed sized arrays are built-ins, and they are supposed
to be used often, so it's not unreasonable to handle them differently/better
than library-defined containers.
You have to do:
data.map!((ref a = a[])).join.writeln;
Unfortunately shorthand lambdas and unaryFun default to pass-by-value, so you
get a stack copy of your static array, which you then slice just as it goes
out
of scope.
DMD has to give a compile-time error for such situation. I think there's an
enhancement request opened on that.
Joining a sequence of fixed-size arrays is a commonly done operation (in my
code), and that map+join code is bug-prone. Your code too has a small mistake:
import std.algorithm: join;
import std.stdio, std.algorithm;
void main() {
int[2][] data = [[1, 2]];
data.map!((ref a) = a[]).join.writeln;
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10203] std.string.toUpperInPlace is... not in place
http://d.puremagic.com/issues/show_bug.cgi?id=10203 Dmitry Olshansky dmitry.o...@gmail.com changed: What|Removed |Added CC||dmitry.o...@gmail.com --- Comment #4 from Dmitry Olshansky dmitry.o...@gmail.com 2013-09-21 13:58:19 PDT --- (In reply to comment #3) Wait, this example is wrong, corrected as: take the string aİ auto a = \x61\xC4\xB0; auto a = \x61\xC4\xB0.dup; auto b = a; toLowerInPlace(a); //Now: //a == \x61\x69 //b == \x61\x69\xB0 Oops: Trailing code unit :/ Sorry. I belive we now should have solid treatment of toUpper/toLower (pending a bugfix in the works). For me this gives now: //a == 61 69 CC 87 //b == 61 C4 B0 i.e. toLowerInPlace fails to do this in place because resulting length increases. Should it try to extend if a.capacity allows it? (I bet it has about 15 bytes of storage) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11089] New: std.string.toUpper doesn't work with 1:m mappings
http://d.puremagic.com/issues/show_bug.cgi?id=11089
Summary: std.string.toUpper doesn't work with 1:m mappings
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: dmitry.o...@gmail.com
--- Comment #0 from Dmitry Olshansky dmitry.o...@gmail.com 2013-09-21
14:07:32 PDT ---
Test case (taht fails due to a bug in std.uni toUpper tables):
void main(){
import std.string;
assert(\u00df.toUpper == SS);
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10203] std.string.toUpperInPlace is... not in place
http://d.puremagic.com/issues/show_bug.cgi?id=10203 bearophile_h...@eml.cc changed: What|Removed |Added CC||bearophile_h...@eml.cc --- Comment #5 from bearophile_h...@eml.cc 2013-09-21 14:13:19 PDT --- (In reply to comment #2) It seems to me that, overall, toLowerInPlace is a function that is broken, that cannot respect the specs it promises, and violates the principal of least surprise in regards to behavior. I think it should either be tagged with a massive red unsafe, or deprecated. Even if it's impossible for Unicode strings, I'd like to keep a version of it for just arrays of ASCII chars, that is a common enough use case. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10203] std.string.toUpperInPlace is... not in place
http://d.puremagic.com/issues/show_bug.cgi?id=10203 --- Comment #6 from Dmitry Olshansky dmitry.o...@gmail.com 2013-09-21 14:26:34 PDT --- (In reply to comment #5) (In reply to comment #2) It seems to me that, overall, toLowerInPlace is a function that is broken, that cannot respect the specs it promises, and violates the principal of least surprise in regards to behavior. I think it should either be tagged with a massive red unsafe, or deprecated. Even if it's impossible for Unicode strings, I'd like to keep a version of it for just arrays of ASCII chars, that is a common enough use case. It also works quite well for UTF-16. And it does now. And I would have kept it if only because of backwards compatibility perspective. There is no other primitive yet, but a version(s) with output range for all string transformations is something to look forward to. The only question is whether or not should this function try to use extra capacity beyond the length if it's present (that would make InPlace suffix look saner). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11089] std.string.toUpper doesn't work with 1:m mappings
http://d.puremagic.com/issues/show_bug.cgi?id=11089 Dmitry Olshansky dmitry.o...@gmail.com changed: What|Removed |Added Keywords||pull --- Comment #1 from Dmitry Olshansky dmitry.o...@gmail.com 2013-09-21 14:29:30 PDT --- https://github.com/D-Programming-Language/phobos/pull/1593 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11080] assert(`string`) should be forbidden
http://d.puremagic.com/issues/show_bug.cgi?id=11080
--- Comment #17 from Maxim Fomin ma...@maxim-fomin.ru 2013-09-21 14:29:19 PDT
---
(In reply to comment #12)
(In reply to comment #11)
Assert(string) is a bug. There should be no discussion here.
Why is it a bug? That's the discussion we're having. An array literal that
evaluates to null *will* trigger it. A user can test it.
void main()
{
enum string s1 = string;
enum string s2 = null;
assert( s1);
assert(!s2);
assert( );
assert(!string.init);
}
These all seem like legit use cases to me.
No, there is difference between array type object and array literal expression.
Code like assert(Array literal) (note that this is not assert(s) where 's'
refers to a string) is always a bug because the expression is always true and
indicates that user actually wanted assert(some_condition, array literal).
There is no reason to write such code. As I have pointed out above, even in
situations which are not surely error, dmd still aborts compilation. In this
regard discussed issue is clear because there is no doubt whether use case is a
bug or not.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11080] assert(`string`) should be forbidden
http://d.puremagic.com/issues/show_bug.cgi?id=11080 Maxim Fomin ma...@maxim-fomin.ru changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Comment #18 from Maxim Fomin ma...@maxim-fomin.ru 2013-09-21 14:33:12 PDT --- (In reply to comment #15) Why is it a bug? I think that the argument is that no one would ever want to assert than an array literal is true, because it's a given that it is. And if it's never something that programmers are going to want to do, and there's significant risk in doing that instead of assert(cond, msg); then it should be banned in order to avoid that particular mistake. That being said, I don't think that it's worth adding a special case to the compiler for this. We should avoid special casing stuff as much as we reasonably can, and I don't think that this problem is anywhere near big enough to merit one. I assume that Temtaime ran into this problem, because (s)he reported it, but I have never run into it - either in my own code or in anyone else's code - and I've never even heard of anyone running it before this. So, while clearly it has caused a problem for at least one person, I seriously question that it's much of a problem in general. Worst case, it sounds like the sort of thing that should be solved by a lint-like tool. I think this is not a big deal to add such 'special rule' as it clearly adds value to the language - discussed case is always a bug and nothing should be hurt by such special case. I reopen issue (by the way, marking it as invalid is wrong - there is wontfix for purposes you wish). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11080] assert(`string`) should be forbidden
http://d.puremagic.com/issues/show_bug.cgi?id=11080 --- Comment #19 from Maxim Fomin ma...@maxim-fomin.ru 2013-09-21 14:34:33 PDT --- (In reply to comment #16) (In reply to comment #15) That being said, I don't think that it's worth adding a special case to the compiler for this. There is a much better and more general solution, from Issue 4733 . (In reply to comment #16) (In reply to comment #15) That being said, I don't think that it's worth adding a special case to the compiler for this. There is a much better and more general solution, from Issue 4733 . Thanks for raising the problem, but this one is a separate issue. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10203] std.string.toUpperInPlace is... not in place
http://d.puremagic.com/issues/show_bug.cgi?id=10203 w0rp devw...@gmail.com changed: What|Removed |Added CC||devw...@gmail.com --- Comment #7 from w0rp devw...@gmail.com 2013-09-21 14:35:51 PDT --- It may be worth considering presenting only what is possible, so offer toUpperInPlace or toLowerInPlace only on ASCII data. As you say, Unicode strings change in byte length dramatically, but the ASCII range stays the same. So I think it would be worth offering functions with different names, or perhaps with locale template arguments. (Locale.ascii, or whatever.) Just so there can be a guarantee of something never allocating when you want to avoid that, but still let you get at a almost there function when you want that. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11080] assert(`string`) should be forbidden
http://d.puremagic.com/issues/show_bug.cgi?id=11080 --- Comment #20 from bearophile_h...@eml.cc 2013-09-21 14:55:15 PDT --- (In reply to comment #19) Thanks for raising the problem, but this one is a separate issue. It's a separate issue, but if you disallow dynamic arrays in boolean evaluation contexts, then it also disallows code like assert(something going wrong) and you don't need to add a special rule to D for such buggy case. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11080] assert(`string`) should be forbidden
http://d.puremagic.com/issues/show_bug.cgi?id=11080 --- Comment #21 from Maxim Fomin ma...@maxim-fomin.ru 2013-09-21 15:03:02 PDT --- (In reply to comment #20) (In reply to comment #19) Thanks for raising the problem, but this one is a separate issue. It's a separate issue, but if you disallow dynamic arrays in boolean evaluation contexts, then it also disallows code like assert(something going wrong) and you don't need to add a special rule to D for such buggy case. Yes, but one of the way to fix the issue (which I consider as a better one) is to cast array not to pointer but to length and still allow arrays in boolean conditions. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11086] dmd segfault
http://d.puremagic.com/issues/show_bug.cgi?id=11086 Infiltrator lt.infiltra...@gmail.com changed: What|Removed |Added CC||lt.infiltra...@gmail.com --- Comment #2 from Infiltrator lt.infiltra...@gmail.com 2013-09-21 16:11:31 PDT --- This looks to be fixed in 2.063: //--- /d741/f473.d(2): Error: template instance foo!(A) template 'foo' is not defined END //--- -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11088] Diagnostics for enum member overflows should improve
http://d.puremagic.com/issues/show_bug.cgi?id=11088 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added CC||bugzi...@digitalmars.com Severity|normal |enhancement -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11088] Diagnostics for enum member overflows should improve
http://d.puremagic.com/issues/show_bug.cgi?id=11088 --- Comment #2 from github-bugzi...@puremagic.com 2013-09-21 17:09:39 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/28dc52f3f1eeec025d18ae49d1ba4105da4dfbd2 Fixes Issue 11088 - Print better diagnostics for enum member overflow errors. https://github.com/D-Programming-Language/dmd/commit/a6075687eb9da2f7a5104d2663c25a65d96f08ed Merge pull request #2581 from AndrejMitrovic/Fix110088 Issue 11088 - Print better diagnostics for enum member overflow errors. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11088] Diagnostics for enum member overflows should improve
http://d.puremagic.com/issues/show_bug.cgi?id=11088 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5570] 64 bit C ABI not followed for passing structs and complex numbers as function parameters
http://d.puremagic.com/issues/show_bug.cgi?id=5570
thelastmamm...@gmail.com changed:
What|Removed |Added
CC||thelastmamm...@gmail.com
--- Comment #39 from thelastmamm...@gmail.com 2013-09-21 19:48:09 PDT ---
(In reply to comment #38)
I don't think the three byte struct issue (see linked bug) has been fixed yet,
but I haven't checked in a while.
has not been fixed. was going to submit a bug report until I saw this thread.
problem with:
struct VideoMode{
uint width;
uint height;
uint bitsPerPixel;
}
sfWindow* sfWindow_create(sfVideoMode mode, const(char)* title, uint style,
const(ContextSettings)* settings);
This is used in SFML-D https://github.com/krzat/SFML-D, making it unsable on
osx 64bit: the sample program crashes with auto screen = new
RenderWindow(VideoMode(800, 600), Game, WindowStyle.Default, null); which I
believe is caused by this.
This leads to a lot of duplication, for example the authors had to duplicate c
bindings just to address this:
https://github.com/Jebbs/DSFML-C where they point to this bug.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10027] demangled name format of local function is wrong
http://d.puremagic.com/issues/show_bug.cgi?id=10027 kekeni...@yahoo.co.jp changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from kekeni...@yahoo.co.jp 2013-09-21 20:12:22 PDT --- Fixed by Rainer. Copied the commit reports from Issue 10277. (this is 10027 :) ) Commit pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/9837043cfc75a37d4a79941cc5b401e19213088d Merge pull request #1592 from rainers/demangle_local fix issues 10277 6045:improve demangling for function local symbols Commit pushed to master at https://github.com/D-Programming-Language/druntime https://github.com/D-Programming-Language/druntime/commit/64ae912e8e89840a0ed14fc149c10fe6bfb8e169 Merge pull request #611 from rainers/demangle_local fix issues 10277 6045:improve demangling for function local symbols -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10425] Link error with templates
http://d.puremagic.com/issues/show_bug.cgi?id=10425 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull --- Comment #4 from Kenji Hara k.hara...@gmail.com 2013-09-21 21:39:47 PDT --- The link-failure could see also on Windows 64bit codegen (use -m64). dmd -m64 -c bug.d dmd -m64 test.d bug.obj Compiler fix: https://github.com/D-Programming-Language/dmd/pull/2582 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
