[Issue 10153] Beta releases should all have unique names
http://d.puremagic.com/issues/show_bug.cgi?id=10153 Jacob Carlborg changed: What|Removed |Added CC||d...@me.com --- Comment #1 from Jacob Carlborg 2013-05-23 23:41:46 PDT --- If we have a naming scheme looking like dmd. it will be automatically compatible with DVM :) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10148] regression 062=>063: unjustified 'safe function cannot call system function'
http://d.puremagic.com/issues/show_bug.cgi?id=10148 Kenji Hara changed: What|Removed |Added Keywords||pull --- Comment #1 from Kenji Hara 2013-05-23 22:54:59 PDT --- https://github.com/D-Programming-Language/dmd/pull/2072 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10144] Using enum inside final class occurs weird errors
http://d.puremagic.com/issues/show_bug.cgi?id=10144 Kenji Hara changed: What|Removed |Added Keywords||pull --- Comment #1 from Kenji Hara 2013-05-23 21:04:27 PDT --- https://github.com/D-Programming-Language/dmd/pull/2070 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10142] [REG2.063a] enum value semantic problem that declared in class member
http://d.puremagic.com/issues/show_bug.cgi?id=10142 Kenji Hara changed: What|Removed |Added Keywords||pull --- Comment #1 from Kenji Hara 2013-05-23 20:43:19 PDT --- https://github.com/D-Programming-Language/dmd/pull/2069 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10158] New: 'offsetof' property of nested struct does not work properly
http://d.puremagic.com/issues/show_bug.cgi?id=10158
Summary: 'offsetof' property of nested struct does not work
properly
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: rejects-valid
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: kekeni...@yahoo.co.jp
--- Comment #0 from kekeni...@yahoo.co.jp 2013-05-23 19:53:45 PDT ---
I tried to write inline assembly code,
but 'offsetof' of nested struct does not work properly.
Code:
class Outer {
static struct Inner {
int f;
}
// from member of Outer class
void test()
{
static assert( Inner.f.offsetof == 0); // NG
static assert( (Inner.f).offsetof == 0); // OK, but doesn't cooperate
with the inline assembler
// Here comes asm { ... }.
}
}
// cf. from non-member of Outer class
void main()
{
static assert( Outer.Inner.f.offsetof == 0); // OK
}
Output:
offsetof_bug.d(9): Error: this for f needs to be type Inner not type
offsetof_bug.Outer
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10147] Make -w identical to -wi and deprecate it
http://d.puremagic.com/issues/show_bug.cgi?id=10147
--- Comment #2 from Jonathan M Davis 2013-05-23 19:27:40
PDT ---
> Can you please be more specific, maybe with example code? I have no knowledge
> of any of this.
Okay. Let's say that you have a function like
auto foo(T)(T t)
{
switch(t.val)
{
case 1:
writeln("warnings");
case 2:
writeln("become");
case 3:
writeln("errors");
default:
break;
}
return t.ret;
}
Without -w, this code will compile just fine (assuming that T has a member
called val which works with a switch statement as well as a member called ret).
But with -w, it won't compile thanks to the fact that it uses implicit
fallthrough. Now, say you have a function like
auto bar(T)(T t)
if(is(typeof(foo(T.init
{
...
}
The template constraint passes if the argument compiles with foo and fails if
it doesn't. So, without -w, if you have the type
struct S
{
int val;
int ret;
}
and you pass it to bar, the code will compile. But if you compile with -w, it
won't, because foo no longer compiles thanks to implicit fallthrough becoming
an error.
_Anything_ that tests whether code compiles potentially breaks thanks to -w.
How big a problem this is in practice, I don't know, but -w can change the
semantics of code, meaning that whether you compile with -w or not effectively
creates two different languages. Normally, we reject any suggestions that
involve flags like this. -w really makes no sense.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10147] Make -w identical to -wi and deprecate it
http://d.puremagic.com/issues/show_bug.cgi?id=10147 Andrej Mitrovic changed: What|Removed |Added CC||andrej.mitrov...@gmail.com --- Comment #1 from Andrej Mitrovic 2013-05-23 19:12:16 PDT --- > -w is inherently broken, because it changes the semantics of code when static inference and conditional compilation and whatnot are involved. Can you please be more specific, maybe with example code? I have no knowledge of any of this.. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10141] wrong error message with Tuple!(int) : Error: static assert "Cannot put a char[] into a Appender!(string)"
http://d.puremagic.com/issues/show_bug.cgi?id=10141 Andrej Mitrovic changed: What|Removed |Added CC||andrej.mitrov...@gmail.com --- Comment #1 from Andrej Mitrovic 2013-05-23 19:14:33 PDT --- Looks like another case of http://d.puremagic.com/issues/show_bug.cgi?id=9549. That one was closed after it was fixed by accident: https://github.com/D-Programming-Language/dmd/pull/1676#issuecomment-14059594 Apparently it's resurfaced again in this new test-case. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9130] Wrong codegen for compile time constructed struct
http://d.puremagic.com/issues/show_bug.cgi?id=9130 Kenji Hara 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 10151] final: before enum is now an error.
http://d.puremagic.com/issues/show_bug.cgi?id=10151
--- Comment #2 from Kenji Hara 2013-05-23 18:22:00 PDT ---
(In reply to comment #0)
> final:
>
> enum Foo { Bar }
>
> Used to compile. Is an error in git master :
> Error: variable module.Bar final cannot be applied to variable, perhaps you
> meant const?
(In reply to comment #1)
> This does compile with 2.063 beta. Are you working off of the 2.063 branch?
The root cause would be same as bug 10144. @deadalnix, could you please give us
a complete test case which can reproduce the error?
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 9130] Wrong codegen for compile time constructed struct
http://d.puremagic.com/issues/show_bug.cgi?id=9130 --- Comment #9 from github-bugzi...@puremagic.com 2013-05-23 18:07:37 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/8265f070e11cb59c7390957abd2f1257290bfd61 fix Issue 9130 - Wrong codegen for compile time constructed struct https://github.com/D-Programming-Language/dmd/commit/bb9a2a95d6f204cbb88a54a239069d4ddf0f23b5 Merge pull request #2068 from WalterBright/fix9130 fix Issue 9130 - Wrong codegen for compile time constructed struct -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10157] New: Vector ops with different types
http://d.puremagic.com/issues/show_bug.cgi?id=10157
Summary: Vector ops with different types
Product: D
Version: D2
Platform: x86
OS/Version: Windows
Status: NEW
Severity: enhancement
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2013-05-23 15:34:00 PDT ---
Is code like this meant to work? It's useful code:
void main() {
int[2] data = [10, 20];
double[2] result;
result[] = data[] * 0.5;
}
DMD 2.063beta5 gives:
test.d(4): Error: incompatible types for ((data[]) * (0.5)): 'int[]' and
'double'
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10151] final: before enum is now an error.
http://d.puremagic.com/issues/show_bug.cgi?id=10151 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #1 from Walter Bright 2013-05-23 14:12:02 PDT --- This does compile with 2.063 beta. Are you working off of the 2.063 branch? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10156] New: Can't handle usage of TypeTuple argument in templated function
http://d.puremagic.com/issues/show_bug.cgi?id=10156
Summary: Can't handle usage of TypeTuple argument in templated
function
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: jcrapuchet...@gmail.com
--- Comment #0 from Jonathan Crapuchettes 2013-05-23
13:43:47 PDT ---
DMD says that it can't deduce template function argument types when the
function is defined with a TypeTuple argument and a variadic template argument.
Example:
---
import std.typetuple;
alias TestT = TypeTuple!(dchar, int);
void main()
{
test('b', 6, 'a', 54);
}
void test(T...)(const TestT v, const T values)
{
}
---
DMD 2.062 output:
test.d(7): Error: template test.test does not match any function template
declaration. Candidates are:
test.d(10):test.test(T...)(const TestT v, const T values)
test.d(7): Error: template test.test(T...)(const TestT v, const T values)
cannot deduce template function from argument types !()(char,int,char,int)
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10155] New: deprecated delete used in http://www.digitalmars.com/d/2.0/memory.html
http://d.puremagic.com/issues/show_bug.cgi?id=10155 Summary: deprecated delete used in http://www.digitalmars.com/d/2.0/memory.html Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: websites AssignedTo: nob...@puremagic.com ReportedBy: qas...@gmail.com --- Comment #0 from QAston 2013-05-23 13:36:28 PDT --- The guide in http://www.digitalmars.com/d/2.0/memory.html uses operator delete in several places. Usage of deprecated features in guidelines is confusing to newcomers. Parts of the article need to be rewritten to show current practices. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10154] New: Betas should be posted on dlang.org
http://d.puremagic.com/issues/show_bug.cgi?id=10154 Summary: Betas should be posted on dlang.org Product: D Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: websites AssignedTo: nob...@puremagic.com ReportedBy: jmdavisp...@gmx.com --- Comment #0 from Jonathan M Davis 2013-05-23 12:22:10 PDT --- This was brought up during the Q&A panel at DConf 2013, and I don't think that anyone's actualy created an issue for this yet, so I'm creating this one. As an effort to make the betas more visible (and therefore more fully tested), which should have a place on the download page for the current beta release (if there is one). And if we get to the point that we're doing nightly builds of the toolchain, we should post them on the downloads page as well. Obviously, they shouldn't be more prominent than the actual release, but putting them on the downloads page will help make them prominent enough to get properly tested. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10153] New: Beta releases should all have unique names
http://d.puremagic.com/issues/show_bug.cgi?id=10153 Summary: Beta releases should all have unique names Product: D Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: installer AssignedTo: nob...@puremagic.com ReportedBy: jmdavisp...@gmx.com --- Comment #0 from Jonathan M Davis 2013-05-23 12:18:45 PDT --- This has been brought up several times (including at dconf 2013), but nothing has happened with it yet, so I figured that I should create an enhancement request for it. Right now, all dmd beta releases have the same name. This makes it very difficult to determine where any particular beta zip file fits into the string of betas or even which release of the compiler the beta is for. They should all have unique names - something like dmd.2.063beta1.zip, dmd.2.063beta2.zip, dmd.2.064beta1.zip. The exact naming scheme isn't necessarily all that important, but it should have the name of the release that it's a beta for as well as a number indicating which beta it is in the string of betas for that release. Ideally, dmd itself would report that version as well so that it's clear which version of dmd you have installed. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9766] align(n) with n compile-time constant
http://d.puremagic.com/issues/show_bug.cgi?id=9766 bearophile_h...@eml.cc changed: What|Removed |Added CC||turkey...@gmail.com --- Comment #1 from bearophile_h...@eml.cc 2013-05-23 09:58:16 PDT --- *** Issue 10149 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 10149] align() expects integer literal
http://d.puremagic.com/issues/show_bug.cgi?id=10149 bearophile_h...@eml.cc changed: What|Removed |Added Status|NEW |RESOLVED CC||bearophile_h...@eml.cc Resolution||DUPLICATE --- Comment #2 from bearophile_h...@eml.cc 2013-05-23 09:58:15 PDT --- *** This issue has been marked as a duplicate of issue 9766 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10152] New: Refused uint array concat with compatible array literal
http://d.puremagic.com/issues/show_bug.cgi?id=10152
Summary: Refused uint array concat with compatible array
literal
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-05-23 09:57:11 PDT ---
This program shows a dis-uniformity that maybe should be removed:
void main() {
void main() {
uint[] a;
a ~= 0;// OK.
a ~= [0]; // OK.
a ~= [-1]; // OK(?)
auto b1 = a ~ 0; // OK.
auto b2 = a ~ [0]; // Error.
}
DMD 2.063beta5 gives:
test.d(7): Error: incompatible types for ((a) ~ ([0])): 'uint[]' and 'int[]'
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10149] align() expects integer literal
http://d.puremagic.com/issues/show_bug.cgi?id=10149
Max Samukha changed:
What|Removed |Added
CC||samu...@voliacable.com
--- Comment #1 from Max Samukha 2013-05-23 09:49:49
PDT ---
dmd has quite a few bugs like that. Your case should be easy to workaround with
a string mixin. Something like:
enum alignment = 16;
mixin("align(" ~ to!string(alignment) ~") int x;");
// or
mixin(format("align(%s) int x;", T.alignof));
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10151] New: final: before enum is now an error.
http://d.puremagic.com/issues/show_bug.cgi?id=10151
Summary: final: before enum is now an error.
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: regression
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: deadal...@gmail.com
--- Comment #0 from deadalnix 2013-05-23 09:42:30 PDT ---
final:
enum Foo { Bar }
Used to compile. Is an error in git master :
Error: variable module.Bar final cannot be applied to variable, perhaps you
meant const?
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10150] Prefix method 'this' qualifiers should be just ignored anytime
http://d.puremagic.com/issues/show_bug.cgi?id=10150 Kenji Hara changed: What|Removed |Added Keywords||pull --- Comment #1 from Kenji Hara 2013-05-23 08:01:02 PDT --- https://github.com/D-Programming-Language/dmd/pull/2071 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10150] New: Prefix method 'this' qualifiers should be just ignored anytime
http://d.puremagic.com/issues/show_bug.cgi?id=10150
Summary: Prefix method 'this' qualifiers should be just ignored
anytime
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: k.hara...@gmail.com
--- Comment #0 from Kenji Hara 2013-05-23 06:23:11 PDT ---
By fixing issue 9199, git head rejects all meaningless method qualifiers for
non-method functions.
class C1
{
const static void fc() {} // NG in both 2.062 and git head
immutable static void fi() {} // NG in both 2.062 and git head
sharedstatic void fs() {} // OK in 2.063 but NG in git head
inout static void fw() {} // OK in 2.063 but NG in git head
}
class C2
{
static void fc() const {} // NG in both 2.062 and git head
static void fi() immutable {} // NG in both 2.062 and git head
static void fs() shared{} // OK in 2.063 but NG in git head
static void fw() inout {} // OK in 2.063 but NG in git head
}
const void fc1() {} // NG in both 2.062 and git head
immutable void fi1() {} // NG in both 2.062 and git head
sharedvoid fs1() {} // OK in 2.063 but NG in git head
inout void fw1() {} // OK in 2.063 but NG in git head
void fc2() const {} // NG in both 2.062 and git head
void fi2() immutable {} // NG in both 2.062 and git head
void fs2() shared{} // OK in 2.063 but NG in git head
void fw2() inout {} // OK in 2.063 but NG in git head
---
But this behavior is restrictive and now breaking exist code. Dlanguage allows
to rewrite prefix storage class to label syntax and scope syntax.
const void foo() {} // previous
const: void foo() {} // label
const { void foo() {} } // scope
Making errors for the functions enclosed by attribute would be inconvenient.
So, I'd like to propose that:
1. Module level functions and class/struct scope static functions just ignore
prefix method 'this' qualifiers (const, immutable, shared, and inout).
2. But specifying them at postfix position should be rejected.
The rule is consistent and make writing code more handy.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10149] New: align() expects integer literal
http://d.puremagic.com/issues/show_bug.cgi?id=10149 Summary: align() expects integer literal Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: turkey...@gmail.com --- Comment #0 from Manu 2013-05-23 04:39:11 PDT --- This works fine: align(16) int x; This doesn't: enum alignment = 16; align(alignment) int x; Or any other expression for that matter. Can't do: align(T.alignof) int x; This makes some generic code impossible. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10148] New: regression 062=>063: unjustified 'safe function cannot call system function'
http://d.puremagic.com/issues/show_bug.cgi?id=10148
Summary: regression 062=>063: unjustified 'safe function cannot
call system function'
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: regression
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: thelastmamm...@gmail.com
--- Comment #0 from thelastmamm...@gmail.com 2013-05-23 04:27:26 PDT ---
2.062:
compile works
2.063(beta5):
compile error that doesn't make sense:
a.d(7): Error: safe function 'a.foo2!(int).foo2.A!(int).A.foo3!(int).foo3'
cannot call system function 'a.foo1'
a.d(16): Error: template instance a.foo2!(int).foo2.A!(int).A.foo3!(int) error
instantiating
a.d:
void foo1(){}
auto foo2(S)() {
struct A(S){
void foo3(T2)(){
foo1();
}
this(S a){
}
}
return A!int(0);
}
void main(){
foo2!int.foo3!int;
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10146] ref on return is ignored
http://d.puremagic.com/issues/show_bug.cgi?id=10146 --- Comment #4 from rswhi...@googlemail.com 2013-05-23 04:18:16 PDT --- That is absolute strange, but thanks for the explanation. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10145] "real" datatype on x64 doesn't accurately represent a floating point number
http://d.puremagic.com/issues/show_bug.cgi?id=10145 bearophile_h...@eml.cc changed: What|Removed |Added CC||bearophile_h...@eml.cc --- Comment #1 from bearophile_h...@eml.cc 2013-05-23 04:15:13 PDT --- I suggest to add a small test case that shows the problem. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10146] ref on return is ignored
http://d.puremagic.com/issues/show_bug.cgi?id=10146 --- Comment #3 from Maxim Fomin 2013-05-23 04:14:52 PDT --- (In reply to comment #2) > I expected that in this case opAssign is called, not the postblit, beause I > return by ref and assign then the ref to a new value. Actually no, because refness here does not matter. You return by ref, but get not a ref in the caller. You don't assign ref to a new value either. You have A a = Initializer; which calls copy constructor. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10146] ref on return is ignored
http://d.puremagic.com/issues/show_bug.cgi?id=10146
--- Comment #2 from rswhi...@googlemail.com 2013-05-23 04:08:43 PDT ---
I expected that in this case opAssign is called, not the postblit, beause I
return by ref and assign then the ref to a new value.
But if you change A to this:
[code]
struct A {
public:
int id;
this(int id) {
writeln("CTor ", id);
this.id = id;
}
this(this) {
writeln("Postblit ", this.id);
this.id *= 2;
}
void opAssign(ref const A a) {
writeln("opAssign L: ", a.id);
this.id = a.id;
}
void opAssign(const A a) {
writeln("opAssign R ", a.id);
memcpy(&this, &a, A.sizeof);
}
~this() {
writeln("DTor ", this.id);
}
}
[/code]
You see still the same output, no call of opAssign by 'getA':
CTor 42
opAssign R 42
DTor 42
Return A
Postblit 42
DTor 84
DTor 42
Or did I miss something important here?
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10146] ref on return is ignored
http://d.puremagic.com/issues/show_bug.cgi?id=10146 Maxim Fomin changed: What|Removed |Added Status|NEW |RESOLVED CC||ma...@maxim-fomin.ru Resolution||INVALID Severity|major |normal --- Comment #1 from Maxim Fomin 2013-05-23 04:03:04 PDT --- D does not have references like C++. Each time you assign return value to a struct variable, refness is wiped out. The only cases when returning by ref matter, is when returned value is also returned by caller by ref or casted to pointer. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10147] New: Make -w identical to -wi and deprecate it
http://d.puremagic.com/issues/show_bug.cgi?id=10147 Summary: Make -w identical to -wi and deprecate it Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: jmdavisp...@gmx.com --- Comment #0 from Jonathan M Davis 2013-05-23 03:54:53 PDT --- -w is inherently broken, because it changes the semantics of code when static inference and conditional compilation and whatnot are involved. -wi is by far the smarter approach, and I really don't think that -w should have existed in the first place. But given that we have it (and it predates -wi), removing it at this point would break a lot of projects. So, I propose that we simply make it so that -w does the same thing as -wi and deprecate it. It's at least _possible_ that some code will break due to the change in semantics, but it's that change in semantics that we want to eliminate, and for the most part, code breakage is unlikely (and arguably would be desirable given the semantics changes of using -w). So, with -w deprecated, projects can migrate to using -wi, which won't change their code's semantics, and we can possibly remove -w at some point in the future (or just remove it from the docs if we don't want to go the extra step of removing it). In any case, I think that we would be far better of with -w and that we should at least seriously consider getting rid of it, and making it the same as -wi seems like a good step in that direction to me. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10146] New: ref on return is ignored
http://d.puremagic.com/issues/show_bug.cgi?id=10146
Summary: ref on return is ignored
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: major
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: rswhi...@googlemail.com
--- Comment #0 from rswhi...@googlemail.com 2013-05-23 03:42:34 PDT ---
The 'ref' by 'getA' is ignored.
[code]
import std.stdio;
struct A {
public:
int id;
this(int id) {
writeln("CTor ", id);
this.id = id;
}
this(this) {
writeln("Postblit ", this.id);
this.id *= 2;
}
~this() {
writeln("DTor ", this.id);
}
}
class B {
private:
A _a;
public:
this() {
this._a = A(42);
}
ref A getA() {
writeln("Return A");
return this._a;
}
}
void main() {
B b = new B();
A a = b.getA();
}
[/code]
Expected Output:
CTor 42
DTor 0
Return A
DTor 42
Current Output:
CTor 42
DTor 0
Return A
Postblit 42
DTor 84
DTor 42
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10145] New: "real" datatype on x64 doesn't accurately represent a floating point number
http://d.puremagic.com/issues/show_bug.cgi?id=10145 Summary: "real" datatype on x64 doesn't accurately represent a floating point number Product: D Version: D2 Platform: x86_64 OS/Version: Windows Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: goober...@gmail.com --- Comment #0 from Ethan Watson 2013-05-23 03:30:56 PDT --- When converting float variables to and from real variables, the actual value gets munged up in to something indecipherable. real values converted to strings print out wrong values, and converting them back to floats keep garbage values about. I discovered this one when using std.json, which uses the real type to track floating point values rather than float/double. Currently working around it by making a copy of std.json, sticking it in another namespace, and replacing real with double. Tested with latest beta. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10144] New: Using enum inside final class occurs weird errors
http://d.puremagic.com/issues/show_bug.cgi?id=10144
Summary: Using enum inside final class occurs weird errors
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: rejects-valid
Severity: regression
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: k.hara...@gmail.com
--- Comment #0 from Kenji Hara 2013-05-23 03:00:38 PDT ---
Test casse:
final class TNFA(char_t)
{
enum Act { don } // line 15
const Act[] action_lookup1 = [ Act.don, ];
}
alias X = TNFA!char; // lien 18
output:
test.d(15): Error: variable test.TNFA!(char).TNFA.don final cannot be applied
to variable, perhaps you meant const?
test.d(18): Error: template instance test.TNFA!(char) error instantiating
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10143] New: Make -property do nothing in preparation for removal
http://d.puremagic.com/issues/show_bug.cgi?id=10143 Summary: Make -property do nothing in preparation for removal Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: jmdavisp...@gmx.com --- Comment #0 from Jonathan M Davis 2013-05-23 03:00:15 PDT --- It's pretty clear at this point that we are _not_ going to have strict property enforcement and that we are _not_ going to require that non-property functions be called with parens (which is what -property currently tries to enforce). So, there is no point in keeping -property around. It's trying to enforce something that we're definitely not going to do. So, I propose that as the first stage toward getting rid of it, we make it a no-op. That way, we can remove -property from Phobos and druntime and move towards getting rid of it entirely. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10142] New: [REG2.063a] enum value semantic problem that declared in class member
http://d.puremagic.com/issues/show_bug.cgi?id=10142
Summary: [REG2.063a] enum value semantic problem that declared
in class member
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: rejects-valid
Severity: regression
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: k.hara...@gmail.com
--- Comment #0 from Kenji Hara 2013-05-23 02:28:59 PDT ---
class File
{
enum Access : ubyte { Read = 0x01 }
enum Open : ubyte { Exists = 0 }
enum Share : ubyte { None = 0 }
enum Cache : ubyte { None = 0x00 }
struct Style
{
Access access;
Openopen;
Share share;
Cache cache;
}
enum Style ReadExisting = { Access.Read, Open.Exists };
this (const(char[]) path, Style style = ReadExisting) {} // line 99
}
output:
test.d(99): Error: cannot make expression out of initializer for ReadExisting
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10141] New: wrong error message with Tuple!(int) : Error: static assert "Cannot put a char[] into a Appender!(string)"
http://d.puremagic.com/issues/show_bug.cgi?id=10141
Summary: wrong error message with Tuple!(int) : Error: static
assert "Cannot put a char[] into a Appender!(string)"
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: regression
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: thelastmamm...@gmail.com
--- Comment #0 from thelastmamm...@gmail.com 2013-05-23 02:16:28 PDT ---
main.d:
import std.typecons;
import std.typecons:unexisting_symbol;
Tuple!(int) fun(){return Tuple!(int).init;}
dmd 2.062:
dmd main.d:
main.d:Error: module std.typecons import 'unexisting_symbol' not found
(which is correct)
dmd 2.063(beta5):
dmd main.d:
main.d: Error: module std.typecons import 'unexisting_symbol' not found
dmd2_063_beta5/osx/bin/../../src/phobos/std/range.d(611): Error: static assert
"Cannot put a char[] into a Appender!(string)"
dmd2_063_beta5/osx/bin/../../src/phobos/std/format.d(1433):instantiated
from here: put!(Appender!(string), char[])
dmd2_063_beta5osx/bin/../../src/phobos/std/format.d(1335):instantiated
from here: formatUnsigned!(Appender!(string), char)
dmd2_063_beta5/osx/bin/../../src/phobos/std/format.d(1309):instantiated
from here: formatIntegral!(Appender!(string), ulong, char)
dmd2_063_beta5/osx/bin/../../src/phobos/std/format.d(2950):... (3
instantiations, -v to show) ...
dmd2_063_beta5/osx/bin/../../src/phobos/std/typecons.d(326):
instantiated from here: format!(char, ulong, ulong)
main.d(3):instantiated from here: Tuple!(int)
(which is incorrect : the stuff after the 1st line doesnt' make sense)
I'm on osx if that matters.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 9130] Wrong codegen for compile time constructed struct
http://d.puremagic.com/issues/show_bug.cgi?id=9130 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #8 from Walter Bright 2013-05-23 02:12:59 PDT --- https://github.com/D-Programming-Language/dmd/pull/2068 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1001] print stack trace (in debug mode) when program die
http://d.puremagic.com/issues/show_bug.cgi?id=1001 Jameson changed: What|Removed |Added CC||beatgam...@gmail.com --- Comment #62 from Jameson 2013-05-23 01:34:51 PDT --- (In reply to comment #60) > 2) Getting line numbers on POSIX. > > I don't think this goal is easily directly reachable. The corresponding > library > (binutils) that parses DWARF debug information and extracts line numbers in > licensed under the GNU GPL, meaning that loading it dynamically and passing > around data structures is out of the question (see > http://www.gnu.org/licenses/gpl-faq.html#NFUseGPLPlugins). However, the D > distribution can include a small GPL-licensed program that can take an > exception stack trace as stdin, and convert it to include line number > information, similar to the addr2line utility. Would something like this work? http://sourceforge.net/apps/trac/elftoolchain/ It's being developed for FreeBSD, so it's likely to work there and on Linux. I don't know of the progress, but it seems to be slated for the FreeBSD 10 release: https://wiki.freebsd.org/GPLinBase -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10135] core.bitop: btc, btr, btc is "pure" but have side effects
http://d.puremagic.com/issues/show_bug.cgi?id=10135 Alex R�nne Petersen changed: What|Removed |Added Status|NEW |RESOLVED CC||a...@lycus.org Resolution||INVALID --- Comment #2 from Alex R�nne Petersen 2013-05-23 10:16:55 CEST --- Yes, they are pure per the D definition. Even if a function mutates the memory pointed to by a pointer given to the function, it is still pure because that pointer is considered an input. See: http://klickverbot.at/blog/2012/05/purity-in-d/ -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10135] core.bitop: btc, btr, btc is "pure" but have side effects
http://d.puremagic.com/issues/show_bug.cgi?id=10135 --- Comment #1 from Don 2013-05-23 01:13:40 PDT --- > core.bitop: btc, btr, btc is "pure" but have side effects What do you mean? They don't modify any globals. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10106] [ICE] Ice in glue.c:1215 + 2 error messages without lines
http://d.puremagic.com/issues/show_bug.cgi?id=10106 --- Comment #9 from github-bugzi...@puremagic.com 2013-05-23 00:58:30 PDT --- Commit pushed to 2.063 at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/9298d34981d5a828e29050432cfb87c026cbb2be Merge pull request #2067 from 9rnsr/fix10106 [test only] Issue 10106 - [ICE] Ice in glue.c:1215 + 2 error messages without lines -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10134] Mutual referencing templates error
http://d.puremagic.com/issues/show_bug.cgi?id=10134 Walter Bright changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10134] Mutual referencing templates error
http://d.puremagic.com/issues/show_bug.cgi?id=10134 --- Comment #3 from github-bugzi...@puremagic.com 2013-05-23 00:56:52 PDT --- Commit pushed to 2.063 at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/a0292c10efb67931e208e0736f626ad5ef3fe531 Merge pull request #2062 from 9rnsr/fix10134 [2.063a] Issue 10134 - Mutual referencing templates error -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10134] Mutual referencing templates error
http://d.puremagic.com/issues/show_bug.cgi?id=10134 --- Comment #2 from github-bugzi...@puremagic.com 2013-05-23 00:54:52 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/a60e757ba69e890881480b98a6dba5456832f55f fix Issue 10134 - Mutual referencing templates error https://github.com/D-Programming-Language/dmd/commit/9edb35f64c700eca65be718aa057cdc344896836 Merge pull request #2062 from 9rnsr/fix10134 [2.063a] Issue 10134 - Mutual referencing templates error -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10140] confusing error message: X is private; undefined identifier Y, did you mean X
http://d.puremagic.com/issues/show_bug.cgi?id=10140
--- Comment #1 from thelastmamm...@gmail.com 2013-05-23 00:35:33 PDT ---
(In reply to comment #0)
>
> import std.regex;
> void main(){
> auto c=match(s,``);
> }
>
>
> Error: module bug std.regex.IR is private
> bug.d(3): Error: undefined identifier s, did you mean enum IR?
Just to clarify, the bug is that the error message shouldn't even say 'Error:
module bug std.regex.IR is private' (which is very confusing). It should just
say:
Error: undefined identifier s, did you mean enum IR?
The second weird thing is that 's' is far from 'IR'; shouldn't it either
specify other symbols or put a cap on levinstein distance?
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10140] New: confusing error message: X is private; undefined identifier Y, did you mean X
http://d.puremagic.com/issues/show_bug.cgi?id=10140
Summary: confusing error message: X is private; undefined
identifier Y, did you mean X
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: thelastmamm...@gmail.com
--- Comment #0 from thelastmamm...@gmail.com 2013-05-23 00:33:10 PDT ---
import std.regex;
void main(){
auto c=match(s,``);
}
Error: module bug std.regex.IR is private
bug.d(3): Error: undefined identifier s, did you mean enum IR?
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10106] [ICE] Ice in glue.c:1215 + 2 error messages without lines
http://d.puremagic.com/issues/show_bug.cgi?id=10106 Kenji Hara 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 10106] [ICE] Ice in glue.c:1215 + 2 error messages without lines
http://d.puremagic.com/issues/show_bug.cgi?id=10106 --- Comment #8 from github-bugzi...@puremagic.com 2013-05-23 00:22:40 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/4d42bf6d5c8545959b1a87b40815b6a9e3fdfe5a fix Issue 10106 - [ICE] Ice in glue.c:1215 + 2 error messages without lines https://github.com/D-Programming-Language/dmd/commit/3e61f34dd63b01c7e70918fe1262c606c2445bc5 Merge pull request #2067 from 9rnsr/fix10106 [test only] Issue 10106 - [ICE] Ice in glue.c:1215 + 2 error messages without lines -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5500] Appender.put causes an invariant violation in struct with overloaded opAssign
http://d.puremagic.com/issues/show_bug.cgi?id=5500 Jameson changed: What|Removed |Added CC||beatgam...@gmail.com --- Comment #6 from Jameson 2013-05-23 00:05:43 PDT --- I can't reproduce this: DMD 2.062 LDC2 (based on 2.061) Arch Linux x86_64 Can anyone else reproduce this? This bug is quite old... -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4600] writeln() is not thread-safe
http://d.puremagic.com/issues/show_bug.cgi?id=4600
Jameson changed:
What|Removed |Added
CC||beatgam...@gmail.com
--- Comment #1 from Jameson 2013-05-22 23:59:00 PDT ---
(In reply to comment #0)
> Okay. Maybe I misunderstood something somewhere, but as I understand it,
> writeln() is supposed to be thread-safe. Multiple threads can interleave lines
> that they're printing, but each line that a thread prints with writeln() is
> supposed to be completely printed before a line from another thread can be
> printed. However, at least some of the time, the output from one thread is
> mixed with another on the same line. For instance, take this program:
>
> import std.concurrency;
> import std.stdio;
>
> void main(string[] args)
> {
> spawn(&func1, thisTid, args.idup);
> spawn(&func2, thisTid, args.idup);
> writeln("main() 1");
> writeln("main() 2");
> writeln("main() 3");
> }
>
> void func1(Tid parentTid, immutable string[] args)
> {
> writefln("func1() begin");
> writefln("func1(): %s", args);
> writefln("func1() end");
> }
>
> void func2(Tid parentTid, immutable string[] args)
> {
> writefln("func2() begin");
> writefln("func2(): %s", args);
> writefln("func2() end");
> }
I couldn't reproduce this with the current DMD. This issue is quite old, so
it's possibly invalid now.
I'm running Linux x86_64 with DMD 2.062. Also tried ldc2 (targeting DMD 2.061),
no problems.
Can this be closed?
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
