[Issue 7432] DMD allows variables to be declared as pure
http://d.puremagic.com/issues/show_bug.cgi?id=7432
--- Comment #16 from Jonathan M Davis jmdavisp...@gmx.com 2013-08-18 22:59:59
PDT ---
Perhaps allow to apply storage classes to variables in block declarations like
attribute: or attribute { } and ban them in single variable declarations?
That's basically what I was thinking (though I would want to apply that to all
symbols, not just variables). At the moment, I can't think of why that would be
a problem (though someone may be able to come up with a reason why it would
be).
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7432] DMD allows variables to be declared as pure
http://d.puremagic.com/issues/show_bug.cgi?id=7432 --- Comment #17 from Stewart Gordon s...@iname.com 2013-08-18 23:05:47 PDT --- (In reply to comment #13) You're talking about what the compiler actually does, which is a different matter from what the spec indicates it should do. Honestly, it really doesn't matter what the spec says. In general, if there's a disagreement between the spec and the compiler, the spec loses. What you're basically saying here is that the language is _defined_ by the compiler, and consequently the compiler has no bugs. So what is the meaning of the word spec in your mind? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6791] std.algorithm.splitter random indexes utf strings
http://d.puremagic.com/issues/show_bug.cgi?id=6791 monarchdo...@gmail.com changed: What|Removed |Added CC||monarchdo...@gmail.com AssignedTo|nob...@puremagic.com|monarchdo...@gmail.com --- Comment #2 from monarchdo...@gmail.com 2013-08-18 23:25:05 PDT --- (In reply to comment #1) This is caused by struct SplitterResult in std.algorithm using array slicing and array indexing to pass char (not dchar!) to the lambda. SplitterResult appears to have multiple issues: it uses array slicing without a proper signature constraint on hasSlicing, and doesn't work properly for narrow strings because it uses indexing which for narrow strings doesn't handle multibyte UTF-8 sequences properly. It appears to be wanting a rewrite that uses only forward range primitives, or at least, an overload for narrow strings that properly take multibyte characters into account. I had submitted a correction for this about 1 year ago, but it ended up being too big in scope (*all* splitter flavors have bugs). It also ended up being messy due to (trying to avoid) code duplication. It might be better to just fix things little by little though, rather than not at all. I'll fix *just* splitter!pred: It's the easiest to fix. We'll see where we go from there. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7432] DMD allows variables to be declared as pure
http://d.puremagic.com/issues/show_bug.cgi?id=7432 --- Comment #18 from Jonathan M Davis jmdavisp...@gmx.com 2013-08-18 23:30:45 PDT --- What you're basically saying here is that the language is _defined_ by the compiler, and consequently the compiler has no bugs. No, I'm not saying that the compiler has no bugs. If there is a disagreement between the spec, the compiler, or TDPL, then it has to be discussed which is correct, but in general, TDPL wins, then the compiler, and then the spec. Yes, the spec _should_ define what the language is, but it's not that precise or that complete, and the language is still under enough development that the spec has to change from time to time even if it's compeletely correct, and the reality of the matter is that the spec is often incorrect if nothing else because it frequently doesn't get updated properly when language design decisions are made, whereas the compiler almost always does get updated. It's not like the spec was written, and then a compiler was written to match it. The language has evolved over time, and on the whole, the compiler has defined what the language is, and Walter has defined what the language is supposed to be when questions come up. The spec attempts to define what the language is based on that, but it doesn't always manage it, primarily because it isn't maintained well enough. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10847] uninitializedArray accepts arguments which make it fail internally
http://d.puremagic.com/issues/show_bug.cgi?id=10847
monarchdo...@gmail.com changed:
What|Removed |Added
CC||monarchdo...@gmail.com
--- Comment #1 from monarchdo...@gmail.com 2013-08-18 23:32:20 PDT ---
(In reply to comment #0)
-
import std.array;
void main()
{
ubyte[] source = uninitializedArray!(ubyte[])(ulong.init);
}
-
$ dmd test.d
C:\DMD\dmd2\windows\bin\..\..\src\phobos\std\array.d(321): Error: function
core.memory.GC.malloc (uint sz, uint ba = 0u) is not callable using argument
types (ulong, BlkAttr)
C:\DMD\dmd2\windows\bin\..\..\src\phobos\std\array.d(272): Error: template
instance std.array.arrayAllocImpl!(false, ubyte[], ulong) error instantiating
test.d(7):instantiated from here: uninitializedArray!(ubyte[], ulong)
test.d(7): Error: template instance std.array.uninitializedArray!(ubyte[],
ulong) error instantiating
The constraint should disallow the argument instead of failing inside of
Phobos
when instantiating other templates.
This was specifically fixed in my Rewrite [Un|Minimally]InitializedArray.
https://github.com/D-Programming-Language/phobos/pull/1447
Specifically, it will static assert with the message:
Argument types in (ulong) are not all convertible to size_t: (ulong)
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10848] Compiler should always try to inlining a direct lambda call
http://d.puremagic.com/issues/show_bug.cgi?id=10848 Manu turkey...@gmail.com changed: What|Removed |Added CC||turkey...@gmail.com --- Comment #1 from Manu turkey...@gmail.com 2013-08-18 23:51:35 PDT --- Sounds like a good case for a __forceinline attribute, and then apply it implicitly in this case. This situation could leverage the same internal mechanic. I still have MANY places where I want to guarantee inlining of certain functions. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10844] Importing package as module fails with nested packages
http://d.puremagic.com/issues/show_bug.cgi?id=10844 --- Comment #2 from Robik szad...@gmail.com 2013-08-19 01:56:46 PDT --- (In reply to comment #1) Which OS + compiler version (and commit if git-head) are you using? I can't recreate this with a5c9b9ae4c25aea71153f162ed7026f561061e28 on win32. I'm using DMD 2.063.2 on win32. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10729] Some exception symbols undefined
http://d.puremagic.com/issues/show_bug.cgi?id=10729 --- Comment #13 from Andre Tampubolon an...@lc.vlsm.org 2013-08-19 02:27:29 PDT --- (In reply to comment #12) One way to test the issue is to compile dmd, druntime, phobos and hello object file in problematic environment and attach them here to test in working environments. If hello program is linkable and runnable in others environments, then problem is with your setup. I decided to wipe out dmd, druntime, and phobos directories and rebuild them. While building phobos, I got this: Error: cannot find source code for runtime library file 'object.d' dmd might not be correctly installed. Run 'dmd -man' for installation instructions. Specify path to file 'object.d' with -I switch I could find both object.di and object_.d in druntime directory, but not object.d -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10763] (x)[0 .. 1] doesn't work in CTFE
http://d.puremagic.com/issues/show_bug.cgi?id=10763 --- Comment #5 from Don clugd...@yahoo.com.au 2013-08-19 02:37:33 PDT --- (In reply to comment #4) (In reply to comment #3) It's basically the same as issue 10266. Issue 10266 additionally requests allowing reinterpret-casts between T* and T[1]* (my implementation currently rejects this, but allowing it would be easy.) The corner cases arise if you still disallow x + 1. My guess is that you're allowing it in your implementation? ... Yes, but dereferencing it is an error. Subtracting one results in the address of x. That is not the issue. The problem is that in C, simply creating the pointer is undefined behaviour. No dereferencing is involved. Note that is undefined behaviour, it's not even implementation-specific behaviour! Simply storing an invalid pointer into a pointer register may generate a hardware exception on some systems. In C, you are not permitted to do pointer arithmetic unless the pointer points to an array, or one-past-the-end-of-an-array. The problem with allowing it is that we're departing from C. Does C actually disallow adding 0 to a pointer to a local variable? That's what the example is doing. I'm not sure if that's legal or not. I suspect not, though I think it would always work in practice. But adding 1 to a pointer to a local variable is definitely illegal, and there are systems where it will not work. So the end of the slice is problematic. Is there really a use case for this unsafe behaviour? Make more code CTFE-able. But it's undefined behaviour. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10729] Some exception symbols undefined
http://d.puremagic.com/issues/show_bug.cgi?id=10729 --- Comment #14 from Maxim Fomin ma...@maxim-fomin.ru 2013-08-19 02:40:21 PDT --- (In reply to comment #13) (In reply to comment #12) One way to test the issue is to compile dmd, druntime, phobos and hello object file in problematic environment and attach them here to test in working environments. If hello program is linkable and runnable in others environments, then problem is with your setup. I decided to wipe out dmd, druntime, and phobos directories and rebuild them. While building phobos, I got this: Error: cannot find source code for runtime library file 'object.d' dmd might not be correctly installed. Run 'dmd -man' for installation instructions. It seems that you indeed linked to old druntime. Specify path to file 'object.d' with -I switch I could find both object.di and object_.d in druntime directory, but not object.d It should be object_.d. You haven't setup path to druntime correctly. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10850] New: Inout substituted incorrectly for delegates in inout function signature
http://d.puremagic.com/issues/show_bug.cgi?id=10850
Summary: Inout substituted incorrectly for delegates in inout
function signature
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: timon.g...@gmx.ch
--- Comment #0 from timon.g...@gmx.ch 2013-08-19 02:49:22 PDT ---
git head:
Since apparently inout now refers to the outermost inout function, inout should
also be substituted for delegates inside the function signature:
inout(int)* delegate(inout(int)*) foo(ref inout(int) x){
inout(int)* bar(inout(int)*) { return x; }
return bar;
}
immutable(int) x;
static assert(is(typeof(foo(x))==immutable(int)* delegate(immutable(int)*)));
(Also note that none of the recent language updates towards type safe inout
checking were documented.)
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10844] Importing package as module fails with nested packages
http://d.puremagic.com/issues/show_bug.cgi?id=10844 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #3 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-08-19 02:51:49 PDT --- (In reply to comment #2) (In reply to comment #1) Which OS + compiler version (and commit if git-head) are you using? I can't recreate this with a5c9b9ae4c25aea71153f162ed7026f561061e28 on win32. I'm using DMD 2.063.2 on win32. Package modules were introduced in git-head, not in 2.063. You'll either have to use git-head or wait for the 2.064 release. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10850] Inout substituted incorrectly for delegates/fptrs in inout function signature
http://d.puremagic.com/issues/show_bug.cgi?id=10850
timon.g...@gmx.ch changed:
What|Removed |Added
Summary|Inout substituted |Inout substituted
|incorrectly for delegates |incorrectly for
|in inout function signature |delegates/fptrs in inout
||function signature
--- Comment #1 from timon.g...@gmx.ch 2013-08-19 02:57:40 PDT ---
Other test case:
inout(int)* foo(inout(int)* a, inout(int)* delegate(inout(int)*) dg){
return dg(a);
}
inout(int)* bar(inout(int)* a, inout(int)* delegate(inout(int)*) dg){
auto x = dg(a);
int* y;
dg(y);
return x;
}
void main(){
immutable int a;
assert(foo(a,x=x) is a); // error
static assert(is(typeof(foo(a,x=x))==immutable(int)*)); // error
assert(foo(a,(immutable(int)* x)=x) is a); // error
}
This should compile.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10758] Unsound type checking for inout.
http://d.puremagic.com/issues/show_bug.cgi?id=10758
timon.g...@gmx.ch changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED |
--- Comment #3 from timon.g...@gmx.ch 2013-08-19 03:06:54 PDT ---
The patch misses to take into consideration inout member functions. Eg. the
following function still manages to unsafely coerce its argument to mutable:
int* foo(inout(int)* x)@safe{
struct S{ inout(int)* screwUp()inout{ return x; } }
return S().screwUp();
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10851] New: Stack trace missing for null object access in module constructor
http://d.puremagic.com/issues/show_bug.cgi?id=10851
Summary: Stack trace missing for null object access in module
constructor
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: andrej.mitrov...@gmail.com
--- Comment #0 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-08-19
03:09:24 PDT ---
-
shared static this()
{
class C
{
void foo() { }
}
C c;
c.foo();
}
void main()
{
}
-
$ dmd -g -run test.d
object.Error: Access Violation
When using the same code in main, a proper stack trace is returned:
-
module test;
void main()
{
class C
{
void foo() { }
}
C c;
c.foo();
}
-
object.Error: Access Violation
0x0040201B in _Dmain at C:\dev\code\d_code\stack_trace_working.d(11)
0x004028E4 in extern (C) int rt.dmain2._d_run_main(int, char**, extern (C) int
function(char[][])*).v
oid runMain()
0x00402974 in extern (C) int rt.dmain2._d_run_main(int, char**, extern (C) int
function(char[][])*).v
oid runAll()
0x00402251 in _d_run_main
0x00402074 in main
0x004141AD in mainCRTStartup
0x766C33CA in BaseThreadInitThunk
0x77C19ED2 in RtlInitializeExceptionChain
0x77C19EA5 in RtlInitializeExceptionChain
Tested on Win 7 64bit.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10852] New: function wrongly inferred pure in embeded function with function cast
http://d.puremagic.com/issues/show_bug.cgi?id=10852
Summary: function wrongly inferred pure in embeded function
with function cast
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: monarchdo...@gmail.com
--- Comment #0 from monarchdo...@gmail.com 2013-08-19 03:27:21 PDT ---
Given:
1. A template function
2. An embedded function
3. A function cast inside the embedded function
Given the above pre-requirements, the embedded function will (wrongly) see the
cast function as pure, and be wrongly inferred:
//
//Impure function. Doesn't throw; not marked as such.
void impureFun()
{}
void nothrowFun()() nothrow
{
void fun () nothrow
{
alias nothrow void function() StillImpure_t;
(cast(StillImpure_t)impureFun)();
};
fun();
}
void main() pure
{
nothrowFun(); //PASSES! (shouldn't)
}
//
Observations:
If the function is not templated, things are refused correctly. If there is no
embedded function, things are refused correctly.
Interesting observation:
If you try to explicitly mark the function as pure, then you *will* be shot
down:
//
void nothrowFun()() nothrow
{
void fun () nothrow pure
{
alias nothrow void function() StillImpure_t;
(cast(StillImpure_t)impureFun)(); //(here)
};
fun();
}
//
Error: pure function 'main.nothrowFun!().nothrowFun.fun' cannot call impure
function pointer 'cast(void function() nothrow) impureFun'
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10763] (x)[0 .. 1] doesn't work in CTFE
http://d.puremagic.com/issues/show_bug.cgi?id=10763 --- Comment #6 from timon.g...@gmx.ch 2013-08-19 03:25:14 PDT --- (In reply to comment #5) (In reply to comment #4) (In reply to comment #3) ... The corner cases arise if you still disallow x + 1. My guess is that you're allowing it in your implementation? ... Yes, but dereferencing it is an error. Subtracting one results in the address of x. That is not the issue. The problem is that in C, simply creating the pointer is undefined behaviour. I guess I'll update my implementation eventually to disallow this. (Other related limitations are that it currently allows escaping addresses to locals and simply closes over them, array appends may cause non-determinism and pointers can be freely compared.) ... Is there really a use case for this unsafe behaviour? Make more code CTFE-able. But it's undefined behaviour. There is not really a reason why (x)[0..1] should be UB. But I guess if you want to keep C behaviour and also keep the invariant that slices always point to arrays, this is indeed not fixable. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10763] (x)[0 .. 1] doesn't work in CTFE
http://d.puremagic.com/issues/show_bug.cgi?id=10763 Iain Buclaw ibuc...@ubuntu.com changed: What|Removed |Added CC||ibuc...@ubuntu.com --- Comment #7 from Iain Buclaw ibuc...@ubuntu.com 2013-08-19 03:42:54 PDT --- (In reply to comment #3) It's basically the same as issue 10266. The corner cases arise if you still disallow x + 1. My guess is that you're allowing it in your implementation? The problem with allowing it is that we're departing from C. And there's annoying things like: // global scope int x; int *p = x + 1; // points to junk! - must not compile Is there really a use case for this unsafe behaviour? Only one would be in std.math if we want to make the elementary functions CTFE-able (we've discussed this before). But yes, I think that it is right to disallow it, as there is no clean way to slice up basic types into an array and guarantee ie: format or endian correctness at compile time (cross-compilers, for instance). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10763] (x)[0 .. 1] doesn't work in CTFE
http://d.puremagic.com/issues/show_bug.cgi?id=10763 --- Comment #8 from Don clugd...@yahoo.com.au 2013-08-19 04:48:39 PDT --- (In reply to comment #7) (In reply to comment #3) It's basically the same as issue 10266. The corner cases arise if you still disallow x + 1. My guess is that you're allowing it in your implementation? The problem with allowing it is that we're departing from C. And there's annoying things like: // global scope int x; int *p = x + 1; // points to junk! - must not compile Is there really a use case for this unsafe behaviour? Only one would be in std.math if we want to make the elementary functions CTFE-able (we've discussed this before). That's why my proposed solution for that is to allow only the complete expression, where the pointer is instantly dereferenced: (cast(ulong *)cast(void *)f)[0]; and it really only needs to be allowed for 80-bit reals, since casting float-int and double-long is already supported. The minimal operations are: - significand - ulong - sign + exponent - ushort That would give us four special-case hacks which are x87 specific. Effectively they are intrinsics with ugly syntax. The existing code could be modified slightly to only use those four operations, with no performance penalty. But yes, I think that it is right to disallow it, as there is no clean way to slice up basic types into an array and guarantee ie: format or endian correctness at compile time (cross-compilers, for instance). It's an ugly area. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10833] DMD puts mixin's source code in the binary
http://d.puremagic.com/issues/show_bug.cgi?id=10833
Don clugd...@yahoo.com.au changed:
What|Removed |Added
Severity|critical|enhancement
--- Comment #3 from Don clugd...@yahoo.com.au 2013-08-19 05:01:21 PDT ---
The mixin source isn't put into the binary. What you're seeing is the
executable code of the template that you instantiated. It's exactly as if you
wrote:
string foo() {
return `void main() { writefln(hello world); }`;
}
There's a possible optimisation: templates instantiated only in a compile-time
context don't need to be put into the binary. Unfortunately the linker isn't
smart enough to detect they are never used. This should be fixable, but it's
not actually a bug.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10833] DMD puts mixin's source code in the binary
http://d.puremagic.com/issues/show_bug.cgi?id=10833 Vladimir Panteleev thecybersha...@gmail.com changed: What|Removed |Added CC||thecybersha...@gmail.com --- Comment #4 from Vladimir Panteleev thecybersha...@gmail.com 2013-08-19 15:05:42 EEST --- This should be fixable, but it's not actually a bug. FWIW, it can be a serious issue for closed-source software products, where details about the source code must not be present in executables. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10763] (x)[0 .. 1] doesn't work in CTFE
http://d.puremagic.com/issues/show_bug.cgi?id=10763 --- Comment #9 from Iain Buclaw ibuc...@ubuntu.com 2013-08-19 05:29:09 PDT --- (In reply to comment #8) (In reply to comment #7) (In reply to comment #3) It's basically the same as issue 10266. The corner cases arise if you still disallow x + 1. My guess is that you're allowing it in your implementation? The problem with allowing it is that we're departing from C. And there's annoying things like: // global scope int x; int *p = x + 1; // points to junk! - must not compile Is there really a use case for this unsafe behaviour? Only one would be in std.math if we want to make the elementary functions CTFE-able (we've discussed this before). That's why my proposed solution for that is to allow only the complete expression, where the pointer is instantly dereferenced: (cast(ulong *)cast(void *)f)[0]; and it really only needs to be allowed for 80-bit reals, since casting float-int and double-long is already supported. And (speaking as someone who stubbed out your implementation of float-int and double-long cast) the only reason why it's supported is because the backend I implement against can (thankfully) do re-interpreted native casts between basic types such as integer, float, complex and vectors. You will need to support all reals that have support in std.math. This includes 64-bit, 80-bit, 96-bit (really just 80-bit), 128-bit (likewise), and 128-bit (quadruple). There are only three supported formats really... (double-double will have to keep with partial support for the time being, sorry PPC!) The minimal operations are: - significand - ulong - sign + exponent - ushort That would give us four special-case hacks which are x87 specific. Effectively they are intrinsics with ugly syntax. I veto any new addition that is x87 specific - or, more accurately endian specific. Remember its: version(BigEndian) short sign_exp = (cast(ushort*)x)[0]; else short sign_exp = (cast(ushort*)x)[5]; -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10833] DMD puts mixin's source code in the binary
http://d.puremagic.com/issues/show_bug.cgi?id=10833 --- Comment #5 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-08-19 06:45:42 PDT --- (In reply to comment #4) This should be fixable, but it's not actually a bug. FWIW, it can be a serious issue for closed-source software products, where details about the source code must not be present in executables. Yeah. This is why I propose a -security switch to add guarantees about what the compiler does, rather than rely on compiler optimizations. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10763] (x)[0 .. 1] doesn't work in CTFE
http://d.puremagic.com/issues/show_bug.cgi?id=10763
--- Comment #10 from Iain Buclaw ibuc...@ubuntu.com 2013-08-19 07:44:59 PDT
---
(In reply to comment #9)
I veto any new addition that is x87 specific - or, more accurately endian
specific.
Remember its:
version(BigEndian)
short sign_exp = (cast(ushort*)x)[0];
else
short sign_exp = (cast(ushort*)x)[5];
Wrote a quick toy routine to paint real-ushort[real.sizeof/2] (based on
backend routine that interprets a value as a vector).
--- pseudo code ---
Expression* e = RealExp(42.0L);
size_t len = native_encode_expr(e, buffer);
(gdb) p buffer
\000\000\000\000\000\000\000\250\004@\000\000\000\000\000\000`\365f\001\000\000\000\000\300\341\377\377\377\177\000\000\000\000\000\000\00
0\000\000\000\023\340Z\000\000\000\000\000`As\001\000\000\000\000\006\000\000\000\000\000\000
tree cst = native_interpret_array (TypeSArray(ushort, 8), buffer, len);
(gdb) p debug_tree(cst)
{[0]=0, [1]=0, [2]=0, [3]=43008, [4]=16388, [5]=0, [6]=0, [7]=0}
---
OK, lets check this output against run-time results.
---
writeln(*cast(ushort[8]*)(x));
= [0, 0, 0, 43008, 16388, 0, 32672, 0]
Which looks like at a first glance that the real-ushort[real.sizeof/2]
conversion isn't correct... up until the point you realise that the '32672'
value is just garbage in padding.
So... this might be very well doable, but will have to be *extremely* careful
about it. Also, I'm assuming that CTFE is able to get values from constant
static arrays?
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10522] __FILE__ and other special keywords cannot be used with printf
http://d.puremagic.com/issues/show_bug.cgi?id=10522 yebblies yebbl...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||yebbl...@gmail.com Resolution||INVALID --- Comment #1 from yebblies yebbl...@gmail.com 2013-08-20 00:38:30 EST --- Neither can string literals! printf is a c-varargs function, and has no way of knowing you want the implicit conversion to const(char)*. Solutions: printf(-- %s\n, cast(const(char*))__FILE__); printf(-- %.*s\n, __FILE__.length, __FILE__.ptr); -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10853] New: ClassInfo.find doesn't work for nested classes
http://d.puremagic.com/issues/show_bug.cgi?id=10853
Summary: ClassInfo.find doesn't work for nested classes
Product: D
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: d...@me.com
--- Comment #0 from Jacob Carlborg d...@me.com 2013-08-19 08:11:38 PDT ---
I just noticed that ClassInfo.find doesn't work for nested classes, even if
they are static. For example:
unittest
{
static class Foo { }
auto name = Foo.classinfo.name;
assert(ClassInfo.find(name) is null); // unfortunately passes
}
I was about to try the documented unit test feature in my work on
std.serialization but I want to have the type I'm serializing visible in the
example as well.
Is it possible to fix somehow? I looked at the symbol table and it seems the
class info is there, but ClassInfo.find just can't find it.
000100040980 D _D4test14__unittestL7_1FZv3Foo6__initZ
000100040a50 D _D4test14__unittestL7_1FZv3Foo6__vtblZ
0001000409b0 D _D4test14__unittestL7_1FZv3Foo7__ClassZ
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10522] __FILE__ and other special keywords cannot be used with printf
http://d.puremagic.com/issues/show_bug.cgi?id=10522 --- Comment #2 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-08-19 08:35:40 PDT --- (In reply to comment #1) Neither can string literals! printf is a c-varargs function, and has no way of knowing you want the implicit conversion to const(char)*. I guess that shows how spoiled I am by D's variadic templates. :) printf(-- %s\n, cast(const(char*))__FILE__); Also __FILE__.ptr and __FILE__.toStringz. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10854] New: debug should also bypass safety and nothrow
http://d.puremagic.com/issues/show_bug.cgi?id=10854 Summary: debug should also bypass safety and nothrow Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: monarchdo...@gmail.com --- Comment #0 from monarchdo...@gmail.com 2013-08-19 08:42:51 PDT --- debug instructions/blocks were allowed to nicely bypass function purity. This allows inserting impure calls for testing reasons inside pure functions. This should be expanded for @safe and nothrow. Its really a natural evolution IMO. There is nothing more annoying than inserting a test writeln() in a function, only to be refused because said function is @safe or nothrow. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10854] debug should also bypass safety and nothrow
http://d.puremagic.com/issues/show_bug.cgi?id=10854
bearophile_h...@eml.cc changed:
What|Removed |Added
CC||bearophile_h...@eml.cc
--- Comment #1 from bearophile_h...@eml.cc 2013-08-19 09:21:47 PDT ---
(In reply to comment #0)
debug instructions/blocks were allowed to nicely bypass function purity. This
allows inserting impure calls for testing reasons inside pure functions.
This should be expanded for @safe and nothrow. Its really a natural evolution
IMO.
If in module A you call a nothrow function F from module B, and you pre-compile
module A with aggressive optimizations that rely on F never throwing, and then
you run the module B in debug mode and now the function F throws, what does it
happens?
If F is also tagged with 'pure' and when you debug B you call something not
pure, like printf(), inside the debug{}, the optimizations of the compilation
of the module A could cause some of those calls to printf() to never happen.
But if the code inside debug{} is well behaved this doesn't cause significant
problems. Peraphs with nothrow the situation is worse.
There is nothing more annoying than inserting a test writeln() in a
function,
only to be refused because said function is @safe or nothrow.
For that I try to use printf(), that is nothrow.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10855] New: Missing dmd.conf for FreeBSD in DMD 2.063.2 release
http://d.puremagic.com/issues/show_bug.cgi?id=10855 Summary: Missing dmd.conf for FreeBSD in DMD 2.063.2 release Product: D Version: unspecified Platform: All OS/Version: FreeBSD Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: d...@me.com --- Comment #0 from Jacob Carlborg d...@me.com 2013-08-19 09:31:27 PDT --- -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10763] (x)[0 .. 1] doesn't work in CTFE
http://d.puremagic.com/issues/show_bug.cgi?id=10763
--- Comment #11 from Iain Buclaw ibuc...@ubuntu.com 2013-08-19 10:22:55 PDT
---
(In reply to comment #10)
So... this might be very well doable, but will have to be *extremely* careful
about it. Also, I'm assuming that CTFE is able to get values from constant
static arrays?
Adapted code so that it does the following:
real - ushort[8]:
RealExp - VectorExp(ushort[8]) - ArrayLiteralExp(ushort[8])
Result?
---
ushort[8] foo(real x)
{ return *cast(ushort[8]*)(x);
}
real bar(ushort[8] x)
{ return *cast(real*)(x);
}
pragma(msg, foo(42.0L));
pragma(msg, bar(foo(42.0L)));
static assert(foo(42.0L) == [0,0,0,43008,16388,0,0,0]);
static assert(bar(foo(42.0L)) == 42.0L);
pragma(msg, Success!);
---
$ gdc -c paint.d
[cast(ushort)0u, cast(ushort)0u, cast(ushort)0u, cast(ushort)43008u,
cast(ushort)16388u, cast(ushort)0u, cast(ushort)0u, cast(ushort)0u]
4.2e+1
Success!
Only downside is that it is restricted to T[x].sizeof == real.sizeof.
So real-ulong[2] only works with 128bit reals on 64bit, but could look into
getting around that later...
Don, I think I'm ready to test trial this in GDC if you are willing to
implement this in DMD?
Regards
Iain.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10854] debug should also bypass safety and nothrow
http://d.puremagic.com/issues/show_bug.cgi?id=10854
--- Comment #2 from monarchdo...@gmail.com 2013-08-19 10:40:40 PDT ---
(In reply to comment #1)
(In reply to comment #0)
debug instructions/blocks were allowed to nicely bypass function purity.
This
allows inserting impure calls for testing reasons inside pure functions.
This should be expanded for @safe and nothrow. Its really a natural
evolution
IMO.
If in module A you call a nothrow function F from module B, and you
pre-compile
module A with aggressive optimizations that rely on F never throwing, and then
you run the module B in debug mode and now the function F throws, what does it
happens?
If the *context* of the debug instruction is nothrow, then the debug could be
automatically expanded to try {BODY} catch (Exception e){assert(0,
formatException %s was thrown from a debug clause in a nothrow context);}
Or something with scope(failure), to avoid scoping the debug instruction/
If F is also tagged with 'pure' and when you debug B you call something not
pure, like printf(), inside the debug{}, the optimizations of the compilation
of the module A could cause some of those calls to printf() to never happen.
But that is what we already have. Also, I don't think the new pure definitions
mean a pure function can be outright optimized out. But I'm unsure.
But if the code inside debug{} is well behaved this doesn't cause significant
problems. Peraphs with nothrow the situation is worse.
There is nothing more annoying than inserting a test writeln() in a
function,
only to be refused because said function is @safe or nothrow.
For that I try to use printf(), that is nothrow.
That is indeed a workaround, but much less powerful than a writef. It is also a
workaround to something (IMO) you shouldn't have to. But thanks for the tip.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 9599] File.byLine doesn't function properly with take
http://d.puremagic.com/issues/show_bug.cgi?id=9599 --- Comment #5 from github-bugzi...@puremagic.com 2013-08-19 10:50:18 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/4c2a8bea355e2a980b21d41c5454fe7a34de1777 Add unittest for issue 9599, plus some other byLine cases https://github.com/D-Programming-Language/phobos/commit/ec1f0fdb9d3f4b9ffd3acd444d27195ffc6a15fb Fix Issue 9599 - File.byLine doesn't function properly with take Calling take could wrongly pop an extra line from the range. Solved by making ByLine use reference-counting. Note: Just changing ByLine not to eagerly read the next line was not sufficient to handle all cases properly (plus that makes empty() less efficient). Note: ByLine was documented until recently. https://github.com/D-Programming-Language/phobos/commit/7bc6e8153921b10eb61179ec318e01b825ff94c5 Merge pull request #1433 from ntrel/byLine-take Fix Issue 9599 - File.byLine doesn't function properly with take -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9599] File.byLine doesn't function properly with take
http://d.puremagic.com/issues/show_bug.cgi?id=9599 monarchdo...@gmail.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 10833] DMD puts mixin's source code in the binary
http://d.puremagic.com/issues/show_bug.cgi?id=10833 hst...@quickfur.ath.cx changed: What|Removed |Added CC||hst...@quickfur.ath.cx --- Comment #6 from hst...@quickfur.ath.cx 2013-08-19 12:58:15 PDT --- IMO DMD should somehow keep track of which template instantiations actually require code to be emitted. If a template function only runs in CTFE but not at runtime, that code shouldn't even be emitted in the first place. Tho I understand that separate compilation may make this tricky. :) One possible approach is to emit all template instantiations in a separate static library that the linker can then selectively pull from. Linkers are designed to only pull parts of the library that are actually referenced, so this won't require massive compiler changes. Then we can both reduce template bloat and avoid security issues like this one. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10854] debug should also bypass safety and nothrow
http://d.puremagic.com/issues/show_bug.cgi?id=10854
--- Comment #3 from bearophile_h...@eml.cc 2013-08-19 13:05:40 PDT ---
(In reply to comment #2)
Also, I don't think the new pure definitions
mean a pure function can be outright optimized out. But I'm unsure.
The DMD compiler completely optimizes out strongly pure functions in some
situations. And I expect better optimizers to remove some more calls. Observe:
import std.stdio;
int sqr(in int x) pure nothrow {
debug printf(sqr\n);
return x ^^ 2;
}
int twoSqr(in int x) pure nothrow {
return sqr(x) + sqr(x);
}
void main() {
writeln(twoSqr(3));
}
...dmd -debug -run test.d
sqr
sqr
18
...dmd -O -release -debug -run test.d
sqr
18
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10848] Compiler should always try to inlining a direct lambda call
http://d.puremagic.com/issues/show_bug.cgi?id=10848
--- Comment #2 from hst...@quickfur.ath.cx 2013-08-19 19:38:26 PDT ---
It would be nice if this also applied to opApply that basically uses a single
loop:
class C {
int opApply(scope void delegate(ref T iter) dg) {
setupLoop(); // some simple setup code
foreach (e; getInternalData()) {
auto ret = dg(e);
if (ret) return ret;
}
cleanupLoop(); // some simple cleanup code
}
}
void main() {
auto c = new C;
foreach (e; c) {
// opApply really should just be inlined here.
}
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4453] Loop-invariant code motion for pure functions
http://d.puremagic.com/issues/show_bug.cgi?id=4453 hst...@quickfur.ath.cx changed: What|Removed |Added CC||hst...@quickfur.ath.cx --- Comment #1 from hst...@quickfur.ath.cx 2013-08-19 19:55:14 PDT --- This looks like a front-end enhancement; just tested the code with gdc -O3, and the call to _aaGetRvalueX is still inside the loop body (in spite of massive inlining and loop unrolling by the gcc backend). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6256] [patch] std.algorithm.map does not support static arrays and has 'length' for narrow strings.
http://d.puremagic.com/issues/show_bug.cgi?id=6256
--- Comment #2 from hst...@quickfur.ath.cx 2013-08-19 20:03:36 PDT ---
As for iterating over static arrays, one workaround is to slice it:
import std.algorithm, std.range, std.stdio;
void main() {
uint[4] test = [1,2,3,4];
writeln(map!(a=a+10)(test[]));
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6256] [patch] std.algorithm.map does not support static arrays and has 'length' for narrow strings.
http://d.puremagic.com/issues/show_bug.cgi?id=6256
hst...@quickfur.ath.cx changed:
What|Removed |Added
CC||hst...@quickfur.ath.cx
--- Comment #1 from hst...@quickfur.ath.cx 2013-08-19 20:01:49 PDT ---
FWIW, map has been fixed in git HEAD to not export length with narrow strings:
import std.algorithm, std.range;
void main() {
string narrow = abcdef;
auto m = map!(a = a)(narrow);
static assert(!hasLength!(typeof(m)));
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7049] Multiple scope(failure) blocks don't work in @safe code
http://d.puremagic.com/issues/show_bug.cgi?id=7049
hst...@quickfur.ath.cx changed:
What|Removed |Added
Status|NEW |RESOLVED
CC||hst...@quickfur.ath.cx
Resolution||WORKSFORME
--- Comment #2 from hst...@quickfur.ath.cx 2013-08-19 20:15:35 PDT ---
Seems to be fixed in git HEAD. To prove that it actually works, I expanded the
test code a bit:
--
import std.stdio;
int count = 0;
@safe void foo() {
scope (failure) { count++; }
scope (failure) { count++; }
throw new Exception(failed);
}
void main() {
try {
foo();
} catch(Exception e) {
}
writeln(count);
}
--
Output:
2
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7049] Multiple scope(failure) blocks don't work in @safe code
http://d.puremagic.com/issues/show_bug.cgi?id=7049 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added CC||andrej.mitrov...@gmail.com --- Comment #3 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-08-19 20:20:06 PDT --- It would be great to add these test-cases of worksforme bugs to the test-suite, if they're not already there. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10848] Compiler should always try to inlining a direct lambda call
http://d.puremagic.com/issues/show_bug.cgi?id=10848 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull --- Comment #3 from Kenji Hara k.hara...@gmail.com 2013-08-19 20:34:43 PDT --- https://github.com/D-Programming-Language/dmd/pull/2483 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7049] Multiple scope(failure) blocks don't work in @safe code
http://d.puremagic.com/issues/show_bug.cgi?id=7049 --- Comment #4 from hst...@quickfur.ath.cx 2013-08-19 20:33:32 PDT --- https://github.com/D-Programming-Language/dmd/pull/2484 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10848] Compiler should always try to inlining a direct lambda call
http://d.puremagic.com/issues/show_bug.cgi?id=10848 --- Comment #4 from Kenji Hara k.hara...@gmail.com 2013-08-19 20:47:41 PDT --- (In reply to comment #1) Sounds like a good case for a __forceinline attribute, and then apply it implicitly in this case. This situation could leverage the same internal mechanic. forceinline is misleading word. This proposal *does not* guarantee that the generated code is always inlined. If the given lambda body is too large/complex, or compiler's inlining ability is very little, the generated code may not be inlined. The language spec should allow it. I still have MANY places where I want to guarantee inlining of certain functions. Inlining would increase compilation time. Such places should be defined carefully. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10857] New: ICE(glue.c, bugzilla 2962?) or compiles, depending on the files order
http://d.puremagic.com/issues/show_bug.cgi?id=10857
Summary: ICE(glue.c, bugzilla 2962?) or compiles, depending on
the files order
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: ice, 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-08-19 20:59:24 PDT ---
This is somehow similar to Issue 8071.
COMMAND:
dmd -inline moda.d modb.d
# files' order is significant.
OUTPUT:(by 2.063.2)
modb.d(4): Error: function modb.foo compiler error, parameter 'outer', bugzilla
2962?
Assertion failure: '0' on line 817 in file 'glue.c'
SOURCES:
--moda.d
import std.algorithm;
--modb.d
import std.algorithm;
import moda;
void foo(bool outer) {
int[] infos;
infos.filter!(s=outer)(); // NG: error is triggered here
//infos.filter!((int s)=outer)(); // OK
}
void main() {}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10848] Compiler should always try to inlining a direct lambda call
http://d.puremagic.com/issues/show_bug.cgi?id=10848 --- Comment #5 from Kenji Hara k.hara...@gmail.com 2013-08-19 21:02:53 PDT --- (In reply to comment #2) It would be nice if this also applied to opApply that basically uses a single loop: To make expand opApply foreach useful, it would need two-level inlining. (first is for the call of opApply, second is for the call of the scope delegate) I can imagine that in most case it would introduce generated code bloat. Therefore I think it should be treated by the -inline switch without any special treatment. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10857] ICE(glue.c, bugzilla 2962?) or compiles, depending on the files order
http://d.puremagic.com/issues/show_bug.cgi?id=10857 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull --- Comment #1 from Kenji Hara k.hara...@gmail.com 2013-08-19 21:59:34 PDT --- https://github.com/D-Programming-Language/dmd/pull/2485 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
