[Issue 23073] [dip1000] scope inference from pure doesn't consider self-assignment
https://issues.dlang.org/show_bug.cgi?id=23073 --- Comment #3 from Walter Bright --- I.e.: test3.d(17): Error: scope variable `c` assigned to non-scope parameter `c` calling `assignNext` (Although calling both variables `c` makes the error message a bit confusing.) --
[Issue 23073] [dip1000] scope inference from pure doesn't consider self-assignment
https://issues.dlang.org/show_bug.cgi?id=23073 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #2 from Walter Bright --- Note that if `pure` is removed from assignNext(), the error is correctly diagnosed and reported. --
[Issue 23140] Array!T where T is a shared class no longer works
https://issues.dlang.org/show_bug.cgi?id=23140 Ruby The Roobster changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Ruby The Roobster --- The pull request has been merged. --
[Issue 22522] [dip1000] Creating interior pointers allowed in @safe
https://issues.dlang.org/show_bug.cgi?id=22522 --- Comment #6 from Dennis --- (In reply to Dennis from comment #5) > It's saying `this` has longer lifetime than `this`. Since when does `x > x` > evaluate to true? Nevermind, it says `this` has longer lifetime than "address of variable `this`", but, it should be in test suite and the modification with `return scope` needs to error. --
[Issue 22522] [dip1000] Creating interior pointers allowed in @safe
https://issues.dlang.org/show_bug.cgi?id=22522
Dennis changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|WONTFIX |---
--- Comment #5 from Dennis ---
(In reply to Walter Bright from comment #4)
> The error message isn't great, but it is correctly identifying the problem.
It's saying `this` has longer lifetime than `this`. Since when does `x > x`
evaluate to true?
It also still works when you add `return scope` to the constructor:
```
@safe:
struct S {
int storage;
int* ptr;
this(int dummy) return scope {
ptr =
}
int* get() return scope {
return ptr;
}
}
int* escape() {
S s = S(0);
return s.get; // escapes a pointer to stack variable `s`
}
```
--
[Issue 22522] [dip1000] Creating interior pointers allowed in @safe
https://issues.dlang.org/show_bug.cgi?id=22522 Walter Bright changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |WONTFIX --- Comment #4 from Walter Bright --- The error message isn't great, but it is correctly identifying the problem. ptr = *is* taking the address of `this`, and assigning it to `this`. As in`storage` is *(this+0), and `ptr` is *(this+8) --
[Issue 22977] [dip1000] can escape scope pointer returned by nested function
https://issues.dlang.org/show_bug.cgi?id=22977 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #2 from Walter Bright --- Probably the most sensible way to deal with this is to allow non-static nested functions to have `return` and `scope` attributes, and then treat uplevel variable references as if they were parameters marked with those attributes. --
[Issue 22916] [dip1000] copy of ref return still treated as scope variable
https://issues.dlang.org/show_bug.cgi?id=22916 --- Comment #4 from Dennis --- (In reply to Walter Bright from comment #2) > I think the basic problem here is the code is trying to make scope > transitive, and it just doesn't work. No, my array struct works exactly like a dynamic array. It does not try to have scope pointers as array elements. --
[Issue 22916] [dip1000] copy of ref return still treated as scope variable
https://issues.dlang.org/show_bug.cgi?id=22916 --- Comment #3 from Dennis --- (In reply to Walter Bright from comment #1) > Although > the *ptr is not `scope`, because `scope` is not transitive, the compiler > transfers the `scope` to the return value because it is told to. No, my `return scope` annotation is correct. *ptr becomes `scope` again because I return it by `ref`, which is effectively taking the address which cancels out the dereference. If you mark `index` just `scope`, the compiler correctly complains about `return *ptr`: > Error: scope variable `this` may not be returned --
[Issue 6958] [CTFE] closures are not yet supported in CTFE
https://issues.dlang.org/show_bug.cgi?id=6958 RazvanN changed: What|Removed |Added CC||razvan.nitu1...@gmail.com Severity|normal |enhancement --
[Issue 22916] [dip1000] copy of ref return still treated as scope variable
https://issues.dlang.org/show_bug.cgi?id=22916 --- Comment #2 from Walter Bright --- I think the basic problem here is the code is trying to make scope transitive, and it just doesn't work. At some point the code will have to use @trusted code to make it work. --
[Issue 22916] [dip1000] copy of ref return still treated as scope variable
https://issues.dlang.org/show_bug.cgi?id=22916
Walter Bright changed:
What|Removed |Added
CC||bugzi...@digitalmars.com
--- Comment #1 from Walter Bright ---
Here's the problem:
ref int* index() return scope {
return *ptr;
}
The `scope` applies to the `this` reference, in this case, `ptr`. Although the
*ptr is not `scope`, because `scope` is not transitive, the compiler transfers
the `scope` to the return value because it is told to. (This is a feature, not
a bug.)
--
[Issue 6274] 'pure' for a whole struct definition
https://issues.dlang.org/show_bug.cgi?id=6274 RazvanN changed: What|Removed |Added Status|NEW |RESOLVED CC||razvan.nitu1...@gmail.com Resolution|--- |WONTFIX --- Comment #3 from RazvanN --- Yes, you can use the `pure:` to obtain exactly what is requested. Closing as WONTFIX. --
[Issue 6245] Using an exception object inside a delegate, causes a crash
https://issues.dlang.org/show_bug.cgi?id=6245 RazvanN changed: What|Removed |Added Status|NEW |RESOLVED CC||razvan.nitu1...@gmail.com Resolution|--- |FIXED --- Comment #2 from RazvanN --- I just compiled and ran the code with the latest master. It successfully compiles, runs and exits gracefully. It seems like this has been fixed. --
[Issue 6225] Some common null test mistakes
https://issues.dlang.org/show_bug.cgi?id=6225 RazvanN changed: What|Removed |Added Status|NEW |RESOLVED CC||razvan.nitu1...@gmail.com Resolution|--- |WONTFIX --- Comment #1 from RazvanN --- This is more suited for a third party library. Also, the compiler will need to do dataflow analysis to understand these cases. --
[Issue 5609] struct opEquals doesn't conform to language specifications.
https://issues.dlang.org/show_bug.cgi?id=5609 RazvanN changed: What|Removed |Added Status|NEW |RESOLVED CC||razvan.nitu1...@gmail.com Resolution|--- |INVALID --- Comment #3 from RazvanN --- This bug report highlights a misunderstanding of the spec [1]. It is clearly stated: "Otherwise the expressions a.opEquals(b) and b.opEquals(a) are tried. If both resolve to the same opEquals function, then the expression is rewritten to be a.opEquals(b).". So, in the provided test case a.opEquals(b) and b.opEquals(a) resolve to the same function therefore `a.opEquals(b)` is selected. Only if opEquals did not resolve to the same function the compiler would have tried to semantically analyze the 2 constructions. So this bug report is invalid. [1] https://dlang.org/spec/operatoroverloading.html#equals --
[Issue 5540] Probable bug-hiding redundancies
https://issues.dlang.org/show_bug.cgi?id=5540 RazvanN changed: What|Removed |Added Status|NEW |RESOLVED CC||razvan.nitu1...@gmail.com Resolution|--- |MOVED --- Comment #9 from RazvanN --- Walter is against adding warnings, so that path is a dead end. These checks should be done by a linter that uses dmd as a library. --
[Issue 5479] Can't take address of struct literal inside array initializer
https://issues.dlang.org/show_bug.cgi?id=5479
--- Comment #3 from RazvanN ---
(In reply to ag0aep6g from comment #2)
> (In reply to RazvanN from comment #1)
> > This compiles successfully in D2.
>
> Uh, no it doesn't? DMD v2.096.0 prints: "Error: cannot use non-constant CTFE
> pointer in an initializer `&[Identifier("someid")][0]`". Reopening.
Argh, I omitted the last line of the bug report when copy pasting...
--
[Issue 5464] Attribute to not ignore function result
https://issues.dlang.org/show_bug.cgi?id=5464 RazvanN changed: What|Removed |Added Status|NEW |RESOLVED CC||razvan.nitu1...@gmail.com Resolution|--- |FIXED --- Comment #4 from RazvanN --- This has been addressed by the addition of @mustuse: https://github.com/dlang/dmd/pull/13589 --
[Issue 5436] tightening auto decl spec
https://issues.dlang.org/show_bug.cgi?id=5436 RazvanN changed: What|Removed |Added CC||razvan.nitu1...@gmail.com Component|dmd |dlang.org --
[Issue 4699] Functions in peer scopes cannot have the same name
https://issues.dlang.org/show_bug.cgi?id=4699 RazvanN changed: What|Removed |Added Status|NEW |RESOLVED CC||razvan.nitu1...@gmail.com Resolution|--- |FIXED --- Comment #8 from RazvanN --- This has been fixed. The code compiles with the latest master. --
[Issue 20708] result of cast not specified when value is out of range
https://issues.dlang.org/show_bug.cgi?id=20708 --- Comment #2 from Nick Treleaven --- > Issue 22527 for float -> int was fixed. See: https://dlang.org/spec/expression.html#cast_floating --
[Issue 20708] result of cast not specified when value is out of range
https://issues.dlang.org/show_bug.cgi?id=20708 Nick Treleaven changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Nick Treleaven --- Issue 21279 for integers now has a pull request. Issue 22527 for float -> int was fixed. Closing in favour of those. *** This issue has been marked as a duplicate of issue 21279 *** --
[Issue 21279] cast expression between integer types is not defined
https://issues.dlang.org/show_bug.cgi?id=21279 Nick Treleaven changed: What|Removed |Added CC||johanenge...@weka.io --- Comment #2 from Nick Treleaven --- *** Issue 20708 has been marked as a duplicate of this issue. *** --
[Issue 21279] cast expression between integer types is not defined
https://issues.dlang.org/show_bug.cgi?id=21279 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #1 from Dlang Bot --- @ntrel created dlang/dlang.org pull request #3373 "Fix Issue 21279 - cast expression between integer types is not defined" fixing this issue: - Fix Issue 21279 - cast expression between integer types is not defined https://github.com/dlang/dlang.org/pull/3373 --
[Issue 23295] New: [dip1000] explain why scope inference failed
https://issues.dlang.org/show_bug.cgi?id=23295
Issue ID: 23295
Summary: [dip1000] explain why scope inference failed
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: dkor...@live.nl
This comes up a lot in Phobos when using range functions (e.g. `reduce` or
`format`) that have a lot of overloads and design by introspection complexity,
making the source of scope errors really hard to track down.
Minimized example:
```
@safe:
void main()
{
scope int* x;
foo(x, null);
}
auto foo(int* y, int** w)
{
fooImpl(y, null);
}
auto fooImpl(int* z, int** w)
{
//
auto f =
//
}
```
The error is:
> Error: scope variable `x` assigned to non-scope parameter `y` calling
> onlineapp.foo
It doesn't tell you anything more than that, I would like the error to tell me:
> Error: scope variable `x` assigned to non-scope parameter `y`
>which is assigned to non-scope parameter `z`
>which is not inferred `scope` because ``
--
[Issue 23294] New: [dip1000] parameter to parameter assignment leads to incorrect scope inference
https://issues.dlang.org/show_bug.cgi?id=23294
Issue ID: 23294
Summary: [dip1000] parameter to parameter assignment leads to
incorrect scope inference
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Keywords: safe
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: dkor...@live.nl
x and y are inferred scope in the following example:
```
@safe:
int global;
auto f(int* x, int* y)
{
x = y;
global++; // make sure it's not inferring scope from pure
}
void g(scope int* z)
{
f(z, z); // passes
}
```
When you mark `x` and `y` as `scope` explicitly, it errors:
> Error: scope variable `y` assigned to `x` with longer lifetime
But evidently, scope parameter inference does not care about relative lifetime
of parameters, which is problematic when they have destructors.
--
[Issue 4586] DMD should look for dmd.conf in /usr/local/etc
https://issues.dlang.org/show_bug.cgi?id=4586 RazvanN changed: What|Removed |Added Severity|normal |minor --
[Issue 4576] [tdpl] 0/1 argument calls to overloaded function is allowed in presence of variadic function
https://issues.dlang.org/show_bug.cgi?id=4576
RazvanN changed:
What|Removed |Added
Status|NEW |RESOLVED
CC||razvan.nitu1...@gmail.com
Resolution|--- |INVALID
--- Comment #5 from RazvanN ---
(In reply to Andrej Mitrovic from comment #4)
> Reduced test-case:
>
> -
> void test(int[] arr...) { assert(1); }
> void test() { assert(0); } // hijacks (shadows) above function
>
> void main()
> {
> test(); // should fail at CT, not RT.
> }
> -
>
> Comment out the second function and the first one will be called. The
> `test()` call should be ambiguous and issue a compile-time error.
The compiler sees that both functions match, however, the non-variadic one is
more specialized and the variadic one. This is all described very well in the
spec [1]. More specifically, point 5 in the section that I linked.
Closing as invalid.
[1] https://dlang.org/spec/function.html#function-overloading
--
[Issue 4558] To spot a possible bug in code that doesn't change a value
https://issues.dlang.org/show_bug.cgi?id=4558 RazvanN changed: What|Removed |Added Status|NEW |RESOLVED CC||razvan.nitu1...@gmail.com Resolution|--- |WONTFIX --- Comment #2 from RazvanN --- Walter has repeatedly stated that dmd-fe does not and will not do dataflow analysis. The problem with these sort of examples is that they seem trivial to implement for the simple cases, but once you start to think about more complex scenarios, the implementation becomes very complicated very fast. I will close this as WONTFIX. --
[Issue 4542] [tdpl] TDPL NVI example results in linker error
https://issues.dlang.org/show_bug.cgi?id=4542 RazvanN changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |WONTFIX --- Comment #18 from RazvanN --- The spec seems to be clear about this [1]: """ The following are not virtual: - Struct and union member functions - final member functions - static member functions - Member functions which are private or package - Member template functions """ So it seems that TDPL is wrong in this aspect. I'm going to close this as per the arguments of Jonathan. [1] https://dlang.org/spec/function.html#virtual-functions --
[Issue 4542] [tdpl] TDPL NVI example results in linker error
https://issues.dlang.org/show_bug.cgi?id=4542
RazvanN changed:
What|Removed |Added
CC||razvan.nitu1...@gmail.com
--- Comment #17 from RazvanN ---
(In reply to Simon Naarmann from comment #16)
> This bug is still in dmd 2.071.2 and 2.072.
>
> I ran into this today, here's my reduced case:
>
> interface IA {
> package void f();
> }
> void main() {
> IA a;
> a.f();
> }
>
> Nothing new, but I'd like to nudge for resolution. :-) I dustmited my
> project due to this bug. The linker error didn't help me.
>
> If this is hard to fix, then maybe error out at compile-time as a hack?
>
> -- Simon
I don't understand what you expect to happen in this case. You are calling f
which does not have a body.
--
[Issue 4410] AA has inconsistent and unreasonable requirements for iterating over reference-type index
https://issues.dlang.org/show_bug.cgi?id=4410 RazvanN changed: What|Removed |Added CC||razvan.nitu1...@gmail.com --- Comment #5 from RazvanN --- Apart from the first foreach, the rest do not compile today. You can only ref an aa key if it is const. This makes sense in my opinion. @Steven, what else needs to be done to consider this issue fixed? --
[Issue 4338] Structs with non-const destructors cannot be used as const parameters
https://issues.dlang.org/show_bug.cgi?id=4338 RazvanN changed: What|Removed |Added Status|NEW |RESOLVED CC||razvan.nitu1...@gmail.com Resolution|--- |LATER --- Comment #10 from RazvanN --- Closing this issue as the code compiles. As Andrei pointed out, it is unsound for this code to compile, however, there is a dedicated bug report for that case. --
[Issue 4236] 'out of memory' error compiling on windows
https://issues.dlang.org/show_bug.cgi?id=4236 RazvanN changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME --
[Issue 20809] return statement might access memory from destructed temporary
https://issues.dlang.org/show_bug.cgi?id=20809 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #16 from Dlang Bot --- dlang/dmd pull request #14358 "fix Issue 20809 - return statement might access memory from destructe…" was merged into master: - 35af96b308228cf6df9dcb409b4fee0ee2ddc3e6 by Walter Bright: fix Issue 20809 - return statement might access memory from destructed temporary https://github.com/dlang/dmd/pull/14358 --
