[Issue 9904] typeof(null) can be casted to aggregate type if .sizeof equals size of pointer
http://d.puremagic.com/issues/show_bug.cgi?id=9904 Kenji Hara changed: What|Removed |Added Keywords||pull Status|NEW |RESOLVED Resolution||FIXED --- Comment #5 from Kenji Hara 2013-06-07 22:20:34 PDT --- Merged pull request: https://github.com/D-Programming-Language/dmd/pull/2148 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9904] typeof(null) can be casted to aggregate type if .sizeof equals size of pointer
http://d.puremagic.com/issues/show_bug.cgi?id=9904 --- Comment #4 from github-bugzi...@puremagic.com 2013-06-07 22:19:54 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/d859a617045bdf04b39edf14bb782faff642141a fix issue 9904 - typeof(null) can be casted to aggregate type if .sizeof equals size of pointer https://github.com/D-Programming-Language/dmd/commit/3c5eb896fb87b788dd0cb7631fbdf8c5cf77d9f2 Merge pull request #2148 from hpohl/9904 fix issue 9904 - typeof(null) can be casted to aggregate type if .sizeof equals size of pointer -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10296] Nested template function call and purity inference bug
http://d.puremagic.com/issues/show_bug.cgi?id=10296 Kenji Hara changed: What|Removed |Added Keywords||pull --- Comment #1 from Kenji Hara 2013-06-07 22:15:45 PDT --- https://github.com/D-Programming-Language/dmd/pull/2149 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10296] New: Nested template function call and purity inference bug
http://d.puremagic.com/issues/show_bug.cgi?id=10296
Summary: Nested template function call and purity inference bug
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: rejects-valid
Severity: major
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: k.hara...@gmail.com
--- Comment #0 from Kenji Hara 2013-06-07 22:10:19 PDT ---
This is similar to bug 10288.
Nested function 'bar' accesses to outer scope variable 'a', so it's inferred as
impure. But, 'bar' does not access to variables out of 'foo', so the outer
function 'foo' should be still inferred as pure so calling 'bar' does not break
its purity.
pure void main()
{
foo();
}
void foo()()
{
int[3] a;
void bar()() { a[1] = 2; }
bar();
pragma(msg, typeof(bar!()));// nothrow @safe void()
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8651] Slice op Slice throws exceptions (not errors), and nothrow
http://d.puremagic.com/issues/show_bug.cgi?id=8651 --- Comment #10 from github-bugzi...@puremagic.com 2013-06-07 21:06:08 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/0b560e6ae873a2f519406faadf1806d404937b51 fix Issue 8651 - Slice op Slice throws exceptions (not errors), and nothrow Array ops should work in @safe pure nothrow code https://github.com/D-Programming-Language/dmd/commit/99c0531136b342afc35bafed23d293ec4be7f316 Merge pull request #2141 from 9rnsr/fix8651 Issue 8651 - Slice op Slice throws exceptions (not errors), and nothrow -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7848] pure and nothrow ignored on unittest blocks
http://d.puremagic.com/issues/show_bug.cgi?id=7848 Walter Bright changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7848] pure and nothrow ignored on unittest blocks
http://d.puremagic.com/issues/show_bug.cgi?id=7848 --- Comment #2 from github-bugzi...@puremagic.com 2013-06-07 21:07:56 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/da5c0cfbd5f8e66dd0bbc180c424f3d58686bd4c fix Issue 7848 - pure and nothrow ignored on unittest blocks https://github.com/D-Programming-Language/dmd/commit/21c30ac9dea49cfc234e8f2268efe09a21b630c8 Merge pull request #2142 from 9rnsr/fix7848 Issue 7848 - pure and nothrow ignored on unittest blocks -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8651] Slice op Slice throws exceptions (not errors), and nothrow
http://d.puremagic.com/issues/show_bug.cgi?id=8651 Walter Bright changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10280] CTFE: Circular variable initializers should be detected properly
http://d.puremagic.com/issues/show_bug.cgi?id=10280 --- Comment #1 from github-bugzi...@puremagic.com 2013-06-07 21:01:10 PDT --- Commit pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/222b4786551a3852890fed1f39e7da2d8b800f40 Fix bug 10280 CTFE: Circular variable initializers should be detected properly Use the existing 'inuse' mechanism to detect cycles. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10295] New: nothrow problem in balancedParens called by std.path.globMatch precondition
http://d.puremagic.com/issues/show_bug.cgi?id=10295
Summary: nothrow problem in balancedParens called by
std.path.globMatch precondition
Product: D
Version: D2
Platform: x86
OS/Version: Windows
Status: NEW
Keywords: rejects-valid
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2013-06-07 17:31:54 PDT ---
Problem found by Anthony Goins in D.learn.
import std.path: globMatch;
void main() {
assert(globMatch("foo.bar", "*"));
}
dmd 2.064alpha, the problem is visible only compiling with "-profile":
...\src\phobos\std\path.d(2187): Error: balancedParens is not nothrow
...\src\phobos\std\path.d(2188): Error: balancedParens is not nothrow
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10294] New: Have -cov print the overview/summary line to stdout or stderr
http://d.puremagic.com/issues/show_bug.cgi?id=10294 Summary: Have -cov print the overview/summary line to stdout or stderr Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: pwil3...@bigpond.net.au --- Comment #0 from Peter Williams 2013-06-07 17:25:10 PDT --- It would be handy for developers if the -cov option printed the overview/summary line; e.g.: ordt/sets.d is 100% covered (at the end of the report line) to stdout or stderr. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10293] New: ModuleInfo isn't documented
http://d.puremagic.com/issues/show_bug.cgi?id=10293 Summary: ModuleInfo isn't documented Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: druntime AssignedTo: nob...@puremagic.com ReportedBy: devw...@gmail.com --- Comment #0 from w0rp 2013-06-07 15:49:49 PDT --- It would be nice to have some Ddoc documentation for ModuleInfo. Currently, ModuleInfo is undocumented. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8268] std.datetime unittest asserts
http://d.puremagic.com/issues/show_bug.cgi?id=8268 --- Comment #6 from Dmitry Olshansky 2013-06-07 15:02:59 PDT --- (In reply to comment #5) > > Well this one is no longer a problem > > Really? Cool. I was able to confirm with the preview version that it was > failing and how it was failing at a higher level, but unfortunately, I've > never > gotten around to finishing the job (sorry about that). So, if it works now, > that's great. > > > but see 10173. > > Did you mean issue# 10161? Issue# 10173 is about std.algorithm.remove. Uhm. Yes, sorry the one about a new time zone. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10292] New: Warn against wrong class opEquals signature usage
http://d.puremagic.com/issues/show_bug.cgi?id=10292
Summary: Warn against wrong class opEquals signature usage
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: diagnostic
Severity: enhancement
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2013-06-07 14:42:07 PDT ---
class Foo {
int x;
this(int x) {
this.x = x;
}
bool opEquals(in Foo a) const {
return a.x == this.x;
}
}
void main() {
Foo f1 = new Foo(10);
Foo f2 = new Foo(10);
assert(f1 != f2);
assert(f1.opEquals(f2));
}
/*
This code compiles with no errors nor warnings with dmd 2.064alpha.
Expected something like:
test(6): Warning. Class opEquals should have signature like: override bool
opEquals(Object) const
Here a little more correct opEquals is:
override bool opEquals(Object a) const {
auto fooa = cast(Foo)a;
if (fooa is null)
return false;
return fooa.x == this.x;
}
The compiler needs to give warnings or errors for such cases of wrong
signatures. If you don't write opEquals(Object) it needs to complain. I think
the current situation of silent accepting wrong/useless special methods is not
acceptable in modern language.
(Code adapted from a post by "Namespace" in D.learn).
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10291] New: formattedWrite() to an Appender fails silently after Appender.clear()
http://d.puremagic.com/issues/show_bug.cgi?id=10291
Summary: formattedWrite() to an Appender fails silently after
Appender.clear()
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: ja...@economicmodeling.com
--- Comment #0 from Jared Miller 2013-06-07
14:19:36 PDT ---
After calling clear() on a std.array.Appender, formattedWrite() using that
appender fails silently. Calling the appender's put() method once after a
clear() is a workaround. Tested on DMD 2.062.
Example:
import std.stdio, std.array, std.format, std.string;
void main()
{
// FIRST EXAMPLE: use only put().
auto a = appender!string;
a.put( format("%d", 1) );
writeln(a.data);
a.clear();
// put() after clear() is OK.
a.put( format("%d", 2) );
writeln(a.data);
assert(a.data == "2");
// SECOND EXAMPLE: use only formattedWrite().
auto b = appender!string;
b.reserve(128);
formattedWrite(b, "%d", 1);
writeln(b.data);
assert(b.data == "1");
b.clear();
// formattedWrite() after clear() does not work.
formattedWrite(b, "%d", 2); // <-- FAILS SILENTLY
writeln(b.data); // "" (writes empty string)
assert(b.data == ""); // this should not pass, but it does.
// You have to call put() on appender before formattedWrite() works again.
b.put("");
formattedWrite(b, "%d", 3);
writeln(b.data);
assert(b.data == "3");
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10289] compiler should infer nothrow even if Error is thrown
http://d.puremagic.com/issues/show_bug.cgi?id=10289 --- Comment #2 from github-bugzi...@puremagic.com 2013-06-07 14:02:14 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/9d901dfe36c548bad2f998f23128484d3db1715a fix Issue 10289 - compiler should infer nothrow even if Error is thrown https://github.com/D-Programming-Language/dmd/commit/3077571190226d14c14d96eac1301bb83b403c41 Merge pull request #2145 from 9rnsr/fix10289 Issue 10289 - compiler should infer nothrow even if Error is thrown -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10265] RandomSample fails when passed an InputRange as input
http://d.puremagic.com/issues/show_bug.cgi?id=10265 --- Comment #2 from github-bugzi...@puremagic.com 2013-06-07 12:06:31 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/cbdd14b57b41092d4e75dc11338b14c9d61ebd9e Issue 10265 - RandomSample fails when passed an InputRange as input * Issue fixed by making presence of save() property conditional on input being a ForwardRange. https://github.com/D-Programming-Language/phobos/commit/783902cafb17eed755d185f63ea2bafa63e4f387 Merge pull request #1332 from WebDrake/randomsample-save Issue 10265 - RandomSample fails when passed an InputRange as input -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8268] std.datetime unittest asserts
http://d.puremagic.com/issues/show_bug.cgi?id=8268 --- Comment #5 from Jonathan M Davis 2013-06-07 11:22:30 PDT --- > Well this one is no longer a problem Really? Cool. I was able to confirm with the preview version that it was failing and how it was failing at a higher level, but unfortunately, I've never gotten around to finishing the job (sorry about that). So, if it works now, that's great. > but see 10173. Did you mean issue# 10161? Issue# 10173 is about std.algorithm.remove. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9634] [CTFE] appending a slice of an array of structs to itself
http://d.puremagic.com/issues/show_bug.cgi?id=9634 --- Comment #11 from github-bugzi...@puremagic.com 2013-06-07 10:53:57 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/ed349e1a519e2245c9adc0789deb09350d8511c0 workaround issue 9634 https://github.com/D-Programming-Language/phobos/commit/db7e325f6d4a26294976b8fb9ebc69124d5056bc Merge pull request #1290 from blackwhale/regex-9634 Workaround issue 9634 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10268] std.typecons.Nullable!JSONValue - error instantiating
http://d.puremagic.com/issues/show_bug.cgi?id=10268 Nils changed: What|Removed |Added CC||nilsboss...@googlemail.com Severity|normal |regression -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10290] New: DMD with -m64 doesn't append .exe to -of option
http://d.puremagic.com/issues/show_bug.cgi?id=10290
Summary: DMD with -m64 doesn't append .exe to -of option
Product: D
Version: D2
Platform: All
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: dmitry.o...@gmail.com
--- Comment #0 from Dmitry Olshansky 2013-06-07
04:24:38 PDT ---
It's all in the title.
This:
simple.d
---
void main(){}
---
compiled as
dmd -m64 -ofs64
gives following:
s64
s64.obj
where s64 is indeed the application but without .exe suffix.
dmd -m32 -ofs32
gives the usual:
s32.exe
s32.obj
Seems like a trivial thing but horribly annoying.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10283] ICE(interpret.c): passing struct with failed initalizer to CTFE
http://d.puremagic.com/issues/show_bug.cgi?id=10283 --- Comment #1 from github-bugzi...@puremagic.com 2013-06-07 03:49:11 PDT --- Commit pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/453da5f5619c287c31ddb524884aea8ce70d3fc1 Fix bug 10283 ICE(interpret.c): passing struct with failed initializer to CTFE If a struct literal contains an error field, it's an error. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8268] std.datetime unittest asserts
http://d.puremagic.com/issues/show_bug.cgi?id=8268 Dmitry Olshansky changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Comment #4 from Dmitry Olshansky 2013-06-07 02:45:55 PDT --- Well this one is no longer a problem but see 10173. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 199] Label causes scope to collapse into parent
http://d.puremagic.com/issues/show_bug.cgi?id=199 --- Comment #33 from monarchdo...@gmail.com 2013-06-07 02:08:53 PDT --- (In reply to comment #32) > (In reply to comment #31) > > >> The (imo correct) path is that the NoScopeStatment should still > > >> provide no scope, but emit a deprecated message if anything > > >> declared in the scope is used. > > > > If you're going to go as far as that, why not emit a deprecation message if > > any > > declarations appear in it at all? > > That sounds easier to implement, and IMO is a bit better than deprecating > having a non-empty block after a label. We would also need to deprecate having > scope() statements in a labelled block. Bug 827 would also need a solution. Deprecating having a block after a label is wrong, and so is having a scope statement inside a labeled block. These are valid use cases of code, and both valid according to spec, old and new. Just because something is changing (more so, arguably being fixed), doesn't mean all previous usage of the code was wrong. > comment #30: > > I understand your position, but deprecation really implies that something > > WILL > > be removed, and usage NEEDS to stop. Having something permanently > > deprecated is > > not tenable: there is a compile mode that makes deprecated calls errors, and > > here, it is not an error. > > If a user has chosen to enable deprecation errors, that is their problem IMO. > By default the code would not break. The idea of deprecation is that something is removed, because that specific usage has been decided un-worthy, and usage should stop. This usually comes with an different/superior alternative. The error-on-deprecate are for users that want to keep their code up to date with the latest standard. This is not what we are doing at all. We changed a behavior, but there is nothing wrong with the code, and more importantly, there is no alternative to migrate to. > Note: GTK2 kept its deprecated symbols until GTK3, rather than scheduling > removal at a certain date. Yes, but they *were* scheduled for deprecation, and probably for a good reason. There is no good reason for a user to not use a labeled scope. > Anyway, a limited period of deprecation rather than just changing behaviour > might be a good compromise. Perhaps 2 years? I agree with Stewart, this all out of proportion. For starters, cases where code would actually break are minimal, and contrived. Not only that, but labels aren't something widely used anyways. In particular, I'd *highly* doubt that *anybody* actually explicitly relied on this behavior (or even knew about it...). If anything, the only changes in behavior I would expect are: a) Wrong code stops compiling (a good thing) b) Symbols weren't used anyways, no change c) User *expected* the end of the block to call a destroyer. The silently failing code would now be fixed. I really think the best solution here is just to fix the damn thing and move on. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7378] inout constructors do not properly resolve to immutable.
http://d.puremagic.com/issues/show_bug.cgi?id=7378
Maksim Zholudev changed:
What|Removed |Added
Status|NEW |RESOLVED
CC||maxim...@gmail.com
Resolution||FIXED
--- Comment #1 from Maksim Zholudev 2013-06-07 02:08:30
PDT ---
Since this pull request was merged
https://github.com/D-Programming-Language/dmd/pull/1726
one must specify the qualifier explicitly:
import std.stdio;
struct T
{
int *data;
this(inout(int)* d) inout {this.data = d;}
}
void main()
{
int x;
const int xc;
immutable int xi;
writeln(typeof(T(&x)).stringof);
writeln(typeof(const T(&xc)).stringof);
writeln(typeof(immutable T(&xi)).stringof);
}
So now inout constructors are resolved manually.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7053] inout implicit conversion error
http://d.puremagic.com/issues/show_bug.cgi?id=7053 Maksim Zholudev changed: What|Removed |Added Status|NEW |RESOLVED CC||maxim...@gmail.com Resolution||WORKSFORME --- Comment #1 from Maksim Zholudev 2013-06-07 01:46:36 PDT --- No errors with DMD from GitHub: https://github.com/D-Programming-Language/dmd/commit/ba281aea010b4772c55fcec08a61f7eea8872436 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7222] inout functions cannot use return type inference
http://d.puremagic.com/issues/show_bug.cgi?id=7222 Maksim Zholudev changed: What|Removed |Added Status|NEW |RESOLVED CC||maxim...@gmail.com Resolution||WORKSFORME --- Comment #1 from Maksim Zholudev 2013-06-07 01:39:52 PDT --- Works for DMD from GitHub: https://github.com/D-Programming-Language/dmd/commit/ba281aea010b4772c55fcec08a61f7eea8872436 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10289] compiler should infer nothrow even if Error is thrown
http://d.puremagic.com/issues/show_bug.cgi?id=10289 Kenji Hara changed: What|Removed |Added Keywords||pull --- Comment #1 from Kenji Hara 2013-06-07 01:07:52 PDT --- https://github.com/D-Programming-Language/dmd/pull/2145 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10289] New: compiler should infer nothrow even if Error is thrown
http://d.puremagic.com/issues/show_bug.cgi?id=10289
Summary: compiler should infer nothrow even if Error is thrown
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: k.hara...@gmail.com
--- Comment #0 from Kenji Hara 2013-06-07 01:04:34 PDT ---
Test case:
void foo(E)()
{
throw new E("");
}
void main() nothrow
{
foo!Exception(); // L7
foo!Error(); // L8
}
Output:
test.d(7): Error: foo is not nothrow
test.d(8): Error: foo is not nothrow
test.d(5): Error: function D main 'main' is nothrow yet may throw
L7 is expected, but L8 is not good.
Today, throwing Error object from a nothrow function is allowed. So, foo!Error
should be inferred to nothrow.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
