[Issue 5091] main runs after unittests
http://d.puremagic.com/issues/show_bug.cgi?id=5091 Peter Alexander peter.alexander...@gmail.com changed: What|Removed |Added CC||peter.alexander...@gmail.co ||m --- Comment #1 from Peter Alexander peter.alexander...@gmail.com 2010-10-21 01:07:14 PDT --- (In reply to comment #0) When compiling a program with dmd -unittest, after the unittests are run, main() is called. This is rarely wanted behavior, so should not be the default. Why is this rarely wanted? If your way was the default then your work flow would be: - Make change - Run with unit test - Run without unit test - Make change - Run with unit test - Run without unit test - etc. The whole point of unit tests is that they are run regularly, preferably after ever change. If you only run them after lots of changes then it makes it much more difficult to find out what broke the build. If you have a lot of time-consuming unit tests in your code then these should be put inside a slowtest version block so that you can leave those for your nightly testing (or whatever you want to do). In general however, unittest should always be on. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5091] main runs after unittests
http://d.puremagic.com/issues/show_bug.cgi?id=5091 --- Comment #2 from Peter Alexander peter.alexander...@gmail.com 2010-10-21 01:11:22 PDT --- Even if you don't buy that argument, consider this: with the current unittest, you only have to add a few lines of code to turn it off (as you described). This is something that you'll only ever have to do once, and really isn't that much of a burden. On the other hand, if running main was off by default then there would be no way to turn it back on! You would have to resort to scripting your build to get it working again. Therefore, the current unittest is unarguably more flexible to people's needs, and arguably more desirable anyway. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5091] main runs after unittests
http://d.puremagic.com/issues/show_bug.cgi?id=5091 bearophile_h...@eml.cc changed: What|Removed |Added CC||bearophile_h...@eml.cc --- Comment #3 from bearophile_h...@eml.cc 2010-10-21 03:19:14 PDT --- (In reply to comment #1) Why is this rarely wanted? D unittesting needs a global redesign, not small changes. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5092] New: pure nothrow should be ignored for unit tests
http://d.puremagic.com/issues/show_bug.cgi?id=5092
Summary: pure nothrow should be ignored for unit tests
Product: D
Version: D2
Platform: Other
OS/Version: Windows
Status: NEW
Keywords: patch
Severity: enhancement
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: clugd...@yahoo.com.au
--- Comment #0 from Don clugd...@yahoo.com.au 2010-10-21 06:50:18 PDT ---
import std.stdio;
pure nothrow:
int foo(int z) { return z*2; }
unittest {
writeln(testing foo);
assert(foo(4) == 8);
}
---
This won't compile, because the unit test calls writeln which is impure and may
throw.
It makes no sense for a unittest to be nothrow. And it's really a nuisance.
And if a unittest isn't conceptually pure, you have a big problem anyway -- the
program behaviour will change depending on whether unittests are run, or not.
PATCH: func.c, around line 3460
void UnitTestDeclaration::semantic(Scope *sc)
{
if (global.params.useUnitTests)
{
if (!type)
type = new TypeFunction(NULL, Type::tvoid, FALSE, LINKd);
Scope *sc2 = sc-push();
+// It makes no sense for unit tests to be pure or nothrow.
+sc2-stc = ~(STCnothrow | STCpure);
sc2-linkage = LINKd;
FuncDeclaration::semantic(sc2);
sc2-pop();
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5093] New: improve error for importing std.c.windows.windows
http://d.puremagic.com/issues/show_bug.cgi?id=5093 Summary: improve error for importing std.c.windows.windows Product: D Version: D2 Platform: All OS/Version: Linux Status: NEW Severity: enhancement Priority: P2 Component: Phobos AssignedTo: nob...@puremagic.com ReportedBy: jesse.k.phillip...@gmail.com CC: jesse.k.phillip...@gmail.com --- Comment #0 from Jesse Phillips jesse.k.phillip...@gmail.com 2010-10-21 09:08:13 PDT --- Currently when you import std.c.windows.windows on a non-Windows machine, the file and line number of std/c/windows/windows.d is returned due to a static assert(0). This is great and all, but it would be really nice to have the file and line number of the importer. I don't know of how to improve this. Maybe an improvement to DMD so that a module that is imported and has a static assert(0) results in the importer file and line being used? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5057] std.variant.Algebraic-aware GC
http://d.puremagic.com/issues/show_bug.cgi?id=5057 --- Comment #3 from bearophile_h...@eml.cc 2010-10-21 09:38:59 PDT --- A more general solution it to add to D an optional standard method, that may be named onScan or something else, that the garbage collection calls if present, and returns information that the GC uses at runtime to know what contents to follow, etc. So a user-defined union may define such onScan(), that reads the instance tag to say the GC what to do. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5093] improve error for importing std.c.windows.windows
http://d.puremagic.com/issues/show_bug.cgi?id=5093 bearophile_h...@eml.cc changed: What|Removed |Added CC||bearophile_h...@eml.cc --- Comment #1 from bearophile_h...@eml.cc 2010-10-21 09:40:34 PDT --- More generally, it may useful to have an error message for failed imports that shows the file name and line number of the module that contains the import statement. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5094] New: No implicit conversion with alias property this
http://d.puremagic.com/issues/show_bug.cgi?id=5094
Summary: No implicit conversion with alias property this
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: rejects-valid
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: rsi...@gmail.com
--- Comment #0 from Shin Fujishiro rsi...@gmail.com 2010-10-21 10:05:37 PDT
---
Implicit conversion with help of alias this doesn't work if the aliased symbol
is a property (or just nullary) function. The following code doesn't compile:
void main()
{
S s;
int[] conv = s; // (4)
}
struct S
{
@property int[] get() { return [1,2,3]; }
alias get this;
}
% dmd -o- -c test.d
test.d(4): Error: cannot implicitly convert expression (s) of type S to int[]
The repro code compiles fine if 'get' is a variable.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5094] No implicit conversion with alias property this
http://d.puremagic.com/issues/show_bug.cgi?id=5094 --- Comment #1 from Shin Fujishiro rsi...@gmail.com 2010-10-21 10:07:27 PDT --- Created an attachment (id=789) Patch against dmd r725, fixes implicitConvTo() implicitConvTo() of TypeStruct and TypeClass don't deal with functions, and just tests convertion from function type to value type (then fails). The attached patch fixes the problem by adding a special check for functions. Passed dmd/druntime/phobos tests. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5091] main runs after unittests
http://d.puremagic.com/issues/show_bug.cgi?id=5091 --- Comment #4 from Simen Kjaeraas simen.kja...@gmail.com 2010-10-21 10:32:36 PDT --- (In reply to comment #1) (In reply to comment #0) When compiling a program with dmd -unittest, after the unittests are run, main() is called. This is rarely wanted behavior, so should not be the default. Why is this rarely wanted? Because I never want my program to run after I run my unittests? If the unittests pass, my program should be working, apart from things that are impossible/hard to unittest. If your way was the default then your work flow would be: - Make change - Run with unit test - Run without unit test - Make change - Run with unit test - Run without unit test - etc. That's one possibility. When I program, I aim for such coverage with my unittests that running the program to see if things work is not necessary. Hence, a more likely scenario: 1 Make change 2 Run unittests (quick) 3 If unittests fail, goto 1 4 Run normally (slow) 5 Goto 1 I have not once wanted to run both the full application and the unittests at the same time. when I want to run the unittests, running the application would be a waste of time. When I want to run the program, I don't care about the unittests. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5093] improve error for importing std.c.windows.windows
http://d.puremagic.com/issues/show_bug.cgi?id=5093 Steven Schveighoffer schvei...@yahoo.com changed: What|Removed |Added CC||schvei...@yahoo.com --- Comment #2 from Steven Schveighoffer schvei...@yahoo.com 2010-10-21 10:43:50 PDT --- you might want to try dmd -v. It shows imports in the order they were imported. It doesn't show the file which imports it, but you can get a good idea probably from the prior file list. I'd say adding the file imported from would be a good thing to add to -v. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5095] New: Error for typesafe variadic functions for structs
http://d.puremagic.com/issues/show_bug.cgi?id=5095
Summary: Error for typesafe variadic functions for structs
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: diagnostic
Severity: minor
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2010-10-21 14:07:55 PDT ---
This is a wrong D2 progra:
struct Foo {
int x;
this(int x_) {
this.x = x_;
}
}
void test(Foo f ...) {}
void main() {
test(1);
}
DMD 2.049 shows at compile-time:
test.d(9): Error: function test2.test (Foo f...) is not callable using argument
types (int)
test.d(9): Error: cannot implicitly convert expression (1) of type int to Foo
But I'd like a better single error message, like for example:
test.d(9): Error: function test2.test (Foo f...) is not callable using argument
types (int), typesafe variadic functions for structs are not supported.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5096] New: More readable unpaired brace error
http://d.puremagic.com/issues/show_bug.cgi?id=5096
Summary: More readable unpaired brace error
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: diagnostic
Severity: minor
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2010-10-21 15:16:28 PDT ---
This is a wrong D2 program:
void foo(int x)
in {
assert(x 0);
} body {
x++;
}
}
void main() {}
DMD 2.049 shows at compile-time:
test.d(7): unrecognized declaration
But that's not easy to understand. A simpler to understand error message may be
something like:
test.d(7): closing brace lacking a corresponding open brace.
Good error messages may shave away wasted seconds during debug, and seconds add
up.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4571] Non-null class references/pointers
http://d.puremagic.com/issues/show_bug.cgi?id=4571 --- Comment #3 from bearophile_h...@eml.cc 2010-10-21 17:52:56 PDT --- Another older partial implementation of typestates from Microsoft, in the Vault language: http://web.archive.org/web/20060706065107/research.microsoft.com/vault/learn/typing/typing.htm -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5097] New: Safer unions with @tagged
http://d.puremagic.com/issues/show_bug.cgi?id=5097
Summary: Safer unions with @tagged
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2010-10-21 18:34:53 PDT ---
D language is designed to be safer than C and C++, yet it's not Java, it has to
offer less safe features too, like unions.
The failure of the Cyclone language shows that the safety features need to be
light, minimal, not syntactically intrusive.
The simpler way to make unions safe is to introduce an attribute as @tagged.
When an union has a @tagged attribute, one word is added by the compiler to the
union, that makes sure (with runtime tests) that the last written field is
read. In release mode this invisible field and their tests vanish (a better
feature is to test and enforce this at compile time, but this requires a more
complex type system that D doesn't have).
(If you want even more safety, unions with the @tagged attribute may not allow
to take the address of fields, to avoid bypassing the runtime cheeks.)
In the end the programmer that wants to use safer unions in D may just add the
@tagged attribute, nothing else is required, and the union semantics is
unchanged (just its size is changed in non-release mode). So this is a very
light and easy to use safety net:
@tagged union Foo {
int i;
float f;
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5097] Safer unions with @tagged
http://d.puremagic.com/issues/show_bug.cgi?id=5097 --- Comment #1 from bearophile_h...@eml.cc 2010-10-21 18:40:42 PDT --- This is not the same as std.variant.Algebraic because: - There is no way for the programmer to read the tag, because the tag and its tests vanish in release mode. - Unions may have methods, they are quite more flexible than Algebraic. - If you translate C code to D you may not want to modify too much the code, so you will not use Algebraic. But you may add the @tagged attribute to unions translated from C. The size of the union changes, but hopefully this doesn't cause disasters often (if changing the size of the union is seen as not acceptable, then the union tags may be stored elsewhere on the heap and stack, but this may increase the implementation complexity of this feature). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5098] New: -unittest does not turn on asserts nor sets unittest version in D1
http://d.puremagic.com/issues/show_bug.cgi?id=5098 Summary: -unittest does not turn on asserts nor sets unittest version in D1 Product: D Version: D1 Platform: Other OS/Version: All Status: NEW Severity: normal Priority: P2 Component: websites AssignedTo: nob...@puremagic.com ReportedBy: st...@despam.it --- Comment #0 from st...@despam.it 2010-10-21 19:04:09 PDT --- http://www.digitalmars.com/d/1.0/dmd-windows.html#switches -unittest compile in unittest code, turns on asserts, and sets the unittest version identifier http://www.digitalmars.com/d/1.0/unittest.html The version identifier unittest is predefined if the compilation is done with unit tests enabled. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5097] Safer unions with @tagged
http://d.puremagic.com/issues/show_bug.cgi?id=5097 Andrei Alexandrescu and...@metalanguage.com changed: What|Removed |Added Status|NEW |RESOLVED CC||and...@metalanguage.com Resolution||INVALID --- Comment #2 from Andrei Alexandrescu and...@metalanguage.com 2010-10-21 20:00:28 PDT --- (In reply to comment #1) This is not the same as std.variant.Algebraic because: - There is no way for the programmer to read the tag, because the tag and its tests vanish in release mode. This does not justify a new language feature. Anyone could define a private tag that doesn't vanish in release mode. - Unions may have methods, they are quite more flexible than Algebraic. A struct with an Algebraic member can define methods. - If you translate C code to D you may not want to modify too much the code, so you will not use Algebraic. But you may add the @tagged attribute to unions translated from C. The size of the union changes, but hopefully this doesn't cause disasters often (if changing the size of the union is seen as not acceptable, then the union tags may be stored elsewhere on the heap and stack, but this may increase the implementation complexity of this feature). Translation from C is hardly improved as use of union is rather rare. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5097] Safer unions with @tagged
http://d.puremagic.com/issues/show_bug.cgi?id=5097 --- Comment #3 from Andrei Alexandrescu and...@metalanguage.com 2010-10-21 20:27:47 PDT --- (In reply to comment #2) (In reply to comment #1) This is not the same as std.variant.Algebraic because: - There is no way for the programmer to read the tag, because the tag and its tests vanish in release mode. This does not justify a new language feature. Anyone could define a private tag that doesn't vanish in release mode. Oops, I meant does. Andrei -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
