[Issue 18657] std.range and std.algorithm can't handle refRange
https://issues.dlang.org/show_bug.cgi?id=18657 --- Comment #4 from Dlang Bot --- @aG0aep6G created dlang/phobos pull request #6935 "make `cycle`, `splitter`, `roundRobin`, and `until` compatible with `RefRange`" mentioning this issue: - make `cycle` compatible with `RefRange` Part of a series on issue 18657. - make `splitter` compatible with `RefRange` Part of a series on issue 18657. - make `roundRobin` compatible with `RefRange` Part of a series on issue 18657. - make `until` compatible with `RefRange` Part of a series on issue 18657. https://github.com/dlang/phobos/pull/6935 --
[Issue 19763] Cannot construct immutable struct from pure mutable struct
https://issues.dlang.org/show_bug.cgi?id=19763 Jacob Carlborg changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #3 from Jacob Carlborg --- Hmm, I see. --
[Issue 19760] Windows 10 -m64 completely broken, can't compile/run hello world
https://issues.dlang.org/show_bug.cgi?id=19760 --- Comment #14 from ki...@gmx.net --- > Are you saying that it's ok that you can't run simple binaries on other > machines without putting them inside an installer and including the MSVC C++ > Redistribuable runtime in your installer? It sadly can't be avoided (and the only one to blame being Microsoft) for as long as druntime and Phobos depend on a C runtime, unless the dev installs Visual Studio or the Build Tools. Alternatively, just mentioning the MSVC runtime as prerequisite on the web or in some README might be enough in some cases. C# apps come with a .NET framework dependency, Java with JRE, and C(++)/D/Rust/... usually with the MSVC runtime (https://stackoverflow.com/questions/52153676/what-is-the-requirements-for-running-a-rust-compiled-program-on-another-windows). My Windows system with a moderate number of installed programs currently has 15 installed MSVC runtime versions (2005-2017, incl. different subversions). For LDC, I wrote this in an attempt to clarify that dependency: https://github.com/ldc-developers/ldc/blob/8f81d0797b7cb4bc44aeb6565366a8d31945b8c4/packaging/README.txt#L10-L18 --
[Issue 19765] std.algorithm.searching.findAmong doesn't `save` like it should
https://issues.dlang.org/show_bug.cgi?id=19765 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #1 from Dlang Bot --- @aG0aep6G created dlang/phobos pull request #6934 "fix issue 19765 - std.algorithm.searching.findAmong doesn't `save` li…" fixing this issue: - fix issue 19765 - std.algorithm.searching.findAmong doesn't `save` like it should https://github.com/dlang/phobos/pull/6934 --
[Issue 19765] New: std.algorithm.searching.findAmong doesn't `save` like it should
https://issues.dlang.org/show_bug.cgi?id=19765
Issue ID: 19765
Summary: std.algorithm.searching.findAmong doesn't `save` like
it should
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: phobos
Assignee: nob...@puremagic.com
Reporter: ag0ae...@gmail.com
import std.algorithm;
import std.range;
void main()
{
auto choices = inputRangeObject("b");
auto f = "foobar".findAmong(choices);
assert(equal(f, "bar")); /* fails; should pass */
}
--
[Issue 19760] Windows 10 -m64 completely broken, can't compile/run hello world
https://issues.dlang.org/show_bug.cgi?id=19760 --- Comment #13 from Jonathan Marler --- > Didn't the installer warn you that no VC runtime was found and even proposed > to install the VC2010 redistributables for you? I'm talking about the the case where you build hello world on one windows machine, then run it on another. Are you saying that it's ok that you can't run simple binaries on other machines without putting them inside an installer and including the MSVC C++ Redistribuable runtime in your installer? And if that's the case, I haven't seen any documentation saying that all executables compiled by DMD need to be packaged with an installer and need to come with the Microsoft redistributable runtime. --
[Issue 19760] Windows 10 -m64 completely broken, can't compile/run hello world
https://issues.dlang.org/show_bug.cgi?id=19760 Rainer Schuetze changed: What|Removed |Added CC||r.sagita...@gmx.de --- Comment #12 from Rainer Schuetze --- I'm with kinke on this. We must not distribute the static MS libs, and the dynamic libs need to be installed (usually through the distributable installers). Didn't the installer warn you that no VC runtime was found and even proposed to install the VC2010 redistributables for you? --
[Issue 19760] Windows 10 -m64 completely broken, can't compile/run hello world
https://issues.dlang.org/show_bug.cgi?id=19760 --- Comment #11 from ki...@gmx.net --- > I think I've read that LIBCMT is a static version of MSVCRT.dll, but I can't > confirm I can; also see the -mscrtlib cmdline switch. > Maybe we chose another implementation that we can ship a static library of > (DMC/MUSL). Musl on Windows? I just mentioned alternative runtimes for completeness; even if somebody wanted to go through all that trouble, incl. adapting druntime, there'd be still one big drawback: if you want to mix D and C(++) code and use the same heap etc., you have to make sure both parts use the same runtime. So any non-MSVC runtime on Windows would be an exotic and as such bad choice, just like the DigitalMars C runtime and Optlink are (being phased out with -m32mscoff/-m64 by default). > This only works if you are creating an executable that you are shipping with > an installer. I was talking about the DMD installer itself - checking if the libs or a Visual C++ (dev) installation is found, just so that the dev himself can run generated binaries without surprises. When redistributing you own Windows programs, you have two options - either bundle your software with the MS DLLs, like most C++ software does, or install Visual Studio or the Build Tools and link against the static runtime to prevent those runtime dependencies. The latter is clearly not an option for hobbyist devs; you surely remember all the threads of Windows users complaining about the Visual C++ dependency for linking. --
[Issue 19760] Windows 10 -m64 completely broken, can't compile/run hello world
https://issues.dlang.org/show_bug.cgi?id=19760 --- Comment #10 from Jonathan Marler --- > Feel free not to trust me, but I had a look at their license, as shipping > with static libs would have made the lives of some people around here much > easier. > Or are you suggesting to port the DigitalMars C runtime to 64-bits? Note that > the MinGW runtime is no alternative, it is itself based on the Microsoft DLLs > (yep, the MSVC ones, not just the Windows ones). I'm not sure what the right solution is yet. It looks like different compilers are using different approaches. I think I've read that LIBCMT is a static version of MSVCRT.dll, but I can't confirm, and even if it is, there may be licensing issues like you point out. Maybe we could use msvcrt.dll (the unversioned one) for stuff that we're sure will never change and supplement it with another static library to fill in the holes. Maybe we chose another implementation that we can ship a static library of (DMC/MUSL). I'm not sure what the right solution is here. > A practical solution (well, the only really I can think of) would be checking > the availability of those DLLs in the installer. This only works if you are creating an executable that you are shipping with an installer. --
[Issue 17729] dmd says cast expression is "not an lvalue", but it can be used as one in other contexts
https://issues.dlang.org/show_bug.cgi?id=17729 Andrei Alexandrescu changed: What|Removed |Added CC||and...@erdani.com Assignee|nob...@puremagic.com|razvan.nitu1...@gmail.com --
[Issue 19754] cast() sometimes yields lvalue, sometimes yields rvalue
https://issues.dlang.org/show_bug.cgi?id=19754 --- Comment #8 from Andrei Alexandrescu --- It seems the main anomaly is that cast() yields (sometimes...) an lvalue for shared data. Razvan, can you investigate if code would break if we forced cast() on shared data to always return an rvalue? --
[Issue 19760] Windows 10 -m64 completely broken, can't compile/run hello world
https://issues.dlang.org/show_bug.cgi?id=19760 --- Comment #9 from anonymous4 --- (In reply to kinke from comment #8) > Or are you suggesting to port the DigitalMars C runtime to 64-bits? Or musl :) --
[Issue 19764] New: Mutable data passed to _d_assert_fail
https://issues.dlang.org/show_bug.cgi?id=19764
Issue ID: 19764
Summary: Mutable data passed to _d_assert_fail
Product: D
Version: D2
Hardware: All
URL: https://forum.dlang.org/post/gwhsgdpodmatjdnubvrp@foru
m.dlang.org
OS: All
Status: NEW
Keywords: diagnostic
Severity: normal
Priority: P1
Component: druntime
Assignee: nob...@puremagic.com
Reporter: dfj1es...@sneakemail.com
When compiled with -checkaction=context
---
void f()
{
char[] a;
assert(a=="0");
}
---
Error: template instance `object._d_assert_fail!("==", char[], string)` error
instantiating
--
[Issue 19762] ICE on invalid code
https://issues.dlang.org/show_bug.cgi?id=19762 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Dlang Bot --- dlang/dmd pull request #9495 "Fix Issue 19762 - ICE on invalid code" was merged into stable: - 1edd0d944e5947ae144d2b1341f7a5fc1dc2c80e by RazvanN7: Fix Issue 19762 - ICE on invalid code https://github.com/dlang/dmd/pull/9495 --
[Issue 19757] crash on invalid initializer at CTFE
https://issues.dlang.org/show_bug.cgi?id=19757 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #2 from Dlang Bot --- @RazvanN7 created dlang/dmd pull request #9496 "Fix Issue 19757 - crash on invalid initializer at CTFE" fixing this issue: - Fix Issue 19757 - crash on invalid initializer at CTFE https://github.com/dlang/dmd/pull/9496 --
[Issue 19762] ICE on invalid code
https://issues.dlang.org/show_bug.cgi?id=19762 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #1 from Dlang Bot --- @RazvanN7 created dlang/dmd pull request #9495 "Fix Issue 19762 - ICE on invalid code" fixing this issue: - Fix Issue 19762 - ICE on invalid code https://github.com/dlang/dmd/pull/9495 --
[Issue 19761] cannot .mangleof or typeof() a private member.
https://issues.dlang.org/show_bug.cgi?id=19761 RazvanN changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=15371 --
[Issue 15371] __traits(getMember) should bypass the protection
https://issues.dlang.org/show_bug.cgi?id=15371 RazvanN changed: What|Removed |Added CC||razvan.nitu1...@gmail.com See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=19761 --
[Issue 19763] Cannot construct immutable struct from pure mutable struct
https://issues.dlang.org/show_bug.cgi?id=19763
--- Comment #2 from ag0aep6g ---
(In reply to ag0aep6g from comment #1)
> (In reply to Jacob Carlborg from comment #0)
[...]
> > Foo newFoo() pure
> > {
> > return Foo(null);
> > }
[...]
>
> This is ok, because newFoo [...] immediately returns the
> constructed Foo.
Correction: That doesn't matter. newFoo returns a mutable Foo, so it could
create the Foo, modify the data, and only then return the Foo. The important
bit is that the data is guaranteed to be newly created inside newFoo. It can't
come from a global or parameter. Any mutable references cease to exist when
newFoo returns.
--
[Issue 19763] Cannot construct immutable struct from pure mutable struct
https://issues.dlang.org/show_bug.cgi?id=19763
ag0aep6g changed:
What|Removed |Added
CC||ag0ae...@gmail.com
--- Comment #1 from ag0aep6g ---
(In reply to Jacob Carlborg from comment #0)
> The following example fails to compile:
>
> struct Foo
> {
> const(char)* filename;
> this(const(char)*) pure { }
> }
>
> void main()
> {
> immutable a = Foo(null);
> }
>
> Error:
I think it's correct that this is rejected.
The compiler could maybe realize that `null` poses no threat, or that the
constructor doesn't actually set `filename`, but it's obviously not that smart.
Generally, code like this must be rejected, because `main` still has access to
the pointer that's passed to the constructor:
struct Foo
{
const(char)* filename;
this(const(char)* f) pure { filename = f; }
}
void main()
{
char* p = new char;
immutable a = Foo(p);
*p = '!'; /* would mutate a.filename which is supposed to be immutable */
}
> But this code compiles:
>
> struct Foo
> {
> const(char)* filename;
> this(const(char)*) pure { }
> }
>
> Foo newFoo() pure
> {
> return Foo(null);
> }
>
> void main()
> {
> immutable a = newFoo();
> }
This is ok, because newFoo is `pure` and it immediately returns the constructed
Foo. So it's guaranteed that the only mutable reference to the data ceases to
exist right as the immutable one is created.
> Also if "const(char)* filename" is changed to "char* filename" the first
> example compiles.
The constructor cannot possibly use the const(char)* parameter to set the char*
field. So there is no way that the constructed Foo can refer to mutable data.
If you make the parameter mutable, too, then the code will be rejected again.
As far as I can tell, there's no bug here.
--
[Issue 19763] New: Cannot construct immutable struct from pure mutable struct
https://issues.dlang.org/show_bug.cgi?id=19763
Issue ID: 19763
Summary: Cannot construct immutable struct from pure mutable
struct
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: d...@me.com
The following example fails to compile:
struct Foo
{
const(char)* filename;
this(const(char)*) pure { }
}
void main()
{
immutable a = Foo(null);
}
Error:
cannot implicitly convert expression `Foo(null).this(null)` of type `Foo` to
`immutable(Foo)`
But this code compiles:
struct Foo
{
const(char)* filename;
this(const(char)*) pure { }
}
Foo newFoo() pure
{
return Foo(null);
}
void main()
{
immutable a = newFoo();
}
Also if "const(char)* filename" is changed to "char* filename" the first
example compiles.
--
[Issue 18657] std.range and std.algorithm can't handle refRange
https://issues.dlang.org/show_bug.cgi?id=18657 --- Comment #3 from Dlang Bot --- dlang/phobos pull request #6346 "make `group`, `chain`, and `choose` compatible with `RefRange`" was merged into stable: - b1b8b7968ffda3d64f9ee4666ebe453311eeb66e by aG0aep6G: make `chain` compatible with `RefRange` Part of a series on issue 18657. - e14ef1c912dcd84c197c03e7a8683e344559144b by aG0aep6G: make `group` compatible with `RefRange` Part of a series on issue 18657. - be9020a369091f58c3e5b1f3f3d31441d402d3f1 by aG0aep6G: make `choose` compatible with `RefRange` Part of a series on issue 18657. https://github.com/dlang/phobos/pull/6346 --
[Issue 19762] New: ICE on invalid code
https://issues.dlang.org/show_bug.cgi?id=19762
Issue ID: 19762
Summary: ICE on invalid code
Product: D
Version: D2
Hardware: x86_64
OS: Windows
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: elpenguin...@gmail.com
I couldn't get this down to less than 3 separate modules, and I can't even
guess which part of this is causing the crash.
Compile with -g.
a.d:
```
module a;
struct X {
import b : Baz;
Err err;
}
```
b.d:
```
module b;
struct Baz {
}
struct Qux {
import c;
}
```
c.d:
```
module c;
struct Foo {
import a : X;
X[] x;
}
Nullable!Foo foo() {
Nullable!Foo output;
return output;
}
struct Nullable(T)
{
bool opEquals(U)(const(U) rhs) const
if (is(typeof(this.get == rhs)))
{
return true;
}
inout(T) get() inout
{
return T.init;
}
}
```
--
