[Issue 17959] [DIP1000] Can store scope delegate in non-scope member

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17959

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com

--- Comment #1 from Walter Bright  ---
https://github.com/dlang/dmd/pull/8008

--

[Issue 18024] checkedint.Abort should be @safe

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18024

Seb  changed:

   What|Removed |Added

Summary|checkedint.Warn should be   |checkedint.Abort should be
   |@safe   |@safe

--

[Issue 15653] IFTI fails for immutable parameter

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15653

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

[Issue 15653] IFTI fails for immutable parameter

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15653

--- Comment #2 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/d68e181bda060f8e61253620695a3aadf0ad1093
Fix issue 15653 - IFTI fails for immutable parameter

https://github.com/dlang/dmd/commit/5fa45d1a355b5bd24caaeddf71b21d94561c3174
Add links to bugzilla for issue 15653

https://github.com/dlang/dmd/commit/25fbcbe2baaf085e679bc281954b208e076d7471
Merge pull request #7977 from JinShil/fix_15653

Fix issue 15653 - IFTI fails for immutable parameter
merged-on-behalf-of: Sebastian Wilzbach 

--

[Issue 17449] [DIP1000] crash due to covariant conversion of scope delegate to delegate

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17449

ag0ae...@gmail.com changed:

   What|Removed |Added

 CC||ag0ae...@gmail.com

--- Comment #9 from ag0ae...@gmail.com ---
(In reply to Rainer Schuetze from comment #8)
> As with the modified reduced test case with @safe, this is still crashing
> for me (Win32 and Win64 with git HEAD). Checking the disassembly for
> compiling with -dip1000 it doesn't generate the closure that it is
> generating without the switch.

If it still crashes, did you mean to reopen this issue? (You changed it from
WORKSFORME to FIXED.)

--

[Issue 17449] [DIP1000] crash due to covariant conversion of scope delegate to delegate

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17449

Rainer Schuetze  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #10 from Rainer Schuetze  ---
I didn't mean to change the status, but reopening is probably appropriate.

--

[Issue 17932] [scope] __traits(compiles, stmt) cannot test scope violations

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17932

Walter Bright  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Walter Bright  ---
Adding @safe to the lambda:

  void test() @safe
  {
int var;
scope int* p;
static int* escape;
static assert(!__traits(compiles, () @safe { escape = p; }));
  //escape = p;
  }

and it compiles without error. The lambda does not inherit @safe from the
function. Perhaps it should, but that would be an enhancement request, and
would possibly break existing code. It should be the subject of a separate
issue.

--

[Issue 17448] Move semantics cause memory corruption and cryptic bugs

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17448

--- Comment #35 from Walter Bright  ---
(In reply to Shachar Shemesh from comment #33)
> You cannot be notified when the object
> moves, and once it does, the global linked list will get completely
> corrupted.

That is correct, and you are right to be concerned about it.

However, from a pragmatic point of view, the compiler cannot move objects that
have external pointers to them (unless it can unambiguously find them all and
update them). This is why, for example, there is an API in the GC to register
pointers to objects that are unknown to the GC.

Why was it moving the stack allocated objects in these examples? Because when
it went out of scope, it is safe to assume that there are no extant pointers to
it. This is why the compiler (now) complains when the code registers a pointer
to the stack object. Of course, making the code @trusted enables code like this
to be written, leaving it up to the programmer to ensure the safety.

But there's another wrinkle. With RVO (Return Value Optimization), if the stack
object is returned, and it is not returned in registers, it is actually not
returned. It is allocated in the caller's stack frame! and is not moved. This
is now the case with all the examples you've provided.

So, to guarantee RVO:

1. the object must be returned on the stack, not in registers. This can be
tested as shown in the documentation:

  https://dlang.org/spec/traits.html#isReturnOnStack

Generally speaking, a struct that is larger than two registers, or is not POD
(Plain Old Data), will return on the stack and not in registers.

2. use only one return statement in the function. Having multiple returns can
defeat RVO.

3. do not pass the object as a parameter to other functions, as the compiler
may 'move' it onto the parameter stack if there are no more references to the
object. If you must pass it as a parameter, pass it by `ref`.

Objects can also be constructed directly into their final destination by
passing them as `out` parameters.

Obviously, I am not familiar with your code and usage patterns. But the above
ought to offer some hope (!) for getting your code working properly. If there
are more pernicious problems with moving that aren't covered by this, please
let me know. Perhaps I can think of a solution.

--

[Issue 17449] [DIP1000] crash due to covariant conversion of scope delegate to delegate

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17449

Walter Bright  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #7 from Walter Bright  ---
Fixing the code with @safe and @trusted:

---
module test;

@safe:
struct Event9834
{
  @safe:
void delegate() dg;
void set(void delegate() @safe h) pure { dg = h; }  // AV occurs
void call() { dg(); }
}

void main()
{
Event9834 ev;
auto a = new class
{
Object o;
this() @safe
{
o = new Object;
ev.set(() @trusted { o.toString(); });
}
};
ev.call();
}
---

and it compiles and runs without error, with or without -dip1000.

--

[Issue 17961] std.uni does not compile with -unittest -dip1000

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17961

Carsten Blüggel  changed:

   What|Removed |Added

 Blocks||18585


Referenced Issues:

https://issues.dlang.org/show_bug.cgi?id=18585
[Issue 18585] Linker error if compiled with -dip1000
--

[Issue 18585] Linker error if compiled with -dip1000

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18585

Carsten Blüggel  changed:

   What|Removed |Added

   Keywords||rejects-valid, safe
 CC||chi...@posteo.net
 Depends on||17961

--- Comment #1 from Carsten Blüggel  ---
The origin of errors seems to be, that std.uni is not -dip1000 compilable
currently.


Referenced Issues:

https://issues.dlang.org/show_bug.cgi?id=17961
[Issue 17961] std.uni does not compile with -unittest -dip1000
--

[Issue 17449] [DIP1000] crash due to covariant conversion of scope delegate to delegate

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17449

--- Comment #5 from Rainer Schuetze  ---
>  This is because 'scope' for delegates now means something with dip1000, it 
> means the delegate must not escape.

There is no "scope" in the test cases. I suspect it is falsely inferred.

--

[Issue 17423] pointer assignment to `this` in member function is not accounted for

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17423

--- Comment #8 from Walter Bright  ---
(In reply to Walter Bright from comment #7)
> https://github.com/dlang/dmd/pull/7999

For this to work, -dip1000 must be used.

--

[Issue 18282] [Scope][DIP1000]Assignment of local variable to `scope` variable not recognized by compiler

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18282

Walter Bright  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||bugzi...@digitalmars.com
 Resolution|--- |INVALID

--- Comment #1 from Walter Bright  ---
(In reply to Mike Franklin from comment #0)
> void main() @safe
> {
> string foo = "foo";
> scope string*[] ls;
> ls ~= 
> }
> 
> Compile with `-dip1000`
> 
> onlineapp.d(5): Error: reference to local variable foo assigned to non-scope
> ls

While ls is scope, ls[] is not scope. Scope is not transitive, hence the
compiler error.


> The compiler doesn't seem to recognize that ls is attributed with `scope`. 
> However due to the way D's attributes are parsed, I'm not sure if it should
> actually be `scope string*[]`, `scope(string*)[]`, or `scope(string*[])`. 
> Anyway, if you use `scope()` (i.e. with parens) the compiler confuses it
> with `scope(exit)` and friends.
> 
> 
> void main() @safe
> {
> string foo = "foo";
> scope(string*[]) ls;
> ls ~= 
> }
> 
> Compile with `-dip1000`
> 
> onlineapp.d(4): Error: valid scope identifiers are exit, failure, or
> success, not string

Scope is a storage class, not a type constructor. (`const`, for example, is a
type constructor, and `static` is a storage class.)

--

[Issue 18593] New: std.datetime.stopwatch.benchmark shouldn't optimize away its functions

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18593

  Issue ID: 18593
   Summary: std.datetime.stopwatch.benchmark shouldn't optimize
away its functions
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Keywords: pull
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: greensunn...@gmail.com

See: https://github.com/dlang/phobos/pull/5416

--

[Issue 17764] [scope][DIP1000] Escape checker defeated by composition transformations

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17764

Walter Bright  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #3 from Walter Bright  ---
The following remain:

---
@safe:
struct Context0x0 { char[]   str; }

struct Parent0x1 { Context0x0  c; }
struct Parent0x2 { Context0x0[1] csa; }
struct Parent0x3 { Context0x0[]  csl; }
struct Parent0x4 { Context0x0*cp; }

struct Parent0x5 { Parent0x1  p1; }
struct Parent0x6 { Parent0x5  p5; }
struct Parent0x7 { Parent0x6  p6; }

struct Parent0x8 { Parent0x2[1]*  p2; }
struct Parent0x9 { Parent0x8[1]   p8; }
struct Parent0xA { Parent0x9[1]   p9; }

struct Parent0xB { Parent0x4* p4; }
struct Parent0xC { Parent0xB* pb; }
struct Parent0xD { Parent0xC* pc; }

char[] global;

void use0x2(scope char[]* arr)
{
global = *arr; // NG - accepts invalid
}

void use0x9(scope ref Parent0x4 p)
{
global = p.cp.str; // NG - accepts invalid
}

void use0xB(scope ref Parent0xA p)
{
global = (*p.p9[0].p8[0].p2)[0].csa[0].str; // NG - accepts invalid
}

void use0xC(scope ref Parent0xD p)
{
global = p.pc.pb.p4.cp.str; // NG - accepts invalid
}
---

All of them are instances of transitive scope, but scope is not transitive. Not
compiler bugs.

--

[Issue 18594] constant 1 is not an lvalue should have a better error message

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18594

--- Comment #1 from Seb  ---
(PR incoming)

--

[Issue 18594] New: constant 1 is not an lvalue should have a better error message

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18594

  Issue ID: 18594
   Summary: constant 1 is not an lvalue should have a better error
message
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: greensunn...@gmail.com

---
void main() {
assert(1 = 2);
}
---

currently errors with "foo.d(2): Error: constant 1 is not an lvalue".
The error message should be better: (1) not mention lvalue and (2) suggesting
`==`.

--

[Issue 17449] [DIP1000] crash due to covariant conversion of scope delegate to delegate

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17449

Rainer Schuetze  changed:

   What|Removed |Added

 Resolution|WORKSFORME  |FIXED

--- Comment #8 from Rainer Schuetze  ---
> Fixing the code with @safe and @trusted:

As with the modified reduced test case with @safe, this is still crashing for
me (Win32 and Win64 with git HEAD). Checking the disassembly for compiling with
-dip1000 it doesn't generate the closure that it is generating without the
switch.

--

[Issue 18594] X is not an lvalue should have a better error message

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18594

Seb  changed:

   What|Removed |Added

Summary|constant 1 is not an lvalue |X is not an lvalue should
   |should have a better error  |have a better error message
   |message |

--

[Issue 17449] [DIP1000] crash due to covariant conversion of scope delegate to delegate

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17449

--- Comment #6 from Rainer Schuetze  ---
> Adding more @safe Makes it compile and run successfully.

Your safe code also fails with -dip1000. (tried on Windows/OMF).

--

[Issue 17512] [REG 2.073] [DIP1000] Error on bad interplay of 'auto ref' and 'return' attribute deduction.

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17512

--- Comment #5 from Walter Bright  ---
https://github.com/dlang/dmd/pull/8001

--

[Issue 17449] [DIP1000] crash due to covariant conversion of scope delegate to delegate

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17449

--- Comment #11 from Rainer Schuetze  ---
BTW: AFAIK -dip1000 is only supposed to affect @safe code, but there is no
@safe in the original test cases.

--

[Issue 18592] New: Associative array assignment with a destructor should be @safe if the destructor is @safe

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18592

  Issue ID: 18592
   Summary: Associative array assignment with a destructor should
be @safe if the destructor is @safe
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: greensunn...@gmail.com

cat > main.d << EOF
void main() @safe
{
struct ThrowingElement
{
int i;
~this()
{
assert(1);
}
}

ThrowingElement[int] aa;
aa[0] = ThrowingElement(0);
}
EOF


The problem is that the generated opAssign is @system:

ref return @system ThrowingElement opAssign(ThrowingElement p)
{
(ThrowingElement __swap2 = void;) , __swap2 = this , this = p ,
__swap2.~this();
return this;
}

--

[Issue 18592] Associative array assignment with a destructor should be @safe if the destructor is @safe

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18592

Seb  changed:

   What|Removed |Added

   Keywords||safe

--

[Issue 18000] [scope] auto-generated opAssign not scope aware

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18000

--- Comment #1 from Walter Bright  ---
Attributes are inferred for the generated opAssign, the result looks like:

   @nogc ref return @trusted File opAssign(File p)

Not sure why scope is not inferred.

In any case, the example has problems as well:

scope File f;
f = File();

The lifetime of File() is less than that of f, so this example should fail to
compile for that reason. https://issues.dlang.org/show_bug.cgi?id=17977
addresses that.

--

[Issue 18519] freebsd 11 + phobos + curl, timing out

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18519

Seb  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #5 from Seb  ---
REOPENED as I just tested the PR with https://github.com/dlang/phobos/pull/6264
and the problem still seems to be existent.

--

[Issue 18591] DMD should allow access to mixin template declarations

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18591

--- Comment #1 from github-bugzi...@puremagic.com ---
Commit pushed to master at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/786bdb338a64fa52b24ab515edf6706b259447de
Fix Issue 18591 - Allow getting type from template declarations.

--

[Issue 18591] New: DMD should allow access to mixin template declarations

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18591

  Issue ID: 18591
   Summary: DMD should allow access to mixin template declarations
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: greensunn...@gmail.com

https://github.com/dlang/dmd/pull/7973

--

[Issue 18547] Win32: throwing exception in fiber crashes application

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18547

--- Comment #2 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/druntime

https://github.com/dlang/druntime/commit/a1a5ad8d70464534228839ad8f1f2a7938cb9524
fix issue 18547 - Win32: throwing exception in fiber crashes application

increase the default stack size because exception handling might need up to
16k. The actually used stack can depend on the version of DbgHelp.dll, the
existence of debug information and possibly other conditions.

https://github.com/dlang/druntime/commit/86cd40a036a67d9b1bff6c14e91cba1e5557b119
Merge pull request #2129 from rainers/issue18547

fix issue 18547 - Win32: throwing exception in fiber crashes application
merged-on-behalf-of: Petar Kirov 

--

[Issue 18547] Win32: throwing exception in fiber crashes application

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18547

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

[Issue 18519] freebsd 11 + phobos + curl, timing out

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18519

--- Comment #4 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/b8e5bca94b661c1d1ffb9ec6f7e37b9fa7a0d09d
fix issue 18519 freebsd 11 + phobos + curl, timing out

stop the TestServer waiting in accept() before thread_joinall

https://github.com/dlang/phobos/commit/35e9807bbec392658ecdc8b4ed93d1f6c02f2845
Merge pull request #6234 from rainers/curl_freeze

fix issue 18519 freebsd 11 + phobos + curl, timing out
merged-on-behalf-of: Petar Kirov 

--

[Issue 18537] Cannot pass absolute path to coverage options

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18537

--- Comment #2 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/druntime

https://github.com/dlang/druntime/commit/feb6e9b2f035f2b564765120e6fb794abfd53622
fix Issue 18537 - Cannot pass absolute path to coverage options

allow DRT arguments to include '=' or ':', splitting is done by ' '

https://github.com/dlang/druntime/commit/ab14e9af2b9f4bbea00d543fe229047ede4dd909
Merge pull request #2120 from rainers/issue18537

fix Issue 18537 - Cannot pass absolute path to coverage options

--

[Issue 18590] New: nothrow constructor call still type-checks destructor for purity

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18590

  Issue ID: 18590
   Summary: nothrow constructor call still type-checks destructor
for purity
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: c...@dawg.eu

cat > bug.d << CODE
extern(C) int printf(const char*, ...);

struct F
{
static F create() pure nothrow
{
return F(1);
}

this(int) pure nothrow
{
}

~this()
{
printf("~this\n");
}
}
CODE
dmd -c bug

Error: pure function 'bug.F.create' cannot call impure function 'bug.F.~this'


Apparently happens because `F(1)` is lowered to `(tmp = F(1)),tmp` internally.
https://github.com/dlang/dmd/blob/93804714c4091a8d867c09ca7b5bf332acb34dfb/src/dmd/expression.d#L3931

--

[Issue 17819] static foreach segfaults on __traits(allMembers)

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17819

bitter.ta...@gmx.com changed:

   What|Removed |Added

 CC||bitter.ta...@gmx.com

--- Comment #3 from bitter.ta...@gmx.com ---
There's a stack overflow in Dsymbol's _foreach, every time it recurses into a
AttribDeclaration (such as the `static foreach') the stack gets deeper until it
explodes.

--

[Issue 18549] name gets overwritten in template definition

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18549

Johannes Nordhoff  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |INVALID

--- Comment #3 from Johannes Nordhoff  ---
ah, sorry, i get it. sorry

--

[Issue 18158] std.file.getcwd should be usable in @safe

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18158

--- Comment #1 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/767d1c51d4ae2e24c9d1752db4c1f1b881a3b658
Fix Issue 18158 - std.file.getcwd should be usable in @safe

https://github.com/dlang/phobos/commit/ba11d630a02345fa634d098694273f145fc5428f
Merge pull request #6252 from JackStouffer/issue18158

Fix Issue 18158 - std.file.getcwd should be usable in @safe
merged-on-behalf-of: Jack Stouffer 

--

[Issue 18126] [internal] Reduce number of turned off warnings.

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18126

Iain Buclaw  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from Iain Buclaw  ---
This was implemented in https://github.com/dlang/dmd/pull/7958

--

[Issue 18110] most of phobos should be @safe-ly useable

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18110
Issue 18110 depends on issue 18158, which changed state.

Issue 18158 Summary: std.file.getcwd should be usable in @safe
https://issues.dlang.org/show_bug.cgi?id=18158

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

[Issue 18178] std.path should be usable in @safe

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18178
Issue 18178 depends on issue 18158, which changed state.

Issue 18158 Summary: std.file.getcwd should be usable in @safe
https://issues.dlang.org/show_bug.cgi?id=18158

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

[Issue 18158] std.file.getcwd should be usable in @safe

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18158

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

[Issue 18549] name gets overwritten in template definition

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18549

Johannes Nordhoff  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |---

--- Comment #2 from Johannes Nordhoff  ---
> > the compiler was using the same name for multiple
> > template-definitions.
>
> I don't understand what you mean by this. If you still think the compiler 
> should do something differently here, please feel free to reopen.
>

yeah, the error message should say:

sth.d(11): Error: sth.tmpl called with argument types () matches both:
sth.d(6): sth.tmpl!(SS).tmpl()
and:
sth.d(7): sth.tmpl!(tt).tmpl()


but instead it says:

sth.d(11): Error: sth.tmpl called with argument types () matches both:
sth.d(6): sth.tmpl!(SS).tmpl()
and:
sth.d(7): sth.tmpl!(SS).tmpl()


--

[Issue 18182] std.uri should be usable in @safe

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18182

--- Comment #1 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/9d44d7c13fc312bc39669df441f8b931789471c1
Fix Issue 18182 - std.uri should be usable in @safe

https://github.com/dlang/phobos/commit/8ec15a80ff844bd3457939cb4662952f736e7f50
Merge pull request #6256 from JackStouffer/issue18182

Fix Issue 18182 - std.uri should be usable in @safe
merged-on-behalf-of: Jack Stouffer 

--

[Issue 18182] std.uri should be usable in @safe

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18182

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

[Issue 18110] most of phobos should be @safe-ly useable

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18110
Issue 18110 depends on issue 18182, which changed state.

Issue 18182 Summary: std.uri should be usable in @safe
https://issues.dlang.org/show_bug.cgi?id=18182

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

[Issue 17448] Move semantics cause memory corruption and cryptic bugs

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17448

--- Comment #34 from Eyal  ---
Walter: Thanks, the RVO fixes are very useful and important - and will be part
of any future solution we have!

--

[Issue 18133] BitArray constructors are poorly documented.

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18133

--- Comment #4 from github-bugzi...@puremagic.com ---
Commit pushed to master at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/3609d7233414fbd8a9d0c21313be21aff02d6829
Merge pull request #6112 from byebye/issue_18133

Fix issue 18133 - improve docs and add code examples for BitArray constructors
merged-on-behalf-of: Jack Stouffer 

--

[Issue 18591] DMD should allow access to mixin template declarations

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18591

Simen Kjaeraas  changed:

   What|Removed |Added

 CC||simen.kja...@gmail.com

--- Comment #2 from Simen Kjaeraas  ---
Issue example from PR:

struct TypeObj
{
alias This = typeof(this);

mixin template MixinTempl()
{
int value;
}
}

ref TypeObj Obj()
{
static TypeObj a;
return a;
}

void main()
{
mixin Obj.This.MixinTempl; // ok
mixin Obj.MixinTempl;  // error: "MixinTempl!()" is not defined
}

--

[Issue 17448] Move semantics cause memory corruption and cryptic bugs

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17448

--- Comment #33 from Shachar Shemesh  ---
Like we said earlier, the safe implications are important, but are not the core
of this bug report.

The problem is that, as things stand with D, certain types of programming
become impossible.

For example, consider a RAII object protecting a resource (say, a file
descriptor). For debugging purposes, we want to have a version(debug) option
for tracking all such objects within the system.

Under C++, what we'd do is to have a global linked list head, and have each
RAII object register itself with the linked list in the constructor and
deregister itself in the destructor.

If necessary, we would have a move constructor that shifts the registration
when the RAII is moved.

This last step is impossible in D. You cannot be notified when the object
moves, and once it does, the global linked list will get completely corrupted.

--

[Issue 17449] [DIP1000] crash due to covariant conversion of scope delegate to delegate

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17449

--- Comment #4 from Walter Bright  ---
(In reply to Rainer Schuetze from comment #3)
> Are you saying that it is ok that adding -dip1000 can change code gen so
> that it crashes?

Yes. This is because 'scope' for delegates now means something with dip1000, it
means the delegate must not escape. If it does, and this is not checked for in
non-@safe functions, it will likely crash.


> I don't see anything unsafe and invalid in the original code. Could you
> elaborate? Please note that it it also in the dmd test suite.

The problem is the delegate escapes from its stack frame, and no closure was
allocated.

The scope checking with delegates is a backwards compatibility thing, as people
often pass scope delegates to non-scope delegate parameters.

--

[Issue 18589] New: Windows header files: bcrypt and ncrypt

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18589

  Issue ID: 18589
   Summary: Windows header files: bcrypt and ncrypt
   Product: D
   Version: D2
  Hardware: All
OS: Windows
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: druntime
  Assignee: nob...@puremagic.com
  Reporter: an...@s-e-a-p.de

Could you add the windows header files for bcrypt and ncrypt to
src\druntime\src\core\sys\windows?

Thanks a lot.

--

[Issue 17512] [REG 2.073] [DIP1000] Error on bad interplay of 'auto ref' and 'return' attribute deduction.

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17512

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com
Summary|[REG 2.073] [DIP1000] Error |[REG 2.073] [DIP1000] Error
   |on bad interplay of "auto   |on bad interplay of 'auto
   |ref" and "return" attribute |ref' and 'return' attribute
   |deduction.  |deduction.

--

[Issue 17448] Move semantics cause memory corruption and cryptic bugs

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17448

--- Comment #32 from Walter Bright  ---
I filed two bug reports based on Tomer's work:

https://issues.dlang.org/show_bug.cgi?id=18575
https://issues.dlang.org/show_bug.cgi?id=18576

which have PRs:

https://github.com/dlang/dmd/pull/7989
https://github.com/dlang/dmd/pull/7990

The second example in comment 1 is a bug in the example, as:

auto f() {auto x = g();}

should be:

auto f() { return g();}

This addresses all the issues in examples provided. I.e. the escapes are
properly detected with -dip1000, and the structs don't move due to RVO (Return
Value Optimization) where the results are written into the caller's stack
frame.

If you discover more problems with escape detection and moved stack objects,
please let me know with examples. Thanks!

--

[Issue 17423] pointer assignment to `this` in member function is not accounted for

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17423

Walter Bright  changed:

   What|Removed |Added

Summary|@safe code seg faults   |pointer assignment to
   ||`this` in member function
   ||is not accounted for

--

[Issue 17423] pointer assignment to `this` in member function is not accounted for

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17423

--- Comment #6 from Walter Bright  ---
The opApply is actually working correctly. The bug is that the dlg parameter
was incorrectly inferred as `scope`.

--

[Issue 17423] pointer assignment to `this` in member function is not accounted for

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17423

--- Comment #7 from Walter Bright  ---
https://github.com/dlang/dmd/pull/7999

--