[Issue 14789] Runtime test reflection is broken
https://issues.dlang.org/show_bug.cgi?id=14789 --- Comment #1 from Dicebot --- It has been broken for several version at least (checked up to 2.066) --
[Issue 14789] New: Runtime test reflection is broken
https://issues.dlang.org/show_bug.cgi?id=14789
Issue ID: 14789
Summary: Runtime test reflection is broken
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: regression
Priority: P1
Component: druntime
Assignee: nob...@puremagic.com
Reporter: pub...@dicebot.lv
// wat.d
import core.runtime;
import std.stdio;
unittest
{
writeln("in test");
assert(false);
}
bool dummyUnitTestRunner()
{
foreach ( m; ModuleInfo )
{
if (m.unitTest !is null)
{
writefln("running tests for %s", m.name);
m.unitTest();
}
}
return true;
}
static this ( )
{
Runtime.moduleUnitTester(&dummyUnitTestRunner);
}
// output:
// running tests for wat
--
[Issue 12056] [CTFE] "couldn't find field" from delegate
https://issues.dlang.org/show_bug.cgi?id=12056 --- Comment #1 from Kenji Hara --- Related issue: 9541 --
[Issue 8862] order of declaration of a function and compile time execution
https://issues.dlang.org/show_bug.cgi?id=8862 Kenji Hara changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #6 from Kenji Hara --- Works with git-head, so I'm sure that it's a duplication of one of already fixed forward reference issue. --
[Issue 7298] global static function and delegate literals
https://issues.dlang.org/show_bug.cgi?id=7298 Kenji Hara changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 7570] Missing error in ctfe for dereferencing a pointer passed as a parameter
https://issues.dlang.org/show_bug.cgi?id=7570 Kenji Hara changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #5 from Kenji Hara --- Seems fixed in 2.067. --
[Issue 14775] core.exception.RangeError@src/rt/aaA.d(861): Range violation
https://issues.dlang.org/show_bug.cgi?id=14775 Jonathan M Davis changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Severity|enhancement |normal --- Comment #1 from Jonathan M Davis --- Fixed in https://github.com/D-Programming-Language/druntime/pull/1273 --
[Issue 14773] druntime unit tests are only run in release mode
https://issues.dlang.org/show_bug.cgi?id=14773 Issue 14773 depends on issue 14774, which changed state. Issue 14774 Summary: core.time.numToString(double) fails its unit tests in non-release mode https://issues.dlang.org/show_bug.cgi?id=14774 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 14773] druntime unit tests are only run in release mode
https://issues.dlang.org/show_bug.cgi?id=14773 Issue 14773 depends on issue 14775, which changed state. Issue 14775 Summary: core.exception.RangeError@src/rt/aaA.d(861): Range violation https://issues.dlang.org/show_bug.cgi?id=14775 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 14774] core.time.numToString(double) fails its unit tests in non-release mode
https://issues.dlang.org/show_bug.cgi?id=14774 Jonathan M Davis changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Jonathan M Davis --- Fixed in https://github.com/D-Programming-Language/druntime/pull/1273 --
[Issue 11414] druntime should run debug unittest
https://issues.dlang.org/show_bug.cgi?id=11414 --- Comment #3 from Jonathan M Davis --- Ah, those were already fixed in https://github.com/D-Programming-Language/druntime/pull/1273 which was merged less than a day ago. So, I guess that my finding those issues was just bad timing. --
[Issue 11414] druntime should run debug unittest
https://issues.dlang.org/show_bug.cgi?id=11414 --- Comment #2 from Jonathan M Davis --- >From some of the testing that I did recently when trying to debug an issue, I found issue# 14774 and issue# 14775, which appear to be blocking this - at least, on my system (FreeBSD 10, 64-bit), those tests always fail when I built druntime without -release, so I would expect them to have to be fixed before running the druntime unit tests without -release will work. --
[Issue 11414] druntime should run debug unittest
https://issues.dlang.org/show_bug.cgi?id=11414 Jonathan M Davis changed: What|Removed |Added CC||issues.dl...@jmdavisprog.co ||m --- Comment #1 from Jonathan M Davis --- *** Issue 14773 has been marked as a duplicate of this issue. *** --
[Issue 14773] druntime unit tests are only run in release mode
https://issues.dlang.org/show_bug.cgi?id=14773 Jonathan M Davis changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Jonathan M Davis --- *** This issue has been marked as a duplicate of issue 11414 *** --
[Issue 14786] The built-in exponentiation operator ^^ sometimes returns a value with the wrong sign.
https://issues.dlang.org/show_bug.cgi?id=14786
--- Comment #5 from Iain Buclaw ---
(In reply to thomas.bockman from comment #4)
> I haven't tested it extensively yet, but here is a fixed version of that
> section:
>
> // Result is real only if y is an integer
> // Check for a non-zero fractional part
> enum real maxPrecise = ulong.max;
> enum real minPrecise = -maxPrecise;
> if (y >= minPrecise && y <= maxPrecise)
> {
> real absY = abs(y);
> ulong w = cast(ulong)absY;
> if (w != absY)
> return sqrt(x); // Complex result -- create a NaN
> if (w & 1) sign = -1.0;
> }
> x = -x;
>
> However, looking at the whole function, I think it would benefit from a
> major refactoring as well. So much duplicated logic...
>
There is no duplicated logic. ;)
--
[Issue 14786] The built-in exponentiation operator ^^ sometimes returns a value with the wrong sign.
https://issues.dlang.org/show_bug.cgi?id=14786
--- Comment #4 from thomas.bock...@gmail.com ---
I haven't tested it extensively yet, but here is a fixed version of that
section:
// Result is real only if y is an integer
// Check for a non-zero fractional part
enum real maxPrecise = ulong.max;
enum real minPrecise = -maxPrecise;
if (y >= minPrecise && y <= maxPrecise)
{
real absY = abs(y);
ulong w = cast(ulong)absY;
if (w != absY)
return sqrt(x); // Complex result -- create a NaN
if (w & 1) sign = -1.0;
}
x = -x;
However, looking at the whole function, I think it would benefit from a major
refactoring as well. So much duplicated logic...
Is that something I should do, or would it mostly likely be rejected on the
basis of, "If it ain't broke, don't fix it"?
--
[Issue 14781] impure delegate to pure function context should be able to modify context
https://issues.dlang.org/show_bug.cgi?id=14781
ag0ae...@gmail.com changed:
What|Removed |Added
CC||ag0ae...@gmail.com
--- Comment #6 from ag0ae...@gmail.com ---
(In reply to Denis Shelomovskij from comment #5)
> Then this function isn't strongly pure anymore:
> ---
> T f() pure;
> ---
> if `T` is `int delegate()`.
>
> Is everybody OK with this?
I think that's already not strongly pure. `int delegate()` has a mutable
indirection in the context pointer. So a function that returns such a delegate
can't be strongly pure.
See
http://klickverbot.at/blog/2012/05/purity-in-d/#indirections_in_the_return_type
An example with the delegate type:
struct S
{
int x = 1;
int method() {return x++;}
}
int delegate() f() pure
{
return &(new S).method;
}
void main()
{
auto dg1 = f();
version(all) auto dg2 = f();
else auto dg2 = dg1; /* This would be equivalent to the above if f were
strongly pure. */
import std.stdio;
writeln(dg1()); /* "1" */
writeln(dg1()); /* "2" */
writeln(dg2()); /* "1" or "3", depending on the version above */
}
--
[Issue 14781] impure delegate to pure function context should be able to modify context
https://issues.dlang.org/show_bug.cgi?id=14781
--- Comment #5 from Denis Shelomovskij ---
(In reply to Steven Schveighoffer from comment #4)
> (In reply to Denis Shelomovskij from comment #3)
>
> > Do you mean this code should compile?
>
> Yes.
>
> > If so, either pure function `bar` can
> > call an impure function or impure delegate is implicitly convertible to a
> > pure one.
>
> No, but I made an error in the example from what I meant.
>
> should be:
>
> auto foo(out int delegate() impureDg) pure {
>
> ...
>
> impureDg = &(bar!());
>
> > If you are opening an issue with an enhancement please provide a clear and
> > concise testcase. Thanks.
>
> It's hard to make a test case that "should compile" without making an error
> with no compiler to help you :D
>
> Really, the issue is that bar doesn't compile, not that the impure delegate
> can't be assigned.
Then this function isn't strongly pure anymore:
---
T f() pure;
---
if `T` is `int delegate()`.
Is everybody OK with this?
--
[Issue 14781] impure delegate to pure function context should be able to modify context
https://issues.dlang.org/show_bug.cgi?id=14781
--- Comment #4 from Steven Schveighoffer ---
(In reply to Denis Shelomovskij from comment #3)
> Do you mean this code should compile?
Yes.
> If so, either pure function `bar` can
> call an impure function or impure delegate is implicitly convertible to a
> pure one.
No, but I made an error in the example from what I meant.
should be:
auto foo(out int delegate() impureDg) pure {
...
impureDg = &(bar!());
> If you are opening an issue with an enhancement please provide a clear and
> concise testcase. Thanks.
It's hard to make a test case that "should compile" without making an error
with no compiler to help you :D
Really, the issue is that bar doesn't compile, not that the impure delegate
can't be assigned.
--
[Issue 14786] The built-in exponentiation operator ^^ sometimes returns a value with the wrong sign.
https://issues.dlang.org/show_bug.cgi?id=14786 --- Comment #3 from Iain Buclaw --- OK, it looks like std.math.pow is only implemented to work with numbers only within the following boundaries. -1.0/real.epsilon < X < 1/real.epsilon I *could* relax this, but we'll need to test raising some random numbers to the power of an integer between long.max and ulong.max. --
[Issue 14781] impure delegate to pure function context should be able to modify context
https://issues.dlang.org/show_bug.cgi?id=14781
Denis Shelomovskij changed:
What|Removed |Added
CC||verylonglogin@gmail.com
--- Comment #3 from Denis Shelomovskij ---
(In reply to Steven Schveighoffer from comment #0)
> In a followup to issue 9148, which made this illegal:
>
> int impureFuncCall() { static int g; return g; }
> auto foo(out int delegate() pure pureDg) pure {
> int x;
> auto bar()() {
> impureFuncCall();
> x = 1; // Error: impure function 'bar' cannot access variable
> 'x'
> // declared in enclosing pure function 'foo'
> }
>
> pureDg = &(bar!());
>
> int dg() pure { return x;}
> return &dg;
> }
>
>
> This should be allowed.
> ...
Do you mean this code should compile? If so, either pure function `bar` can
call an impure function or impure delegate is implicitly convertible to a pure
one.
If you are opening an issue with an enhancement please provide a clear and
concise testcase. Thanks.
--
[Issue 14767] Support CTFE of BigInt
https://issues.dlang.org/show_bug.cgi?id=14767
Ivan Kazmenko changed:
What|Removed |Added
CC||ga...@mail.ru
--- Comment #4 from Ivan Kazmenko ---
Perhaps on x86, the compiler could do something like the following when
instantiating BigInt:
-
if (__ctfe)
{
// use biguintnoasm
}
else
{
// use biguintx86
}
-
--
[Issue 14626] [REG2.066] byValue doesn't work with inout AA
https://issues.dlang.org/show_bug.cgi?id=14626 Kenji Hara changed: What|Removed |Added Depends on||14788 --
[Issue 14788] New: Incorrect rejection of inout function call
https://issues.dlang.org/show_bug.cgi?id=14788
Issue ID: 14788
Summary: Incorrect rejection of inout function call
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Keywords: rejects-valid
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: k.hara...@gmail.com
Blocks: 14626
Following code does not compile, but it should.
auto make(K, V)(inout V[K] aa)
{
static struct Result
{
V[K] aa;
ref front() inout { return aa[1]; }
}
return inout Result(aa);
}
void main()
{
int[int] aa = [1:1];
make(aa).front();// line 14
}
Output:
$ dmd -o- test
test.d(14): Error: modify inout to mutable is not allowed inside inout function
If the 'Result' struct is not static, the error is not wrong. Because the
returned reference by Result.front() may come from the local state of enclosing
'make' function.
However the 'Result' is actually static and it cannot access outer inout
function context. Therefore the compile error is not correct.
This compiler bug is blocking fix for the regression issue 14626.
--
[Issue 12603] [CTFE] goto does not correctly call dtors
https://issues.dlang.org/show_bug.cgi?id=12603 --- Comment #4 from github-bugzi...@puremagic.com --- Commit pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/0b55d6319a63fdc0d088bde7e5062b773f15e73a std.regex: simplify case statement The old issue 12603 is fixed according to the issue tracker. Therefore we try to simplify the case statement as proposed initially. --
[Issue 14787] New: DMD shipps outdated 32-bit ODBC import library
https://issues.dlang.org/show_bug.cgi?id=14787
Issue ID: 14787
Summary: DMD shipps outdated 32-bit ODBC import library
Product: D
Version: D2
Hardware: x86
OS: Windows
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: dmitry.o...@gmail.com
This ODBC test program listed below fails to link due to:
```
Error 42: Symbol Undefined _SQLSetEnvAttr@16
odbc.obj(odbc)
Error 42: Symbol Undefined _SQLAllocHandle@12
--- errorlevel 2
```
x64 version works just fine by using MS SDK libraries.
pragma(lib, "odbc32");
import etc.c.odbc.sql;
import etc.c.odbc.sqlext;
import std.stdio;
int main() {
SQLHENV env;
SQLCHAR driver[256];
SQLCHAR attr[256];
SQLSMALLINT driver_ret;
SQLSMALLINT attr_ret;
SQLUSMALLINT direction;
SQLRETURN ret;
SQLAllocHandle(SQL_HANDLE_ENV, SQL_NULL_HANDLE, &env);
SQLSetEnvAttr(env, SQL_ATTR_ODBC_VERSION, cast(void *) SQL_OV_ODBC3, 0);
direction = SQL_FETCH_FIRST;
while(SQL_SUCCEEDED(ret = SQLDrivers(env, direction,
driver.ptr, driver.sizeof, &driver_ret,
attr.ptr, attr.sizeof, &attr_ret))) {
direction = SQL_FETCH_NEXT;
printf("%s - %s\n", driver.ptr, attr.ptr);
if (ret == SQL_SUCCESS_WITH_INFO) printf("\tdata truncation\n");
}
return 0;
}
--
[Issue 12294] CTFE fails with inherited in contract
https://issues.dlang.org/show_bug.cgi?id=12294 Kenji Hara changed: What|Removed |Added Keywords||pull, rejects-valid --- Comment #2 from Kenji Hara --- https://github.com/D-Programming-Language/dmd/pull/4809 --
[Issue 14781] impure delegate to pure function context should be able to modify context
https://issues.dlang.org/show_bug.cgi?id=14781 Kenji Hara changed: What|Removed |Added Keywords||pull --- Comment #2 from Kenji Hara --- https://github.com/D-Programming-Language/dmd/pull/4808 --
[Issue 4541] Intrinsic functions do not have pointers
https://issues.dlang.org/show_bug.cgi?id=4541 Marc Schütz changed: What|Removed |Added CC||schue...@gmx.net --- Comment #4 from Marc Schütz --- Still in DMD master. See http://forum.dlang.org/post/fyywzedmhacyyaqvg...@forum.dlang.org --
[Issue 13522] Let's use '_' underscore as official ignore value
https://issues.dlang.org/show_bug.cgi?id=13522 --- Comment #6 from Martin Nowak --- There is precedence for this usage in python, haskell and scala. --
[Issue 14779] incorrect addressing of arguments in require/in-contract
https://issues.dlang.org/show_bug.cgi?id=14779 --- Comment #3 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/9e6bc30b0997867d21b794b933cbf822e7d8cfa6 fix Issue 14779 - incorrect addressing of arguments in require/in-contract https://github.com/D-Programming-Language/dmd/commit/971b319e45c4e81825265fdb04363806a76bd4a0 Merge pull request #4803 from 9rnsr/fix14779 [REG] Issue 14779 - incorrect addressing of arguments in require/in-contract --
[Issue 14786] The built-in exponentiation operator ^^ sometimes returns a value with the wrong sign.
https://issues.dlang.org/show_bug.cgi?id=14786
--- Comment #2 from Iain Buclaw ---
This seems to be the correct extract from std.math to look at:
---
5675│ // Result is real only if y is an integer
5676│ // Check for a non-zero fractional part
5677├>if (y > -1.0 / real.epsilon && y < 1.0 / real.epsilon)
5678│ {
5679│ long w = cast(long)y;
5680│ if (w != y)
5681│ return sqrt(x); // Complex result -- create a NaN
5682│ if (w & 1) sign = -1.0;
5683│ }
5684│ x = -x;
---
If 'e = long.max', it is representable, and the (w & 1) check sets sign to
'-1.0'
As instead 'e = long.max + 2', it is not representable, and so the signed-ness
is not adjusted.
Checked result against libm routines, and yes it looks like a bug on our side.
--
[Issue 14782] Internal error: backend/cod1.c
https://issues.dlang.org/show_bug.cgi?id=14782
--- Comment #1 from yazan.dab...@gmail.com ---
Further reduction:
struct Foo
{
void* a;
int b;
}
Foo[1] fun()
{
Foo[1] a;
return a;
}
void main()
{
auto result = fun();
}
--
[Issue 14786] The built-in exponentiation operator ^^ sometimes returns a value with the wrong sign.
https://issues.dlang.org/show_bug.cgi?id=14786 Iain Buclaw changed: What|Removed |Added CC||ibuc...@gdcproject.org Component|druntime|phobos --- Comment #1 from Iain Buclaw --- Moving from druntime to phobos (std.math.pow is the component, unless the compiler was able to fold the operation). --
