[Issue 4995] New: invariant() can violate a function's nothrow
http://d.puremagic.com/issues/show_bug.cgi?id=4995
Summary: invariant() can violate a function's nothrow
Product: D
Version: unspecified
Platform: Other
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: jmdavisp...@gmx.com
--- Comment #0 from Jonathan M Davis 2010-10-04 22:49:07
PDT ---
Take this program:
import std.stdio;
struct S
{
int val() nothrow
{
return 7;
}
invariant()
{
throw new Exception("Hello from your friendly, neighborhood
invariant!");
}
}
void main()
{
auto s = S();
writeln(s.val);
}
It results in this output:
object.Exception: Hello from invariant
./d(nothrow int d.S.val()) [0x807ece2]
./d(_Dmain+0x12) [0x807ed3a]
./d(extern (C) int rt.dmain2.main(int, char**)) [0x8084cd6]
./d(extern (C) int rt.dmain2.main(int, char**)) [0x8084c30]
./d(extern (C) int rt.dmain2.main(int, char**)) [0x8084d1a]
./d(extern (C) int rt.dmain2.main(int, char**)) [0x8084c30]
./d(main+0x96) [0x8084bd6]
/usr/lib32/libc.so.6(__libc_start_main+0xe6) [0xf7595c76]
./d() [0x807ec21]
This, in spite of the fact that val() is specifically marked as nothrow. This
is particularly interesting since the compiler does complain about impure
invariants (bug # 4974). Now, I hate to make invariants even pickier about
whether they'll compile or let your struct/class compile, but this clearly
violates the fact that val() is marked as nothrow. This program should not
compile (or at least not with these semantics). I see two options:
1. The compiler should refuse to compile an invariant which throws if any
function on the type is nothrow (very annoying, but possible necessary).
2. Merely change the generated code to consider any exception escaping the
invariant to result in the invariant failing, as if you had
scope(FAILURE) assert(0, "Exception thrown in invariant.");
at the top of the invariant. This seems like a much nicer solution to me.
Regardless, the code which is currently generated is obviously wrong.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4425] More bells & whistles for bitfields
http://d.puremagic.com/issues/show_bug.cgi?id=4425
--- Comment #2 from bearophile_h...@eml.cc 2010-10-04 18:16:44 PDT ---
Another possible feature is to make std.bitmanip.bitfields generate two
versions of the code, that get compiled conditionally according to the CPU
endianess:
static if (std.system.endian == std.system.Endian.BigEndian) {
...
} else {
...
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 2254] Size of executable almost triples
http://d.puremagic.com/issues/show_bug.cgi?id=2254 nfx...@gmail.com changed: What|Removed |Added CC||nfx...@gmail.com --- Comment #14 from nfx...@gmail.com 2010-10-04 17:41:57 PDT --- Those who are affected by this, be sure to check bug 4767. Can pull in unrelated and unused modules from the standard library. There's also bug 3214 which can double the size of debug executables. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4994] New: std.range assumeSorted and SortedRange!() don't work with immutables
http://d.puremagic.com/issues/show_bug.cgi?id=4994 Summary: std.range assumeSorted and SortedRange!() don't work with immutables Product: D Version: D2 Platform: x86 OS/Version: Windows Status: NEW Severity: major Priority: P2 Component: Phobos AssignedTo: nob...@puremagic.com ReportedBy: ah0801...@yahoo.com --- Comment #0 from Austin Hastings 2010-10-04 15:52:36 PDT --- The assumeSorted and SortedRange templates cannot work with immutable data. Apparently, one requirement for being sorted is supporting .save. The SortedRange!().save as written uses typeof() to copy the type of the input, without stripping off immutability. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4993] New: Temporary values and opIndexAssign
http://d.puremagic.com/issues/show_bug.cgi?id=4993
Summary: Temporary values and opIndexAssign
Product: D
Version: D2
Platform: Other
OS/Version: Windows
Status: NEW
Keywords: rejects-valid
Severity: major
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: simen.kja...@gmail.com
--- Comment #0 from Simen Kjaeraas 2010-10-04 13:14:44
PDT ---
The following code does not compile. Note that the exact same functions are
present in both the inner and outer structs, and that opIndex works for both.
struct Foo{
struct Bar {
int opIndex( size_t index ) {
return 3;
}
void opIndexAssign( int value, size_t index ) {
}
}
@property
auto bar( ) {
return Bar( );
}
int opIndex( size_t index ) {
return 3;
}
void opIndexAssign( int value, size_t index ) {
}
}
void main( ) {
Foo f;
f[3] = f[2];
Foo.Bar b;
b[3] = b[2];
f.bar[3] = f.bar[2]; // Fails
}
foo.d(28): Error: f.bar()[3u] is not an lvalue
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4992] New: ICE(glue.c) or segfault: using int[new]
http://d.puremagic.com/issues/show_bug.cgi?id=4992 Summary: ICE(glue.c) or segfault: using int[new] Product: D Version: D2 Platform: Other OS/Version: Windows Status: NEW Keywords: ice-on-invalid-code, patch Severity: normal Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: clugd...@yahoo.com.au --- Comment #0 from Don 2010-10-04 13:02:13 PDT --- TEST CASE: // ICE(glue.c) int[new] crash4992; // Segfault int crash4992b[new]; PATCH: Support for T[new] needs to be removed from the parser. mtype.c, Remove lines 2414 - 2419 from parseBasicType2(). and also from isDeclarator() parseDeclarator() They are easily found by searching for TOKnew. Each section begins with something like: - else if (token.value == TOKnew && peekNext() == TOKrbracket) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2254] Size of executable almost triples
http://d.puremagic.com/issues/show_bug.cgi?id=2254 --- Comment #13 from Heinz Traub 2010-10-04 12:56:05 PDT --- Please vote for this issue. It may give a higher priority and Walter might take a look at this long term bug. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4782] core.atomic.atomicLoad broken for floating point
http://d.puremagic.com/issues/show_bug.cgi?id=4782
David Simcha changed:
What|Removed |Added
Summary|atomicOp!"+=" hangs with|core.atomic.atomicLoad
|floating point |broken for floating point
--- Comment #1 from David Simcha 2010-10-04 12:42:16 PDT ---
I looked into this one a little. The root cause is actually that atomicLoad is
broken for floating point values. Floating point values are supposed to be
returned in floating point registers, not x86 registers. Here's an example
demonstrating this issue.
import std.stdio;
void main() {
double foo = 2;
writeln(atomicLoad!(msync.raw)(foo)); // -nan
}
// Copy/paste core.atomic here and remove module declaration, since atomic load
is private.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4991] New: Make 'nothrow', other function attributes, accessible (via traits?)
http://d.puremagic.com/issues/show_bug.cgi?id=4991
Summary: Make 'nothrow', other function attributes, accessible
(via traits?)
Product: D
Version: D2
Platform: Other
OS/Version: Windows
Status: NEW
Severity: enhancement
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: ah0801...@yahoo.com
--- Comment #0 from Austin Hastings 2010-10-04 12:15:45
PDT ---
In a template, I'd like to declare a mathematical function as pure/nothrow. The
problem is that I am using a traits template to specify behavior for some edge
conditions, and the caller may reasonably want the edge case to throw an
exception.
So I would like to be able to statically detect the nothrow status of the trait
class' behavior handler, and reflect that in the declaration of the template
function.
At the very least, this means providing a boolean query for nothrow. But in
fact, propagating the attribute would benefit from additional capabilities.
Declaring a function "conditionally nothrow" presently seems to require a
conditional re-declaration of the entire function either with or without the
nothrow added. There seems to be no way to mixin("nothrow") or { alias nothrow
NT } to add in the attribute.
Perhaps this kind of "attribute propagation" needs some kind of special tuple?
Or is this a reason to support prototypes?
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4990] New: Internal error "e2ir.c 4629" when trying to foreach over a compile time assoc array
http://d.puremagic.com/issues/show_bug.cgi?id=4990
Summary: Internal error "e2ir.c 4629" when trying to foreach
over a compile time assoc array
Product: D
Version: D2
Platform: x86_64
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: juan...@gmail.com
--- Comment #0 from Juanjo Alvarez 2010-10-04 12:12:43 PDT
---
Minimal test case, using DMD 2.0.49 on Linux (32 bits compiler on a 64 bits
machine & OS):
enum dict = ["key1": "value1"];
void main() {
foreach(key, value; dict) {}
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4982] Repeating same error message thousands of times due to brute forcing matching symbol name
http://d.puremagic.com/issues/show_bug.cgi?id=4982 --- Comment #2 from Koroskin Denis <2kor...@gmail.com> 2010-10-04 11:59:44 PDT --- With "int someSymbol;" uncommented code becomes valid, isn't it? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4989] New: opDispatch not used when alias this is present
http://d.puremagic.com/issues/show_bug.cgi?id=4989
Summary: opDispatch not used when alias this is present
Product: D
Version: D2
Platform: Other
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: schvei...@yahoo.com
--- Comment #0 from Steven Schveighoffer 2010-10-04
10:38:27 PDT ---
Example:
import std.stdio;
struct X
{
int foo() { return 1; }
bool foo2() {return true;}
}
struct S
{
X x;
// override only int functions
auto opDispatch(string fn, Args...)(Args args) if (is(typeof(mixin("x." ~
fn ~ "(args)")) == int))
{
writeln("calling " ~ fn);
mixin("return x." ~ fn ~ "(args);");
}
// override functions that aren't supported by X
void opDispatch(string fn, Args...)(Args args) if (!is(typeof(mixin("x." ~
fn ~ "(args)"
{
writeln("invalid function " ~ fn);
}
// let all others pass through (i.e. foo2)
alias x this;
}
void main()
{
S s;
s.foo();
s.foo2();
// s.baz(); // compiler error "Error: no property 'baz' for type 'X'"
}
when compiled, this outputs nothing. I'd expect to see (if last line of main
is uncommented):
calling foo
invalid function baz
Note the glaring use case here is being able to have an implicit cast, yet
override the behavior of the implicitly casted member.
At the very least, opDispatch should be used when the alias this'd value does
not support the function.
IMO, opDispatch should be preferred over the alias this'd member. Simply
because it's possible (though ugly) to select which opDispatch functions
compile, but it's impossible to selectively pick members to compile via alias
this.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4968] inout is sticky to function return type
http://d.puremagic.com/issues/show_bug.cgi?id=4968
Steven Schveighoffer changed:
What|Removed |Added
CC||schvei...@yahoo.com
--- Comment #1 from Steven Schveighoffer 2010-10-04
06:06:46 PDT ---
This is a good catch. Although inout doesn't work currently, so don't expect
much yet.
IMO, this is how the compiler should behave:
void foo(T)(T t)
{
writeln(typeof(t).stringof);
}
inout(int)
f(inout(int) i)
{
return i;
}
void main()
{
int i;
const int j;
immutable int k;
foo(f(i));
foo(f(j));
foo(f(k));
}
should print:
int
const(int)
immutable(int)
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3318] [PATCH]Rebindable.get is not accessible
http://d.puremagic.com/issues/show_bug.cgi?id=3318 --- Comment #5 from Steven Schveighoffer 2010-10-04 06:15:59 PDT --- *** Issue 4978 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 4986] New: IFTI fails on partial matching with value parameters
http://d.puremagic.com/issues/show_bug.cgi?id=4986
Summary: IFTI fails on partial matching with value parameters
Product: D
Version: D2
Platform: Other
OS/Version: Windows
Status: NEW
Keywords: rejects-valid
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: simen.kja...@gmail.com
--- Comment #0 from Simen Kjaeraas 2010-10-04 00:42:50
PDT ---
The following code fails to deduce the value of m2 in bar:
struct Foo( int n, int m ) {
/// Bugged:
void bar( int m2 )( Foo!( m2, n ) arg ) {}
// Workaround:
void baz( int n2, int m2 )( Foo!( n2, m2 ) arg ) if ( n == n2 ) {}
}
void bug( )( ) {
Foo!(3,2) f;
Foo!(3,3) g;
f.baz( g ); // Works.
f.bar( g ); // Fails.
}
foo.d(14): Error: template foo.Foo!(3,2).Foo.bar(int m2) does not match any
func
tion template declaration
foo.d(14): Error: template foo.Foo!(3,2).Foo.bar(int m2) cannot deduce template
function from argument types !()(Foo!(3,3))
Note also that this works for type parameters:
struct Foo( T, U ) {
void bar( V )( Foo!( T, V ) arg ) {}
}
void bug( )( ) {
Foo!(int, float) f;
Foo!(int, string) g;
f.bar( g );
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4988] New: Floats in structs are not equal on 0.0f vs -0.0f
http://d.puremagic.com/issues/show_bug.cgi?id=4988
Summary: Floats in structs are not equal on 0.0f vs -0.0f
Product: D
Version: D2
Platform: Other
OS/Version: Windows
Status: NEW
Keywords: wrong-code
Severity: critical
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: simen.kja...@gmail.com
--- Comment #0 from Simen Kjaeraas 2010-10-04 01:34:30
PDT ---
The following code asserts:
struct Foo {
float data;
}
void bug( ) {
assert( Foo( 0.0f ) == Foo( -0.0f ) ); // Works fine
auto a = Foo( 0.0f );
auto b = Foo( -0.0f );
assert( b == a ); // Asserts
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4987] New: C function pointer syntax needs to be deprecated
http://d.puremagic.com/issues/show_bug.cgi?id=4987
Summary: C function pointer syntax needs to be deprecated
Product: D
Version: D1 & D2
Platform: Other
OS/Version: Windows
Status: NEW
Keywords: patch
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: clugd...@yahoo.com.au
--- Comment #0 from Don 2010-10-04 01:14:13 PDT ---
This patch also gives a reasonable fix for bug 4962, "Improve error message for
wrong constructor name?"
It also gives nice error messages for missing return types in function
declarations.
Most importantly, it makes x(y) an invalid type, instead of being a declaration
of a 'y', where &y is type 'x function()'. It's critical that syntax be
removed.
---
PATCH: parse.c, Parser::parseDeclarator() line 2497
case TOKlparen:
if (peekNext() == TOKmul || peekNext() == TOKlparen ||
peekNext() == TOKlbracket)
{
/* Parse things with parentheses around the identifier, like:
* int (*ident[3])[]
* although the D style would be:
* int[]*[3] ident
*/
if (!global.params.useDeprecated) {
error("C-style function pointer syntax is deprecated. Use
'function' to declare function pointers");
}
nextToken();
ts = parseDeclarator(t, pident);
check(TOKrparen);
break;
}
ts = t;
Token *peekt = &token;
// Improve error messages for the common bug of a missing return
type
if (isParameters(&peekt)) {
error("function declaration without return type. "
"(Note that constructors are always named 'this')");
}
else
error("unexpected ( in declarator");
break;
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4982] Repeating same error message thousands of times due to brute forcing matching symbol name
http://d.puremagic.com/issues/show_bug.cgi?id=4982 Stewart Gordon changed: What|Removed |Added Keywords||diagnostic, ||ice-on-invalid-code CC||s...@iname.com Platform|Other |All Version|D2 |D1 & D2 Blocks||340 --- Comment #1 from Stewart Gordon 2010-10-04 06:02:35 PDT --- The error message is bogus in any case. Should be something like test.d(11): no property 'someSymbol' for type 'B' Though not technically an ICE, it seems to run into an infinite loop, effectively hanging the compiler, hence my adding ice-on-invalid-code. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4978] Can't get object out of Rebindable: get is private
http://d.puremagic.com/issues/show_bug.cgi?id=4978 Steven Schveighoffer changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #2 from Steven Schveighoffer 2010-10-04 06:15:59 PDT --- *** This issue has been marked as a duplicate of issue 3318 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
