[Issue 20627] Module ctors / dtors should always have D linkage
https://issues.dlang.org/show_bug.cgi?id=20627 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Dlang Bot --- dlang/dmd pull request #10858 "Fix issue 20627: Module ctors / dtors should always have D linkage" was merged into master: - 786fdf10317b25ed5b85ae07e918dc5627b7ab27 by Geod24: Fix issue 20627: Module ctors / dtors should always have D linkage See the changelog for the rationale of this change (or the issue). https://github.com/dlang/dmd/pull/10858 --
[Issue 20627] Module ctors / dtors should always have D linkage
https://issues.dlang.org/show_bug.cgi?id=20627 --- Comment #2 from Dlang Bot --- @Geod24 updated dlang/dmd pull request #10834 "Fix issue 20607 - Module constructors are visible as regular function" fixing this issue: - Fix issue 20627: Module ctors / dtors should always have D linkage See the changelog for the rationale of this change (or the issue). https://github.com/dlang/dmd/pull/10834 --
[Issue 20636] Support the RDSEED instruction in asm blocks
https://issues.dlang.org/show_bug.cgi?id=20636 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Dlang Bot --- dlang/dmd pull request #10865 "Fix Issue 20636 - Support the RDSEED instruction in asm blocks" was merged into master: - a854e1860952cae7500f0f603dfc5c9ec099ada5 by Nathan Sashihara: Fix Issue 20636 - Support the RDSEED instruction in asm blocks https://github.com/dlang/dmd/pull/10865 --
[Issue 20636] Support the RDSEED instruction in asm blocks
https://issues.dlang.org/show_bug.cgi?id=20636 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #1 from Dlang Bot --- @n8sh created dlang/dmd pull request #10865 "Fix Issue 20636 - Support the RDSEED instruction in asm blocks" fixing this issue: - Fix Issue 20636 - Support the RDSEED instruction in asm blocks https://github.com/dlang/dmd/pull/10865 --
[Issue 20636] New: Support the RDSEED instruction in asm blocks
https://issues.dlang.org/show_bug.cgi?id=20636 Issue ID: 20636 Summary: Support the RDSEED instruction in asm blocks Product: D Version: D2 Hardware: x86_64 OS: All Status: NEW Severity: enhancement Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: n8sh.second...@hotmail.com Allow the RDSEED instruction in asm blocks. https://www.felixcloutier.com/x86/rdseed --
[Issue 17927] [scope] `scope inout` parameter value can be escaped via return
https://issues.dlang.org/show_bug.cgi?id=17927 Steven Schveighoffer changed: What|Removed |Added Resolution|INVALID |FIXED --- Comment #15 from Steven Schveighoffer --- Fixing the resolution, as the original bug was not invalid. If I have time, I'll try to remember what this was about and open another enhancement request. --
[Issue 18792] Incorrect scope analysis with -dip1000 for small-sized-optimized string
https://issues.dlang.org/show_bug.cgi?id=18792 --- Comment #4 from Walter Bright --- much better, thank you --
[Issue 20635] New: std.file.write is not UFCS friendly
https://issues.dlang.org/show_bug.cgi?id=20635 Issue ID: 20635 Summary: std.file.write is not UFCS friendly Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: normal Priority: P1 Component: phobos Assignee: nob...@puremagic.com Reporter: b2.t...@gmx.com the filename is the first parameter. It would be more judicious if it was the second. e.g, you cant do that for now --- string doStuff1(string); string doStuff2(string); dirEntries(...) .map!(a => tuple(a.name, readText(a.name)) .each!(a => a[1].doStuff1() .doStuff2() .write(a[0])); // oops --- it can happen very easily, even on a simple stuff like --- buffer.write(name); --- The choice of the order is very poor. Both cases presented here happened for real. At some point if you don't take care you finish with a folder containing files with cryptic names and each of them contains a path. Hilarious. As UFCS mimics the beahior of member functions we can compare `std.file.write` to something like `MemoryStream.writeToFile()` hence the "pseudo" `this` must be for the data, not the name. --
[Issue 18792] Incorrect scope analysis with -dip1000 for small-sized-optimized string
https://issues.dlang.org/show_bug.cgi?id=18792
--- Comment #3 from Per Nordlöw ---
(In reply to Per Nordlöw from comment #2)
> Small enough, Walter?
Forgot to remove obselete comments. Here's a new version with irrelevant
comments removed.
struct SSOString
{
pure nothrow @nogc:
inout(char)[] opSlice() inout return scope @trusted
{
return small.data[0 .. small.length];
}
struct Small
{
ubyte length;
char[15] data;
}
struct Raw
{
size_t length;
char* ptr;
}
union
{
Raw raw; // PROBLEM this declaration prevents DIP-1000 scope analysis
from kicking in in `opSlice`
Small small;
}
}
@safe pure nothrow @nogc unittest
{
char[] shouldFail1() @safe pure nothrow @nogc
{
SSOString x;
return x[]; // TODO should fail with -dip1000
}
}
--
[Issue 18792] Incorrect scope analysis with -dip1000 for small-sized-optimized string
https://issues.dlang.org/show_bug.cgi?id=18792
--- Comment #2 from Per Nordlöw ---
I managed to reduce the code snippet to
struct SSOString
{
pure nothrow @nogc:
inout(char)[] opSlice() inout return scope @trusted // TODO @safe for
-dip1000?
{
return small.data[0 .. small.length]; // scoped. TODO use .ptr when
proved stable
}
struct Small
{
ubyte length; // TODO only first 4 bits are needed to represent a
length between 0-15, use other 4 bits
char[15] data;
}
struct Raw // same memory layout as `char[]`
{
size_t length; // can be bit-fiddled without GC allocation
char* ptr;
}
union
{
Raw raw; // PROBLEM this declaration prevents DIP-1000 scope analysis
from kicking in in `opSlice`
Small small;
}
}
@safe pure nothrow @nogc unittest
{
char[] shouldFail1() @safe pure nothrow @nogc
{
SSOString x;
return x[]; // TODO should fail with -dip1000
}
}
When compiled with -dip100 the function `shouldFail1` should fail to compile
but it does still compile. When I remove the line
Raw raw;
scope analysis suddenly starts working which correctly triggers the error
foo.d(33,17): Error: returning `x.opSlice()` escapes a reference to local
variable `x`
return x[]; // TODO should fail with -dip1000
Small enough, Walter?
--
[Issue 19301] [DIP1000] missing overload abilities
https://issues.dlang.org/show_bug.cgi?id=19301 Walter Bright changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution|--- |WONTFIX --- Comment #1 from Walter Bright --- scope is deliberately not overloaded upon, as it would seem to be a very bizarre use case to do so. Adding this would require significant discussion and evaluation, including compelling use cases. I.e. a DIP would be needed. --
[Issue 19183] DIP1000 defeated if auto used instead of scope in variable declaration with template this member function
https://issues.dlang.org/show_bug.cgi?id=19183 Walter Bright changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution|--- |WORKSFORME --- Comment #20 from Walter Bright --- (In reply to Atila Neves from comment #19) > I can't reproduce the issue anymore. Then closing! --
[Issue 18792] Incorrect scope analysis with -dip1000 for small-sized-optimized string
https://issues.dlang.org/show_bug.cgi?id=18792 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #1 from Walter Bright --- Please reduce to a much smaller case of what the problem is. --
[Issue 18756] Escaping address of temporary struct field
https://issues.dlang.org/show_bug.cgi?id=18756 Walter Bright changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution|--- |INVALID --- Comment #6 from Walter Bright --- The compiler is working as designed. --
[Issue 17927] [scope] `scope inout` parameter value can be escaped via return
https://issues.dlang.org/show_bug.cgi?id=17927 Walter Bright changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |INVALID --- Comment #14 from Walter Bright --- (In reply to Steven Schveighoffer from comment #12) > ref inout should NOT be inferred as return. inout is a pattern match > on the mutability of the parameters, it does not necessarily imply that it > is part of the return type. inout is deliberately inferred as return. It's the way the language currently works. To change it please make an enhancement request, as such should be discussed on its own merits. --
[Issue 11044] Escaping references to lazy argument are allowed and compile to wrong code
https://issues.dlang.org/show_bug.cgi?id=11044 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #5 from Walter Bright --- I have a dip in the works to deprecate lazy parameters, replacing them with delegates, precisely because of problems like this. So this particular issue will likely not get fixed. --
[Issue 5212] no escape analysis for typesafe variadic function arguments
https://issues.dlang.org/show_bug.cgi?id=5212
Walter Bright changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|--- |INVALID
--- Comment #24 from Walter Bright ---
Compiling:
-
@safe:
class Foo {
int[] args;
@safe this(int[] args_...) {
args = args_;
}
}
Foo foo() {
return new Foo(1, 2, 3); // passes stack data to Foo
}
void main() {
assert(foo().args == [1, 2, 3]);
}
with -preview=DIP1000 yields:
test.d(5): Error: scope variable `args_` assigned to non-scope `this.args`
meaning the compiler is working correctly.
--
[Issue 19752] dip1000 isn't @safe if struct contains a slice
https://issues.dlang.org/show_bug.cgi?id=19752 --- Comment #5 from Walter Bright --- The key to understanding perplexing examples is to ruthlessly rewrite them in terms of `int*` and plain functions. Get rid of slices, this references, structs, member functions, etc. which do nothing but obfuscate what is happening, as they are just fancier versions of int* and functions. --
[Issue 19752] dip1000 isn't @safe if struct contains a slice
https://issues.dlang.org/show_bug.cgi?id=19752
Walter Bright changed:
What|Removed |Added
Status|NEW |RESOLVED
CC||bugzi...@digitalmars.com
Resolution|--- |INVALID
--- Comment #4 from Walter Bright ---
Let's do a little rewriting:
struct Range { Container *self; }
struct Container {
int* p;
static Range range(return scope ref Container c) @safe {
return Range();
}
}
which produces the same error. More rewrites:
struct Range { Container *self; }
struct Container { int* p; }
Range range(return scope ref Container c) @safe {
return Range();
}
produces the same error. More:
struct Container { int* p; }
Container* range(return scope ref Container c) @safe {
return
}
produces the same error. More:
int** range(return scope ref int* c) @safe {
return
}
produces the same error:
Error: cannot take address of ref parameter c in @safe function range
Now, the return value is not `ref`, so the `return` applies to the `int*`, not
the `ref`. But we're not returning the `int*`, we're returning the address of
the `int*` and recall the `return` doesn't apply to that, hence the error.
--
[Issue 19721] Cannot take address of scope local variable even with dip1000 if a member variable is a delegate
https://issues.dlang.org/show_bug.cgi?id=19721 Walter Bright changed: What|Removed |Added Status|NEW |RESOLVED Hardware|x86_64 |All Resolution|--- |INVALID OS|Linux |All --- Comment #3 from Walter Bright --- Here's what's happening. `scope int* s;` declares `s` as a pointer that must not be allowed to escape `main()`. The `func();` passes the address of `s` to `func`. `func` declares its parameter as `scope int**`. This ensures that the address of `s` does not escape, but says nothing about `s`'s pointer value, which must not be allowed to escape. I.e. the value of `s` is not protected from escaping `func`, so the call causes a compile error. If `s` is simply declared as an `int`, the `scope` annotation for `s` is meaningless, as there is no pointer value to protect, and it compiles successfully. Generally, rewriting perplexing examples as simple pointers tends to make what is happening much easier to determine. A delegate is regarded as a pointer. A struct that contains pointer values is itself regarded as a pointer. Hence the simplification of the example. --
