[Issue 20766] empty string literals passed as optional parameter should not be 0 terminated
https://issues.dlang.org/show_bug.cgi?id=20766 Simen Kjaeraas changed: What|Removed |Added Status|NEW |RESOLVED CC||simen.kja...@gmail.com Resolution|--- |INVALID --- Comment #2 from Simen Kjaeraas --- Of course the else branch can be executed, just call test(null). Like RazvanN said, "" is not the same as null. --
[Issue 20787] Add module core.sys.darwin.sys.attr with getattrlist, setattrlist, searchfs, and related definitions
https://issues.dlang.org/show_bug.cgi?id=20787 Nathan S. changed: What|Removed |Added Summary|Add module |Add module |core.sys.darwin.sys.attr|core.sys.darwin.sys.attr |with getattrlist, |with getattrlist, |setattrlist, and related|setattrlist, searchfs, and |definitions |related definitions --
[Issue 20785] std.file.setTimes: on macOS use setattrlist to avoid truncating timestamp precision to microseconds
https://issues.dlang.org/show_bug.cgi?id=20785 Nathan S. changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=20787 --
[Issue 20787] Add module core.sys.darwin.sys.attr with getattrlist, setattrlist, and related definitions
https://issues.dlang.org/show_bug.cgi?id=20787 Nathan S. changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=20785 --
[Issue 20787] New: Add module core.sys.darwin.sys.attr with getattrlist, setattrlist, and related definitions
https://issues.dlang.org/show_bug.cgi?id=20787 Issue ID: 20787 Summary: Add module core.sys.darwin.sys.attr with getattrlist, setattrlist, and related definitions Product: D Version: D2 Hardware: All OS: Mac OS X Status: NEW Severity: enhancement Priority: P1 Component: druntime Assignee: nob...@puremagic.com Reporter: n8sh.second...@hotmail.com For use in issue #20785. --
[Issue 13567] Attribute inference for private functions
https://issues.dlang.org/show_bug.cgi?id=13567 Steven Schveighoffer changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=20786 --
[Issue 20786] do attribute inference for all nested functions
https://issues.dlang.org/show_bug.cgi?id=20786 Steven Schveighoffer changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=13567 --
[Issue 20786] New: do attribute inference for all nested functions
https://issues.dlang.org/show_bug.cgi?id=20786 Issue ID: 20786 Summary: do attribute inference for all nested functions Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: schvei...@yahoo.com All nested functions have available source for the compiler, so there is no reason not to infer attributes. This already happens inside @safe functions, it makes no sense for it not to happen for all nested functions. Note the post from Walter here: https://forum.dlang.org/post/r75q88$182b$1...@digitalmars.com Also, this is related to issue 13567, but it's slightly different, and there is better precedent. --
[Issue 20785] std.file.setTimes: on macOS use setattrlist to avoid truncating timestamp precision to microseconds
https://issues.dlang.org/show_bug.cgi?id=20785 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #1 from Dlang Bot --- @n8sh created dlang/phobos pull request #7466 "std.file.setTimes: on macOS use setattrlist to avoid truncating timestamp precision to microseconds" fixing this issue: - Fix Issue 20785 - std.file.setTimes: on macOS use setattrlist to avoid truncating timestamp precision to microseconds https://github.com/dlang/phobos/pull/7466 --
[Issue 20785] New: std.file.setTimes: on macOS use setattrlist to avoid truncating timestamp precision to microseconds
https://issues.dlang.org/show_bug.cgi?id=20785 Issue ID: 20785 Summary: std.file.setTimes: on macOS use setattrlist to avoid truncating timestamp precision to microseconds Product: D Version: D2 Hardware: All OS: Mac OS X Status: NEW Severity: normal Priority: P1 Component: phobos Assignee: nob...@puremagic.com Reporter: n8sh.second...@hotmail.com This was brought to my attention by a unit test in https://github.com/CyberShadow/ae/blob/master/sys/persistence/core.d that was failing on macOS because it was storing a result of `timeLastModified` then using the stored value as an argument to `setTimes` and expecting that the next call to `timeLastModified` would yield the same result as the stored value. The problem is that on macOS std.file uses hecto-nanosecond precision (converted from nanosecond) when reading file access/modification times but only uses microsecond precision when writing them. This is because core.sys.posix.sys.stat does not have `utimensat` for macOS, which is because it only became available in macOS starting from version 10.13 which was released in 2017. As an alternative `setattrlist` can be used with any version of macOS to set timestamps with the same precision as `utimensat`. --
[Issue 20766] empty string literals passed as optional parameter should not be 0 terminated
https://issues.dlang.org/show_bug.cgi?id=20766 RazvanN changed: What|Removed |Added CC||razvan.nitu1...@gmail.com --- Comment #1 from RazvanN --- I don't understand why this is a problem. I think that this is the intendend behavior; an empty string is not a null pointer. --
[Issue 6401] infinite loop with -inline in gflow.c:accumaecpx
https://issues.dlang.org/show_bug.cgi?id=6401 safety0ff.bugz changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=19550 --
[Issue 19550] [REG 2.078] Massive compiler backend slowdown
https://issues.dlang.org/show_bug.cgi?id=19550 safety0ff.bugz changed: What|Removed |Added CC||safety0ff.b...@gmail.com See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=6401, ||https://issues.dlang.org/sh ||ow_bug.cgi?id=7157 --- Comment #5 from safety0ff.bugz --- I ran the test code through callgrind and `accumaecpx` gets called 6.155 million times. Adding issues #6401 and #7157 to the see also list. --
[Issue 7157] Optimiser is O(n^2) w.r.t. function length
https://issues.dlang.org/show_bug.cgi?id=7157 safety0ff.bugz changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=19550 --
[Issue 20784] New: Assert expression specification needs to be updated
https://issues.dlang.org/show_bug.cgi?id=20784 Issue ID: 20784 Summary: Assert expression specification needs to be updated Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: minor Priority: P1 Component: dlang.org Assignee: nob...@puremagic.com Reporter: andrej.mitrov...@gmail.com https://dlang.org/spec/expression.html#assert_expressions > The first AssignExpression must evaluate to true. If it does not, an Assert > Failure has occurred and the program enters an Invalid State. > Undefined Behavior: Once in an Invalid State the behavior of the continuing > execution of the program is undefined. This in theory is true. And https://github.com/dlang/dmd/pull/6896, if merged, would actually make it really true. (It would be great if we got some progress on that PR). However see my next comment: > Do not attempt to resume normal execution after an Assert Failure. But then what is the point of `Runtime.extendedModuleUnitTester`? If an application enters an Invalid state then after the very first assertion failure it wouldn't make sense to continue running tests in other modules. But Druntime explicitly supports this feature.. > AssertExpression has different semantics if it is in a unittest or in > contract. The documentation doesn't actually list what the differences are. But maybe it should just link to the contracts page? --
[Issue 20783] std.string.lastIndexOf doesn't work correctly in CTFE
https://issues.dlang.org/show_bug.cgi?id=20783 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #1 from Dlang Bot --- @wolframw created dlang/phobos pull request #7465 "Fix Issue 20783 - std.string.lastIndexOf doesn't work correctly in CTFE" fixing this issue: - Fix Issue 20783 - std.string.lastIndexOf doesn't work correctly in CTFE https://github.com/dlang/phobos/pull/7465 --
[Issue 13292] DMD accepts both -m32 and -m64
https://issues.dlang.org/show_bug.cgi?id=13292 Mathias LANG changed: What|Removed |Added Status|NEW |RESOLVED CC||pro.mathias.l...@gmail.com Resolution|--- |WONTFIX --- Comment #2 from Mathias LANG --- As mentioned in the PR open by @woframw, this is actually not something we want. It's a common behavior of CLI to allow args to be overridden, and just take the last one into account. We have some switch that follow this behavior already (checkaction), and we rely on this behavior in our testsuite. Closing as WONTFIX. --
[Issue 20782] std.conv.to can't convert string to const enum
https://issues.dlang.org/show_bug.cgi?id=20782
Dlang Bot changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #2 from Dlang Bot ---
dlang/phobos pull request #7464 "Fix issue 20782 - allow std.conv.to to convert
string to const enum" was merged into master:
- 46933cf73ed7a127c4657f418280938e3d1bbd80 by Atila Neves:
Fix issue 20782 - allow std.conv.to to convert string to const enum
The commit allows the following code to compile:
enum Enum { oops }
"foo".to!(const Enum);
https://github.com/dlang/phobos/pull/7464
--
[Issue 20783] New: std.string.lastIndexOf doesn't work correctly in CTFE
https://issues.dlang.org/show_bug.cgi?id=20783
Issue ID: 20783
Summary: std.string.lastIndexOf doesn't work correctly in CTFE
Product: D
Version: D2
Hardware: x86_64
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: phobos
Assignee: nob...@puremagic.com
Reporter: chalu...@gmail.com
```
pragma(msg, "aa".lastIndexOf("ab"));
```
Returns 0 instead of -1.
Problem seems to be with:
https://github.com/dlang/phobos/blob/ffca395ed2e9fd31cdb8e3e67adb8ddfba2607ac/std/string.d#L1345
as it continues foreach loop that should be stopped and instead upper for loop
should continue with next character.
--
[Issue 20779] Segfault when self-containing struct is accessed from inside in a __traits(compiles) context
https://issues.dlang.org/show_bug.cgi?id=20779 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Dlang Bot --- dlang/dmd pull request #11070 "Fix issue 20779: compiler segfaults when struct contains itself" was merged into stable: - cf4c82efdadfc74c1973f66a16254ec886380c20 by Mathis Beer: Fix issue 20779: compiler segfaults when struct contains itself When working with metaprogramming, the error message saying that the struct should not contain itself can get swallowed by gagging. In this case, only the segfault remains, leading to an unsatisfactory user experience. Fix the segfault by breaking the infinite recursion. https://github.com/dlang/dmd/pull/11070 --
[Issue 20780] Function parameter UDA not accepted in nested function declarations
https://issues.dlang.org/show_bug.cgi?id=20780 --- Comment #3 from Basile-z --- Created attachment 1780 --> https://issues.dlang.org/attachment.cgi?id=1780=edit patch for the bug --
[Issue 20780] Function parameter UDA not accepted in nested function declarations
https://issues.dlang.org/show_bug.cgi?id=20780
--- Comment #2 from Basile-z ---
forgott to rename last test func
---
void main()
{
struct A;
struct B { struct CD;}
alias V = void;
alias I = int;
Vtest0(@A I){}
Vtest1(@A @(B) I) {}
Vtest2(@(B.CD) @B I){}
Vtest3(@A I, @B @A I) {}
Vtest4(@A I, @(B.CD) @A I) {}
}
---
--
[Issue 20782] std.conv.to can't convert string to const enum
https://issues.dlang.org/show_bug.cgi?id=20782
Dlang Bot changed:
What|Removed |Added
Keywords||pull
--- Comment #1 from Dlang Bot ---
@atilaneves created dlang/phobos pull request #7464 "Fix issue 20782 - allow
std.conv.to to convert string to const enum" fixing this issue:
- Fix issue 20782 - allow std.conv.to to convert string to const enum
The commit allows the following code to compile:
enum Enum { oops }
"foo".to!(const Enum);
https://github.com/dlang/phobos/pull/7464
--
[Issue 20782] New: std.conv.to can't convert string to const enum
https://issues.dlang.org/show_bug.cgi?id=20782
Issue ID: 20782
Summary: std.conv.to can't convert string to const enum
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: normal
Priority: P1
Component: phobos
Assignee: nob...@puremagic.com
Reporter: atila.ne...@gmail.com
-
import std.conv: to;
enum Enum { oops }
"foo".to!(const Enum); // doesn't compile
-
--
[Issue 20781] Can call @live function without checking dip1021 rules
https://issues.dlang.org/show_bug.cgi?id=20781 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #1 from Dlang Bot --- @WalterBright created dlang/dmd pull request #11071 "fix Issue 20781 - Can call @live function without checking dip1021 rules" fixing this issue: - fix Issue 20781 - Can call @live function without checking dip1021 rules https://github.com/dlang/dmd/pull/11071 --
[Issue 20780] Function parameter UDA not accepted in nested function declarations
https://issues.dlang.org/show_bug.cgi?id=20780
--- Comment #1 from Basile-z ---
Better TC:
---
void main()
{
struct A;
struct B { struct CD;}
alias V = void;
alias I = int;
Vtest0(@A I){}
Vtest1(@A @(B) I) {}
Vtest2(@(B.CD) @B I){}
Vtest3(@A I, @B @A I) {}
Vtest3(@A I, @(B.CD) @A I) {}
}
---
--
[Issue 20781] Can call @live function without checking dip1021 rules
https://issues.dlang.org/show_bug.cgi?id=20781 Walter Bright changed: What|Removed |Added Keywords||live --
[Issue 20781] New: Can call @live function without checking dip1021 rules
https://issues.dlang.org/show_bug.cgi?id=20781
Issue ID: 20781
Summary: Can call @live function without checking dip1021 rules
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: bugzi...@digitalmars.com
The following should give an error, even when DIP1021 is not set, as calling
@live functions with multiple pointers to the same memory object should not be
allowed.
void test() {
int a;
foo(a, a);
}
@live int foo(ref int a, ref int b);
--
[Issue 20780] Function parameter UDA not accepted in nested function declarations
https://issues.dlang.org/show_bug.cgi?id=20780 Basile-z changed: What|Removed |Added Summary|Function parameter UDA are |Function parameter UDA not |not accepted in nested |accepted in nested function |function declarations |declarations --
[Issue 20780] New: Function parameter UDA are not accepted in nested function declarations
https://issues.dlang.org/show_bug.cgi?id=20780
Issue ID: 20780
Summary: Function parameter UDA are not accepted in nested
function declarations
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: b2.t...@gmx.com
See https://forum.dlang.org/thread/gbxpopfbibdmuxffy...@forum.dlang.org
test case
---
void main()
{
struct A;
struct B;
alias V = void;
alias I = int;
Vtest0(@A I){}
Vtest1(@A @(B) I) {}
Vtest2(@A @B I) {}
}
---
--
[Issue 20779] Segfault when self-containing struct is accessed from inside in a __traits(compiles) context
https://issues.dlang.org/show_bug.cgi?id=20779 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #1 from Dlang Bot --- @FeepingCreature created dlang/dmd pull request #11070 "Fix issue 20779: compiler segfaults when struct contains itself" fixing this issue: - Fix issue 20779: compiler segfaults when struct contains itself When working with metaprogramming, the error message saying that the struct should not contain itself can get swallowed by gagging. In this case, only the segfault remains, leading to an unsatisfactory user experience. Fix the segfault by breaking the infinite recursion. https://github.com/dlang/dmd/pull/11070 --
[Issue 20779] New: Segfault when self-containing struct is accessed from inside in a __traits(compiles) context
https://issues.dlang.org/show_bug.cgi?id=20779
Issue ID: 20779
Summary: Segfault when self-containing struct is accessed from
inside in a __traits(compiles) context
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: minor
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: default_357-l...@yahoo.de
Consider this code:
struct X {
X x;
enum e = __traits(compiles, X.init);
}
DMD tries to warn us that X cannot contain itself as a field; however, the
error is eaten by the __traits(compiles). Then it segfaults.
--
