[Issue 7730] Make imports work case-sensitive on all platforms
http://d.puremagic.com/issues/show_bug.cgi?id=7730 Jacob Carlborg d...@me.com changed: What|Removed |Added CC||d...@me.com --- Comment #3 from Jacob Carlborg d...@me.com 2012-03-19 00:14:24 PDT --- (In reply to comment #1) This is an interesting idea, but I think there are also other alternatives. Like requiring enforcing all module names to be fully lower-case. That would completely break Tango. I don't like the idea. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7366] IFTI fails to consider bounds-checked implicit conversions for non-deduced parameter types
http://d.puremagic.com/issues/show_bug.cgi?id=7366
timon.g...@gmx.ch changed:
What|Removed |Added
Summary|template overload |IFTI fails to consider
|resolution failure |bounds-checked implicit
||conversions for non-deduced
||parameter types
--- Comment #1 from timon.g...@gmx.ch 2012-03-19 02:44:53 PDT ---
Simpler test case:
void foo()(byte k){}
void main(){foo(2);}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7366] IFTI fails to consider bounds-checked implicit conversions for non-deduced parameter types
http://d.puremagic.com/issues/show_bug.cgi?id=7366 Don clugd...@yahoo.com.au changed: What|Removed |Added CC||clugd...@yahoo.com.au --- Comment #2 from Don clugd...@yahoo.com.au 2012-03-19 03:09:39 PDT --- Looks like a duplicate of regression bug 4953. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7730] Make imports work case-sensitive on all platforms
http://d.puremagic.com/issues/show_bug.cgi?id=7730 --- Comment #4 from Armin Kazmi armin.ka...@tu-dortmund.de 2012-03-19 03:41:27 PDT --- (In reply to comment #3) (In reply to comment #1) This is an interesting idea, but I think there are also other alternatives. Like requiring enforcing all module names to be fully lower-case. That would completely break Tango. I don't like the idea. I wouldn't really exaggerate that. Actually using a find/sed expression thats quite easy to fix. What I simply want is to have it consistent import/module-lookup behavior across all platforms to save all that mess one already has in C/C++ with it. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7726] 'virtual' keyword please
http://d.puremagic.com/issues/show_bug.cgi?id=7726
--- Comment #2 from Manu turkey...@gmail.com 2012-03-19 04:09:50 PDT ---
Then I can't use private:, since that suffers from the same problem of not
having a corresponding 'public'.
{
[public virtual methods]
private:
[data members]
final:
[non-virtual methods] // are now private
}
{
[public virtual methods]
final:
[non-virtual methods]
private:
[data members] // error because of the 'final:' bug
}
This all leads to messy, and rather difficult to follow classes. I like to keep
associated stuff together.
I also really like the virtual keyword, it states in the API clearly how to
extend the class, and you can grep for it.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7726] 'virtual' keyword please
http://d.puremagic.com/issues/show_bug.cgi?id=7726
--- Comment #3 from Piotr Szturmaj psztur...@tlen.pl 2012-03-19 05:08:26 PDT
---
You can tag individual members with public/private and final. final: and final
{ } are just for convenience.
You can also try something like this:
{
void virtualMethod() {}
private:
int privateMember;
public final:
void finalMethod() { } // public
}
I guess you are opting for virtual: keyword to just disable existing final:
specifier. There are other possible solutions without adding a new keyword:
- Use default: to restore public and virtual.
- Use negation, like !final: to disable specifiers that differ from public and
virtual.
But I'm ok with current approach.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7730] Make imports work case-sensitive on all platforms
http://d.puremagic.com/issues/show_bug.cgi?id=7730 Stewart Gordon s...@iname.com changed: What|Removed |Added CC||s...@iname.com --- Comment #5 from Stewart Gordon s...@iname.com 2012-03-19 05:13:27 PDT --- The problem at the moment is that the capitalisation of a module's name, in the absence of a module declaration, depends on the name by which it is referenced. Try this at home: - modulecap_a.d - import modulecap_b; - ModuleCap_b.d - int x = .y; -- C:\Users\Stewart\Documents\Programming\D\Testsdmd modulecap_b.d modulecap_b.d(1): Error: undefined identifier module modulecap_b.y C:\Users\Stewart\Documents\Programming\D\Testsdmd ModuleCap_b.d ModuleCap_b.d(1): Error: undefined identifier module ModuleCap_b.y C:\Users\Stewart\Documents\Programming\D\Testsdmd modulecap_a.d modulecap_b.d(1): Error: undefined identifier module modulecap_b.y -- I can imagine this leading to havoc if the same module is referenced from different modules by different capitalisations of the name. If there's a module declaration, go with that. Otherwise, go with the actual capitalisation of the filename, thereby ensuring platform-consistent behaviour. That said, are there any 32+-bit platforms on which filenames aren't case-retentive? -- 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 --- Comment #3 from Don clugd...@yahoo.com.au 2012-03-19 05:25:40 PDT --- (In reply to comment #2) OK, this is a very serious bug. Something is BADLY broken with CTFE: struct AssociativeArray [snip] That test case is unrelated to the original bug. Please open a new bug report, changing the severity of both bugs if required. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7730] Make imports work case-sensitive on all platforms
http://d.puremagic.com/issues/show_bug.cgi?id=7730 --- Comment #6 from Armin Kazmi armin.ka...@tu-dortmund.de 2012-03-19 05:28:29 PDT --- The problem at the moment is that the capitalisation of a module's name, in the absence of a module declaration, depends on the name by which it is referenced. Try this at home: - modulecap_a.d - import modulecap_b; - ModuleCap_b.d - int x = .y; -- C:\Users\Stewart\Documents\Programming\D\Testsdmd modulecap_b.d modulecap_b.d(1): Error: undefined identifier module modulecap_b.y C:\Users\Stewart\Documents\Programming\D\Testsdmd ModuleCap_b.d ModuleCap_b.d(1): Error: undefined identifier module ModuleCap_b.y C:\Users\Stewart\Documents\Programming\D\Testsdmd modulecap_a.d modulecap_b.d(1): Error: undefined identifier module modulecap_b.y -- I'm not really that much into the internals of dmd, but in the given case, dmd could fail to import ModuleCap_b by simply comparing it with the import case modulecap_b and also output a warning that one should check the case. Also, for the same reason, all arguments passed into dmd which refer to files, should also work case-sensitive (just to make it easier to have makefiles, buildscripts work correctly across platforms). I can imagine this leading to havoc if the same module is referenced from different modules by different capitalisations of the name. If there's a module declaration, go with that. Otherwise, go with the actual capitalisation of the filename, thereby ensuring platform-consistent behaviour. I know how to prevent that issue. You're pretty much forced to prevent it when using linux. But seeing a lot of C/C++ code in windows, windows developers simply ignore the problem altogether. Also, I think, that such trivial code should really work exactly in the same way to the file level across all platforms. It's not hard to implement it and would completely eliminate such issues before they start becoming popular. I really wondered why that wasn't a design decision from day one. (BTW: similar arguments are valid for int vs size_t) That said, are there any 32+-bit platforms on which filenames aren't case-retentive? I don't know -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7731] New: Assertion failure: 't' on line 7911 in file 'mtype.c'
http://d.puremagic.com/issues/show_bug.cgi?id=7731
Summary: Assertion failure: 't' on line 7911 in file 'mtype.c'
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: dmitry.o...@gmail.com
--- Comment #0 from Dmitry Olshansky dmitry.o...@gmail.com 2012-03-19
06:27:50 PDT ---
That's the exact output of dmd 2.059head, on win 7:
Assertion failure: 't' on line 7911 in file 'mtype.c'
abnormal program termination
//code
struct A{
int a;
}
template Inherit(alias X)
{
X __super;
alias __super this;
}
struct B{
mixin Inherit!A;
int b;
}
struct PolyPtr(X)
{
X* _payload;
static if(is(typeof(X.init.__super)))
{
alias typeof(X.init.__super) Super;
@property auto getSuper(){ return PolyPtr!Super(_payload.__super); }
alias getSuper this;
}
//alias _payload this;//multiple alias this, sigh
auto opDispatch(string s)(){ return mixin(_payload.~s); }
}
template create(X)
{
PolyPtr!X create(X, T...)(T args){
return PolyPtr!X(args);
}
}
void f1(PolyPtr!A a) {/*...*/}
void f2(PolyPtr!B b) {f1(b);/*...*/}
void main(){
auto b = create!B();
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7726] 'virtual' keyword please
http://d.puremagic.com/issues/show_bug.cgi?id=7726
--- Comment #5 from Manu turkey...@gmail.com 2012-03-19 06:33:04 PDT ---
*crap, I tapped tab and the 'commit' button gained focus, and when I pressed
space bar, it posted.*
class MyClass
{
final:
this();
@property void property1(int t)
@property int property1()
@property void thing(int t)
@property int thing()
void doThing()
void addUnrelated(Unrelated x);
Unrelated getUnrelated();
virtual void updateUnrelateds();
// etc.
private:
virtual void update();
virtual void draw();
void handlerDelegate();
void handlerDelegate2();
int data1;
float data2;
...
}
Ie. logically group stuff, mark the occasional virtual explicitly, continue as
final.
This looks like a fairly realistic class to me. I really want to be able to
explicitly mark each function that is virtual in this way.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7726] 'virtual' keyword please
http://d.puremagic.com/issues/show_bug.cgi?id=7726
--- Comment #6 from Piotr Szturmaj psztur...@tlen.pl 2012-03-19 07:00:07 PDT
---
You can write it like this:
class MyClass
{
final {
this();
@property void property1(int t)
@property int property1()
@property void thing(int t)
@property int thing()
void doThing()
void addUnrelated(Unrelated x);
Unrelated getUnrelated();
}
void updateUnrelateds();
// etc.
private:
void update();
void draw();
final {
void handlerDelegate();
void handlerDelegate2();
}
int data1;
float data2;
...
}
IMHO it makes no sense to introduce virtual keyword since virtual in D is the
default...
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7732] New: CTFE bug causes if(ptr !is null) to pass when ptr==null
http://d.puremagic.com/issues/show_bug.cgi?id=7732
Summary: CTFE bug causes if(ptr !is null) to pass when
ptr==null
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: critical
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: hst...@quickfur.ath.cx
--- Comment #0 from hst...@quickfur.ath.cx 2012-03-19 07:55:54 PDT ---
Something is BADLY broken with CTFE:
struct AssociativeArray
{
int *impl;
int f()
{
if (impl !is null)
auto x = *impl; // this is line 7
return 1;
}
}
void main() {
int test()
{
AssociativeArray aa;
return aa.f;
}
enum str = test();
}
This is not a fully minimized test case, but I've tried my best to reduce it as
much as possible. With the latest dmd from git, this gives:
test.d(7): Error: dereference of invalid pointer 'AssociativeArray(null)'
test.d(15):called from here: aa.f()
test.d(17):called from here: test()
This is a VERY serious bug because apparently the condition (impl !is null)
actually passes, even though impl is null!
This appears to be related to the current AssociativeArray magic (renaming the
struct in the above code makes the bug go away).
--
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 hst...@quickfur.ath.cx changed: What|Removed |Added Severity|critical|normal --- Comment #4 from hst...@quickfur.ath.cx 2012-03-19 07:57:25 PDT --- OK, opened new issue bug 7732. Downgrading this bug back to original severity. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7722] Refuse normal functions to be used as properties
http://d.puremagic.com/issues/show_bug.cgi?id=7722 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull Platform|x86 |All Version|unspecified |D2 OS/Version|Windows |All --- Comment #1 from Kenji Hara k.hara...@gmail.com 2012-03-19 07:58:56 PDT --- https://github.com/D-Programming-Language/dmd/pull/817 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4953] Regression(2.031): templates don't do implicit conversion properly
http://d.puremagic.com/issues/show_bug.cgi?id=4953
hst...@quickfur.ath.cx changed:
What|Removed |Added
CC||hst...@quickfur.ath.cx
--- Comment #11 from hst...@quickfur.ath.cx 2012-03-19 08:04:35 PDT ---
Another data point:
void f(dstring d) { dstring e = d; }
f(abc); // OK
void f()(dstring d) { dstring e = d; }
f(abc); // OK
void f(byte[] b) { byte[] c = b; }
f([1,2,3]); // OK
void f()(byte[] b) { byte[] c = b; }
f([1,2,3]);
// Error: template test2.f() does not match any function template declaration
// Error: template test2.f() cannot deduce template function from argument
types !()(int[])
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5233] [patch] std.range.put accepts *any* element type when putting to an array.
http://d.puremagic.com/issues/show_bug.cgi?id=5233 --- Comment #9 from Rob Jacques sandf...@jhu.edu 2012-03-19 09:56:04 PDT --- (In reply to comment #8) I think the patch has diverged from the intended charter of put, as mentioned in the pull request. I am misunderstanding something. In the pull request, you mentioned that The intent of put(r, e) is to provide a universal generic interface for putting stuff into stuff using a unified syntax. As such, adding policies and options works against that charter. We're better off defining independent functions such as putArray etc. However, put already contains policies for handling arrays, ranges, delegates, etc. All I've attempted to do, on that front, is to add all the variations (i.e. edge cases) on those concepts, so that generic code functions correctly. The other feature I've added is some external control of those policies, a feature which is a interim measure until UFC is working. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7726] 'virtual' keyword please
http://d.puremagic.com/issues/show_bug.cgi?id=7726 --- Comment #7 from Manu turkey...@gmail.com 2012-03-19 10:02:13 PDT --- Yeah, I'll do that in the mean time, but it's not a 'solution'. I still can't grep for virtual (important). And it's really ugly; breaks indentation policy, separates things in and out of braces. D is meant to be cleaner and tidier than C++. Certainly not messier. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7734] New: Wrong comparison of float return value from opEquals
http://d.puremagic.com/issues/show_bug.cgi?id=7734
Summary: Wrong comparison of float return value from opEquals
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: simen.kja...@gmail.com
--- Comment #0 from Simen Kjaeraas simen.kja...@gmail.com 2012-03-19 10:57:24
PDT ---
struct Foo {
float opEquals(int other) {
return 0.0;
}
}
void main( ) {
assert( Foo() != 3 );
}
The above code generates this assembly:
fldz
fucompp
fnstsw ax
sahf
je D main+25h
mov eax,0Ah
callmain@__assert
It seems to assume that FPU status flags will be all 0 when the return value is
0.0, which is simply not true - the C3 flag is 1 when the return value is 0.0.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7733] New: [tdpl] opIndexUnary not called with postfix increment/decrement operators
http://d.puremagic.com/issues/show_bug.cgi?id=7733
Summary: [tdpl] opIndexUnary not called with postfix
increment/decrement operators
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: hst...@quickfur.ath.cx
--- Comment #0 from hst...@quickfur.ath.cx 2012-03-19 10:56:39 PDT ---
struct S {
int[] data;
void opIndex(size_t i) { return data[i]; }
void opIndexUnary(string op)(size_t i) {
return mixin(op ~ data[i]);
}
}
void main() {
S s;
s.data = [1,2,3];
++s[0]; // OK
s[0]++; // Error: s.opIndex(1u) is not an lvalue
}
This contradicts the specs, that specify that x++ is translated to ++x, which
should cause opIndexUnary!++ to be called, not opIndex.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7250] [UFCS] UFCS chaining doesn't work
http://d.puremagic.com/issues/show_bug.cgi?id=7250 Brad Anderson e...@gnuk.net changed: What|Removed |Added CC||e...@gnuk.net --- Comment #1 from Brad Anderson e...@gnuk.net 2012-03-19 11:19:17 PDT --- I've tested and this works fine in 2.059 HEAD as of today. It should be closed (I'm not sure of the protocol who closes issues or I'd just close it myself). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6438] [CTFE] wrong error value used before set when slicing =void array
http://d.puremagic.com/issues/show_bug.cgi?id=6438 --- Comment #3 from github-bugzi...@puremagic.com 2012-03-19 11:26:46 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/f152b09d8f59a4981bff924802bebaccb926f948 Fix issue 6438 - [CTFE] wrong error value used before set when slicing =void array Take advantage of the new VoidExp. https://github.com/D-Programming-Language/dmd/commit/b71836bbc5e83af949484401e6f97346e7d66a2d Merge pull request #816 from donc/voidctfe6438 Fix issue 6438 - [CTFE] wrong error value used before set with = void -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6438] [CTFE] wrong error value used before set when slicing =void array
http://d.puremagic.com/issues/show_bug.cgi?id=6438 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 7250] [UFCS] UFCS chaining doesn't work
http://d.puremagic.com/issues/show_bug.cgi?id=7250 bearophile_h...@eml.cc changed: What|Removed |Added Status|NEW |RESOLVED CC||bearophile_h...@eml.cc Resolution||FIXED --- Comment #2 from bearophile_h...@eml.cc 2012-03-19 11:56:55 PDT --- This is now working. It's currently working even too much well (see Bug 7722 that already has a patch). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 611] IsExpression fails when inside implemented interface
http://d.puremagic.com/issues/show_bug.cgi?id=611
Tim Shea tim.m.s...@gmail.com changed:
What|Removed |Added
CC||tim.m.s...@gmail.com
--- Comment #2 from Tim Shea tim.m.s...@gmail.com 2012-03-19 12:10:45 PDT ---
Please correct me if I'm wrong, but this does not seem incorrect to me. In
fact, if the static assert compiles and passes outside the interface, I would
think that would be an issue. After all:
interface MyInterface(T) {
static assert(is(T : MyInterface));
}
MyInterface(int) a;
Should compile to :
interface MyInterface(Int) {
static assert(is(int : MyInterface(int));
}
This seems self evidently false to me. An integer does not convert to a
MyInterface(int), nor should it. Regardless of where the static assert is, I
would think it should fail.
I guess if you have something like:
interface Cloneable(T) {
T clone();
}
then it makes sense to say:
class CloneableObject : Cloneable(CloneableObject) {...}
but I don't think it follows that a Cloneable(CloneableObject) should be
convertible back to a plain CloneableObject.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7215] array.Appender.put should work on its own type
http://d.puremagic.com/issues/show_bug.cgi?id=7215 Rob Jacques sandf...@jhu.edu changed: What|Removed |Added CC||sandf...@jhu.edu --- Comment #1 from Rob Jacques sandf...@jhu.edu 2012-03-19 14:02:08 PDT --- https://github.com/D-Programming-Language/phobos/pull/502 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5813] [patch] std.array.Appender has severe performance and memory leak problems.
http://d.puremagic.com/issues/show_bug.cgi?id=5813 --- Comment #19 from Rob Jacques sandf...@jhu.edu 2012-03-19 14:02:01 PDT --- https://github.com/D-Programming-Language/phobos/pull/502 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4287] opOpAssign!(~=) for std.array.Appender
http://d.puremagic.com/issues/show_bug.cgi?id=4287 Rob Jacques sandf...@jhu.edu changed: What|Removed |Added CC||sandf...@jhu.edu --- Comment #4 from Rob Jacques sandf...@jhu.edu 2012-03-19 14:02:41 PDT --- https://github.com/D-Programming-Language/phobos/pull/502 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6641] RefAppender!(T[]) should be OutputRange.
http://d.puremagic.com/issues/show_bug.cgi?id=6641 Rob Jacques sandf...@jhu.edu changed: What|Removed |Added CC||sandf...@jhu.edu --- Comment #3 from Rob Jacques sandf...@jhu.edu 2012-03-19 14:02:29 PDT --- https://github.com/D-Programming-Language/phobos/pull/502 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7735] New: Functions with variadic void[][]... arguments corrupts passed data
http://d.puremagic.com/issues/show_bug.cgi?id=7735
Summary: Functions with variadic void[][]... arguments corrupts
passed data
Product: D
Version: D2
Platform: x86
OS/Version: Windows
Status: NEW
Severity: major
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: psztur...@tlen.pl
--- Comment #0 from Piotr Szturmaj psztur...@tlen.pl 2012-03-19 14:53:41 PDT
---
This program:
import std.stdio;
void a(void[][] data...)
{
writeln(data);
b(data);
}
void b(void[][] data...)
{
writeln(data);
c(data);
}
void c(void[][] data...)
{
writeln(data);
}
void main()
{
a([]);
a([]);
}
Prints:
[[]]
[[0, 0, 0, 0, 0, 0, 0, 0]]
[[8, 0, 0, 0, 88, 254, 19, 0]]
[[]]
[[0, 0, 0, 0, 0, 0, 0, 0]]
[[8, 0, 0, 0, 104, 254, 19, 0]]
Please note the difference between two a() calls. Also, data written from
within c() looks like array layout - 8 byte length and a pointer.
Tested with 2.059head and 32-bit Windows XP.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5813] [patch] std.array.Appender has severe performance and memory leak problems.
http://d.puremagic.com/issues/show_bug.cgi?id=5813 bearophile_h...@eml.cc changed: What|Removed |Added CC||bearophile_h...@eml.cc --- Comment #20 from bearophile_h...@eml.cc 2012-03-19 15:13:08 PDT --- (In reply to comment #19) https://github.com/D-Programming-Language/phobos/pull/502 Algorithmically, Appender is implemented using a sealed rope, a linked-list of arrays, with the first node being cached in a thread local free list. Was a linked-list of arrays better/faster than a dynamic array of pointers to equal-sized memory blocks (decks data structure)? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7736] New: opApply for immutable structs too
http://d.puremagic.com/issues/show_bug.cgi?id=7736
Summary: opApply for immutable structs too
Product: D
Version: D2
Platform: x86
OS/Version: Windows
Status: NEW
Keywords: rejects-valid
Severity: regression
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2012-03-19 16:29:47 PDT ---
This code used to work not too much time ago (maybe 2.056?):
immutable struct Foo {
char stop;
int opApply(int delegate(ref int) dg) {
int result;
for (int i = 0; i stop; i++) {
result = dg(i);
if (result) break;
}
return result;
}
}
void main() {
foreach (i; Foo(10)) {}
}
DMD 2.059 gives:
test.d(13): Error: cannot uniquely infer foreach argument types
The code compiles and works if you remove the immutable and replace it with
const:
const struct Foo {
char stop;
int opApply(int delegate(ref int) dg) {
int result;
for (int i = 0; i stop; i++) {
result = dg(i);
if (result) break;
}
return result;
}
}
void main() {
foreach (i; Foo(10)) {}
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7737] New: std.typecons.Typedef problem with immutable initialized in static this()
http://d.puremagic.com/issues/show_bug.cgi?id=7737
Summary: std.typecons.Typedef problem with immutable
initialized in static this()
Product: D
Version: D2
Platform: x86
OS/Version: Windows
Status: NEW
Keywords: rejects-valid
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2012-03-19 17:22:46 PDT ---
I don't know if it's possible to fix this just changing Phobos. Maybe more is
needed.
Tests performed with DMD 2.059head:
This compiles:
alias int[] Arr;
immutable Arr a;
pure nothrow static this() {
a = [1, 2, 3];
}
void main() {}
This compiles (with -d):
typedef int[] Arr;
immutable Arr a;
pure nothrow static this() {
a = [1, 2, 3];
}
void main() {}
This compiles:
import std.typecons: Typedef;
alias Typedef!(int[]) Arr;
Arr a;
nothrow static this() {
a = [1, 2, 3];
}
void main() {}
But this doesn't compile:
import std.typecons: Typedef;
alias Typedef!(int[]) Arr;
immutable Arr a;
pure nothrow static this() {
a = [1, 2, 3];
}
void main() {}
It gives:
test.d(5): Error: template
std.typecons.Typedef!(int[],null).Typedef.Proxy!(Typedef_payload).opAssign(this
X,V) does not match any function template declaration
test.d(5): Error: template
std.typecons.Typedef!(int[],null).Typedef.Proxy!(Typedef_payload).opAssign(this
X,V) cannot deduce template function from argument types !()(int[])
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7738] New: Can't iterate a std.typecons.Typedef!(int[]) with foreach
http://d.puremagic.com/issues/show_bug.cgi?id=7738
Summary: Can't iterate a std.typecons.Typedef!(int[]) with
foreach
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: rejects-valid
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2012-03-19 17:33:07 PDT ---
This compiles in DMD 2.059head:
alias int[] MyArray;
void main() {
MyArray arr;
foreach (i, item; arr) {}
}
This doesn't compile:
import std.typecons: Typedef;
alias Typedef!(int[]) MyArray;
void main() {
MyArray arr;
foreach (i, item; arr) {}
}
DMD 2.059head gives the error:
test.d(5): Error: invalid foreach aggregate arr
This simpler code gives the same error:
import std.typecons: Typedef;
alias Typedef!(int[]) MyArray;
void main() {
MyArray arr;
foreach (item; arr) {}
}
My main use cases for typedef are with arrays. So this problem makes
std.typecons.Typedef not much useful.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7722] Refuse normal functions to be used as properties
http://d.puremagic.com/issues/show_bug.cgi?id=7722
--- Comment #2 from Kenji Hara k.hara...@gmail.com 2012-03-19 17:46:06 PDT ---
Enforce all @property attribute for property usage (with -property switch) is
good, but one problem is in there.
From:
https://github.com/D-Programming-Language/dmd/pull/817#issuecomment-4580804
https://github.com/D-Programming-Language/dmd/pull/817#issuecomment-4586905
With UFCS, a property setting e1.prop = ev is rewritten to .prop(e1, ev).
If the compiler disallows a property function with two arguments, we cannot
set @property attribute to .prop function, but -property switch enforce to
.prop that has @property. After all, we can never use such a syntax.
@property void prop(int, int){}
// Error: properties can only have zero or one parameter
void main(){ 1.prop = 10; }
The alternate way is to stop property enforcement for the UFCS setter that
needs two arguments.
/*@property */void prop(int, int){}
void main(){ 1.prop = 10; } // not detected attribute missing with -property
Currently, my pull in comment#1 allows a property function that has two
arguments.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7739] New: regex fails to accept \p in expression of unicode properties
http://d.puremagic.com/issues/show_bug.cgi?id=7739
Summary: regex fails to accept \p in expression of unicode
properties
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: j...@prismnet.com
--- Comment #0 from Jay Norwood j...@prismnet.com 2012-03-19 19:47:00 PDT ---
dmd 2.058
win7-64
void wcp (string fn)
{
enum ctr = ctRegex!(\p{WhiteSpace},m);
}
-- Build started: Project: a7, Configuration: Release Win32
--
Building Release\a7.exe...
a7.d(210): undefined escape sequence \p
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7740] New: unicodeProperties cannot be read at compile time for ctRegex
http://d.puremagic.com/issues/show_bug.cgi?id=7740
Summary: unicodeProperties cannot be read at compile time for
ctRegex
Product: D
Version: D2
Platform: x86
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: j...@prismnet.com
--- Comment #0 from Jay Norwood j...@prismnet.com 2012-03-19 19:52:49 PDT ---
this is on win7 2.058 d2
void wcp_bug_no_p(string fn)
{
enum ctr = ctRegex!(r\p{WhiteSpace},m);
}
-- Build started: Project: a7, Configuration: Debug Win32
--
Building Debug\a7.exe...
G:\d\dmd2\windows\bin\..\..\src\phobos\std\regex.d(786): Error:
static variable unicodeProperties cannot be read at compile time
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7442] ctRegex!`\p{Letter}` uses a lot memory in compilation
http://d.puremagic.com/issues/show_bug.cgi?id=7442
Jay Norwood j...@prismnet.com changed:
What|Removed |Added
CC||j...@prismnet.com
--- Comment #1 from Jay Norwood j...@prismnet.com 2012-03-19 20:11:58 PDT ---
I see probably a related issue when compiling either of these expressions in
win7
void wcpx(string fn)
{
enum ctr = ctRegex!(r\w+,g);
}
void wcpx(string fn)
{
enum ctr = regex(r\w+,g);
}
-- Build started: Project: a7, Configuration: Release Win32 --
Building Release\a7.exe...
Error: out of memory
Building Release\a7.exe failed!
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6253] Refuse definition too of impossible associative arrays
http://d.puremagic.com/issues/show_bug.cgi?id=6253 hst...@quickfur.ath.cx changed: What|Removed |Added CC||hst...@quickfur.ath.cx --- Comment #5 from hst...@quickfur.ath.cx 2012-03-19 20:45:56 PDT --- Does (In reply to comment #4) AA keys don't have to be immutable, they just have to be a type that implicitly converts to immutable. This is the same requirement for parameters of strongly pure functions. Does this mean AA keys should be stored as immutable internally? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7722] Refuse normal functions to be used as properties
http://d.puremagic.com/issues/show_bug.cgi?id=7722 --- Comment #3 from github-bugzi...@puremagic.com 2012-03-19 21:57:24 PDT --- Commit pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/a57a29cf4a3631154c29e64c9377418893b36698 Merge pull request #817 from 9rnsr/fix_ufcs Issue 7722 - Refuse normal functions to be used as properties -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7722] Refuse normal functions to be used as properties
http://d.puremagic.com/issues/show_bug.cgi?id=7722 --- Comment #4 from github-bugzi...@puremagic.com 2012-03-19 22:04:32 PDT --- Commit pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/cc28ed074548ed6e8f5cf0d2f2a422b41ff51581 Revert fix Issue 7722 - Refuse normal functions to be used as properties This reverts commit ddd8f3456207ed4b94fb36fde9538e37eac36687. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7493] Initialization of void[][N]
http://d.puremagic.com/issues/show_bug.cgi?id=7493 Don clugd...@yahoo.com.au changed: What|Removed |Added CC||clugd...@yahoo.com.au Version|D1 |D1 D2 --- Comment #2 from Don clugd...@yahoo.com.au 2012-03-19 22:24:25 PDT --- Also applies to D2. The problem is that there are two possible interpretations: void[] x = [str]; typeof(x)[1] = x; void[] y = str; typeof(y)[1] = [ y ]; I think this should be an error. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7722] Refuse normal functions to be used as properties
http://d.puremagic.com/issues/show_bug.cgi?id=7722 --- Comment #5 from github-bugzi...@puremagic.com 2012-03-19 22:25:33 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/e1d932a56c80ea8d5f4adad85df648c71314f187 fix Issue 7722 - Refuse normal functions to be used as properties https://github.com/D-Programming-Language/dmd/commit/55e2a21b43a585cc3175542c0a89c17785631773 Revert fix Issue 7722 - Refuse normal functions to be used as properties This reverts commit ddd8f3456207ed4b94fb36fde9538e37eac36687. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7736] Regression(2.059 beta): opApply for immutable structs too
http://d.puremagic.com/issues/show_bug.cgi?id=7736 Don clugd...@yahoo.com.au changed: What|Removed |Added CC||clugd...@yahoo.com.au Summary|opApply for immutable |Regression(2.059 beta): |structs too |opApply for immutable ||structs too --- Comment #1 from Don clugd...@yahoo.com.au 2012-03-19 22:42:26 PDT --- Worked in 2.058. This bug hasn't appeared in an official release. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6253] Refuse definition too of impossible associative arrays
http://d.puremagic.com/issues/show_bug.cgi?id=6253 --- Comment #6 from yebblies yebbl...@gmail.com 2012-03-20 16:48:54 EST --- (In reply to comment #5) Does (In reply to comment #4) AA keys don't have to be immutable, they just have to be a type that implicitly converts to immutable. This is the same requirement for parameters of strongly pure functions. Does this mean AA keys should be stored as immutable internally? I'd say yes, tail-immutable. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
