[Issue 9035] Nested struct `init` is lvalue and can be modified
http://d.puremagic.com/issues/show_bug.cgi?id=9035 --- Comment #3 from github-bugzi...@puremagic.com 2012-12-03 22:01:08 PST --- Commit pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/acf8a8934dff6b9cdfcc4d5f98b9b5c242b11ebd fixup for pull #1301 and #1309 By fixing bug 9069 and 9035, T.init always returns rvalue and ref cannot receive it. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9069] struct literals are treated as lvalues
http://d.puremagic.com/issues/show_bug.cgi?id=9069 --- Comment #8 from github-bugzi...@puremagic.com 2012-12-03 22:01:02 PST --- Commit pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/acf8a8934dff6b9cdfcc4d5f98b9b5c242b11ebd fixup for pull #1301 and #1309 By fixing bug 9069 and 9035, T.init always returns rvalue and ref cannot receive it. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8408] Purity calculation should be improved
http://d.puremagic.com/issues/show_bug.cgi?id=8408 --- Comment #5 from github-bugzi...@puremagic.com 2012-12-03 22:00:20 PST --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/41c52a324d0526a079039041c64afc1d3983eb58 fix Issue 8408 - Purity calculation should be improved https://github.com/D-Programming-Language/dmd/commit/b6a809346a43c7fbf350bd4181d350dd9b2cd4e6 Merge pull request #1110 from 9rnsr/fix8408 Issue 8408 - Purity calculation should be improved -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9069] struct literals are treated as lvalues
http://d.puremagic.com/issues/show_bug.cgi?id=9069 --- Comment #7 from github-bugzi...@puremagic.com 2012-12-03 21:52:44 PST --- Commit pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/afed048033d976482739945f9ca4e8ca14271264 fixup for pull #1301 and #1309 By fixing bug 9069 and 9035, T.init always returns rvalue and ref cannot receive it. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9035] Nested struct `init` is lvalue and can be modified
http://d.puremagic.com/issues/show_bug.cgi?id=9035 --- Comment #2 from github-bugzi...@puremagic.com 2012-12-03 20:58:34 PST --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/a5514dd6ed97646abe3d0f32631d22ef42f58f99 fix Issue 9035 - Nested struct `init` is lvalue and can be modified https://github.com/D-Programming-Language/dmd/commit/3b061322300c5b7a39f1b5c5f76016a4d9906899 Merge pull request #1301 from 9rnsr/fix9035 Issue 9035 & 9036 - Nested struct `init` is lvalue and can be modified -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9036] postblit is called for nested structs when assigning `init`
http://d.puremagic.com/issues/show_bug.cgi?id=9036 --- Comment #3 from github-bugzi...@puremagic.com 2012-12-03 20:58:29 PST --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/6861282d3877f504c4b9e586917d0333e8b1c5f4 fix Issue 9036 - postblit is called for nested structs when assigning `init` https://github.com/D-Programming-Language/dmd/commit/3b061322300c5b7a39f1b5c5f76016a4d9906899 Merge pull request #1301 from 9rnsr/fix9035 Issue 9035 & 9036 - Nested struct `init` is lvalue and can be modified -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9112] New: Uniform default construction
http://d.puremagic.com/issues/show_bug.cgi?id=9112 Summary: Uniform default construction 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 2012-12-03 20:06:08 PST --- Related: http://d.puremagic.com/issues/show_bug.cgi?id=8752 Built-in .init property is useful, but it is sometimes unsafe, and many people might confuse the default initializer and construction. - Default initializer represents pre-constructing object state. Users can access to it by using built-in `.init` property. - Default construction is a default operation which constructing an object completely. * For built-in types (int, double, pointers, arrays) and class types, default construction does nothing. Because, after initializing by default initializer, the object is already completely constructed. * For struct types, it is same in basic. After initialized by S.init, the object is completely constructed. Except: + If S is a nested struct, default construction should fill its frame pointer. So default construction is valid only in the function where S is defined. + If S is a struct which has `@disable this();`, default construction is disabled explicitly. So default construction is never occur. Instead, users should call explicitly defined user-defined constructor which has arguments. Well, for struct types, default construction has an explicit syntax S(). But, built-in types does not have that. It is inconsistent. So I'd like to propose new syntax to reduce such concept confusion. int n = int();// same as int.init int n = int(10); // same as cast(int)10; >From the meta-programming view, we can represent default construction of value types by T(). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8819] void static array should have init built-in propert
http://d.puremagic.com/issues/show_bug.cgi?id=8819
--- Comment #3 from Kenji Hara 2012-12-03 19:32:30 PST ---
(In reply to comment #2)
> I'm not convinced this is a good idea. void[] is supposed to be untyped data,
> and a 0 initializer is specific to some types, and not for others.
In almost cases, void[] and void[n] are used to represent *bare* memory.
Then, 0-initialized bare memory is enough acceptable concept to me.
---
The enhancement only I argue is just to add init property. That means, default
construction of void[n] should be kept invalid.
void main() {
void[1] vsa1 = (void[1]).init; // allowed by this enhancement
void[1] vsa2; // default construction should still be error
}
I think void[n] should behave as like a struct has `@disable this();`.
All structs have built-in `.init`. Therefore void[n] should also have `.init`.
---
>From a view of meta-programming, I think that all types which has run-time
representation should have .init property. It is consistent and much useful.
Example:
template isSomeCheck(T) {
enum isSomeCheck = is(typeof({
T t = T.init; // Can ignore T's constructing way.
func(t); // check whether func accepts an lvalue object typed T
func(T.init); // check whether func accepts an rvalue object typed T
}
}
After taking this enhancement, only one type which doesn't have init property
is void.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8819] void static array should have init built-in propert
http://d.puremagic.com/issues/show_bug.cgi?id=8819 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #2 from Walter Bright 2012-12-03 18:07:49 PST --- I'm not convinced this is a good idea. void[] is supposed to be untyped data, and a 0 initializer is specific to some types, and not for others. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9070] nothrow of constructer/destructor isn't correct
http://d.puremagic.com/issues/show_bug.cgi?id=9070 --- Comment #2 from github-bugzi...@puremagic.com 2012-12-03 18:09:48 PST --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/cff6404b990fe5d0a88cfc3a2abba86d5139a36e fix Issue 9070 - nothrow of constructer/destructor isn't correct https://github.com/D-Programming-Language/dmd/commit/f9fe4a8a4fa9f25a5f33007c455e0be6a758a1bb Merge pull request #1317 from 9rnsr/fix9070 Issue 9070 - nothrow of constructer/destructor isn't correct -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9076] Aliased template function and property resolution doesn't work
http://d.puremagic.com/issues/show_bug.cgi?id=9076 --- Comment #2 from github-bugzi...@puremagic.com 2012-12-03 18:00:37 PST --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/b295355275a046e789344458763534c104b23224 fix Issue 9076 - Aliased template function and property resolution doesn't work https://github.com/D-Programming-Language/dmd/commit/ac6734d3639615a92b1926d20ad720a8c819e288 Merge pull request #1326 from 9rnsr/fix9076 Issue 9076 - Aliased template function and property resolution doesn't work -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9077] Struct copy constructor ignored when opAssign with a different type is present
http://d.puremagic.com/issues/show_bug.cgi?id=9077 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 9069] struct literals are treated as lvalues
http://d.puremagic.com/issues/show_bug.cgi?id=9069 --- Comment #6 from github-bugzi...@puremagic.com 2012-12-03 17:24:28 PST --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/5fb1348103930045604835ac40bb3a84106c7bf0 fix Issue 9069 - struct literals are treated as lvalues https://github.com/D-Programming-Language/dmd/commit/5b8827f3db5affdd4534cf131492fd92c6e10269 Merge pull request #1319 from 9rnsr/fix9069 Issue 9069 - struct literals are treated as lvalues -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9109] Regression: 2.053: Lazy Variadic Functions do not work with delegates
http://d.puremagic.com/issues/show_bug.cgi?id=9109 Kenji Hara changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Kenji Hara 2012-12-03 16:03:29 PST --- https://github.com/D-Programming-Language/dmd/commit/0a08e9556b0e327191cd3fdb5c9c19d4ac1101a8 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9077] Struct copy constructor ignored when opAssign with a different type is present
http://d.puremagic.com/issues/show_bug.cgi?id=9077 --- Comment #2 from github-bugzi...@puremagic.com 2012-12-03 15:42:02 PST --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/00ba398dd1d7bb5f06b2b380dc113ba32b3afff8 fix Issue 9077 - Struct copy constructor ignored when opAssign with a different type is present https://github.com/D-Programming-Language/dmd/commit/6b31d6c0d12ffacb007bb75f74a26ac3081d4b1c Merge pull request #1345 from 9rnsr/fix9077 Issue 9077 - Struct copy constructor ignored when opAssign with a different type is present -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9092] GC.extend allocates less then it reports
http://d.puremagic.com/issues/show_bug.cgi?id=9092 --- Comment #5 from Rainer Schuetze 2012-12-03 15:07:31 PST --- (In reply to comment #4) > 1. What exactly are inside those 16 bytes? I'd say something along the lines > of > pointer to destructor, and currently used vs capacity? Currently only the number of entries that are actually used in the memory block are stored. This allows to append in place if a slice ends at the end of the used data in the block. It is 16 bytes in case any struct needs that alignment. > 2. Why is this issue *only* showing up when my allocation sizes are exact > multiples of 0x1 ? The problem happens at page boundaries (4kB), but the "commit" size of GC pools is 64kB, so pages are mapped into memory at that granularity. So you'll probably corrupt memory earlier, but the page fault is likely to happen at 64kB boundaries. > 3. Would it be possible to somehow have extend detect when it is given an > "array allocated pointer"? In that case, it could either refuse to extend, or > assert, or something? I don't think it is GC.extend's job to do this. Although slightly less efficient, I think appender should get the new capacity via capacity(array) instead of calculating it from the return value of GC.extent. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9106] Rename std.random.randomShuffle as std.random.shuffle
http://d.puremagic.com/issues/show_bug.cgi?id=9106 monarchdo...@gmail.com changed: What|Removed |Added CC||monarchdo...@gmail.com --- Comment #2 from monarchdo...@gmail.com 2012-12-03 13:56:02 PST --- (In reply to comment #1) > Due to the issues regarding random number generator ranges being value types > instead of reference types, there's a decent chance that we're going to end up > with a std.random2 in the semi-near future. It would make sense to make this > sort of change when we do that. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9092] GC.extend allocates less then it reports
http://d.puremagic.com/issues/show_bug.cgi?id=9092 --- Comment #4 from monarchdo...@gmail.com 2012-12-03 13:49:53 PST --- (In reply to comment #3) > You expect different stuff from GC.extend than its author... Ok, I think I get it. This leads to 3 questions (if you'd care to educate me): 1. What exactly are inside those 16 bytes? I'd say something along the lines of pointer to destructor, and currently used vs capacity? 2. Why is this issue *only* showing up when my allocation sizes are exact multiples of 0x1 ? 3. Would it be possible to somehow have extend detect when it is given an "array allocated pointer"? In that case, it could either refuse to extend, or assert, or something? I was currently looking into appender, so I'll try to fix it in such a way as to not have this problem anymore. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9077] Struct copy constructor ignored when opAssign with a different type is present
http://d.puremagic.com/issues/show_bug.cgi?id=9077 Kenji Hara changed: What|Removed |Added Keywords||pull --- Comment #1 from Kenji Hara 2012-12-03 05:54:26 PST --- https://github.com/D-Programming-Language/dmd/pull/1345 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7602] [CTFE] Segmentation fault when using array.keys on a null AA
http://d.puremagic.com/issues/show_bug.cgi?id=7602 Don changed: What|Removed |Added CC||ellery-newco...@utulsa.edu --- Comment #5 from Don 2012-12-03 03:58:01 PST --- *** Issue 8568 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 8568] compile time access of associative array keys results in segfault
http://d.puremagic.com/issues/show_bug.cgi?id=8568 Don changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #2 from Don 2012-12-03 03:58:01 PST --- This is fixed by my patch to bug 7602 (it's not a pure duplicate, but has the same root cause). *** This issue has been marked as a duplicate of issue 7602 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9111] Parent object getting GCed before the elements of child dynamic array
http://d.puremagic.com/issues/show_bug.cgi?id=9111 Maxim Fomin changed: What|Removed |Added Status|NEW |RESOLVED CC||ma...@maxim-fomin.ru Resolution||INVALID --- Comment #1 from Maxim Fomin 2012-12-03 02:43:56 PST --- Not a bug http://forum.dlang.org/thread/mailman.2438.1354423511.5162.digitalmar...@puremagic.com -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9111] New: Parent object getting GCed before the elements of child dynamic array
http://d.puremagic.com/issues/show_bug.cgi?id=9111
Summary: Parent object getting GCed before the elements of
child dynamic array
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: regression
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: pun...@coverify.org
--- Comment #0 from Puneet Goel 2012-12-03 00:51:58 PST
---
The following code segfaults when compiled with current DMD github snapshot. It
seems that array elements of "frop" are getting garbage collected after the
parent class Foo's object is collected.
Works fine with dmd-2.059 and dmd-2.060.
class Frop {
bar _v;
}
struct bar {
static Foo _root;
~this() {
_root.del();
}
}
class Foo {
int _x;
Frop[] _frop;
this() {
bar._root = this;
_frop = [new Frop()];
}
void del() {}
}
void main() {
auto foo = new Foo ;
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 9109] Regression: 2.053: Lazy Variadic Functions do not work with delegates
http://d.puremagic.com/issues/show_bug.cgi?id=9109 Kenji Hara changed: What|Removed |Added Keywords||pull, rejects-valid --- Comment #1 from Kenji Hara 2012-12-03 00:34:42 PST --- https://github.com/D-Programming-Language/dmd/pull/1344 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
