[Issue 24592] ImportC: Bitfield layout wrong for int64 on 32-bit Linux
https://issues.dlang.org/show_bug.cgi?id=24592 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Dlang Bot --- dlang/dmd pull request #16590 "Fix bugzilla 24592 - ImportC: Bitfield layout wrong for int64 on 32-b…" was merged into master: - e427ca656d801bcc438afce7fd6fba94d0e860c5 by Tim Schendekehl: Fix bugzilla 24592 - ImportC: Bitfield layout wrong for int64 on 32-bit Linux Type ulong is 64-bit on 32-bit Linux, but has 32-bit alignment. This affects the layout of bitfields. Also add a new test for ImportC bitfields, which compares size, alignment and layout with the host C++ compiler. The existing tests compared with fixed values instead. https://github.com/dlang/dmd/pull/16590 --
[Issue 24613] New: Bitfield with 64 bits always zero
https://issues.dlang.org/show_bug.cgi?id=24613
Issue ID: 24613
Summary: Bitfield with 64 bits always zero
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: tim.dl...@t-online.de
Values for a bitfield with 64 bits are not stored and remain 0.
```
struct S
{
ulong a:64;
}
void main()
{
S s;
s.a = 1;
assert(s.a == 1); // Fails: s.a is 0
}
```
This affects both ImportC and normal D with -preview=bitfields.
--
[Issue 24592] ImportC: Bitfield layout wrong for int64 on 32-bit Linux
https://issues.dlang.org/show_bug.cgi?id=24592 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #1 from Dlang Bot --- @tim-dlang created dlang/dmd pull request #16590 "Fix bugzilla 24592 - ImportC: Bitfield layout wrong for int64 on 32-b…" fixing this issue: - Fix bugzilla 24592 - ImportC: Bitfield layout wrong for int64 on 32-bit Linux Type ulong is 64-bit on 32-bit Linux, but has 32-bit alignment. This affects the layout of bitfields. Also add a new test for ImportC bitfields, which compares size, alignment and layout with the host C++ compiler. The existing tests compared with fixed values instead. https://github.com/dlang/dmd/pull/16590 --
[Issue 24612] New: Explicitly given `auto ref` parameter can’t bind by lvalue by value
https://issues.dlang.org/show_bug.cgi?id=24612
Issue ID: 24612
Summary: Explicitly given `auto ref` parameter can’t bind by
lvalue by value
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: qs.il.paperi...@gmail.com
```d
void f(T)(auto ref T x) {}
void main()
{
int x;
f!long(x); // Error: template `f` is not callable using argument types
`!(long)(int)`
}
```
This should instantiate `f` as `f!long(long x)`, as `int` converts to `long`
and `cast(long)x` is an rvalue.
I don’t know how far with implicit conversions this should go, but it should
work for built-in integer and floating-point types. It should also work for
class/interface types with inheritance relationship, and while binding those by
`auto ref` is weird to do explicitly, such a binding might end up from
templates that bind arbitrary type objects that happen to be class handles in
the user’s code. Then:
```d
Exception e = new Exception("");
f!Object(e); // Currently error, should be pass-by-value
```
With my proposed fix for Issue 24611, users could opt-into `ref` explicitly if
they need to.
--
[Issue 24612] Explicitly given `auto ref` parameter can’t bind by lvalue by value
https://issues.dlang.org/show_bug.cgi?id=24612 Bolpat changed: What|Removed |Added Priority|P1 |P2 CC||qs.il.paperi...@gmail.com --
[Issue 24611] Cannot explicitly instantiate template function with `auto ref`
https://issues.dlang.org/show_bug.cgi?id=24611 Bolpat changed: What|Removed |Added Priority|P1 |P2 CC||qs.il.paperi...@gmail.com --
[Issue 24611] New: Cannot explicitly instantiate template function with `auto ref`
https://issues.dlang.org/show_bug.cgi?id=24611
Issue ID: 24611
Summary: Cannot explicitly instantiate template function with
`auto ref`
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: qs.il.paperi...@gmail.com
```d
void f(T)(auto ref T x) {}
void main()
{
int x;
f(x); // infers T = int, auto ref = ref
f(0); // infers T = int, auto ref = Ø
f!int(x); // same as first
f!int(0); // same as second
auto fp = !int; // Error: cannot explicitly instantiate template function
with `auto ref`
alias f_int = f!int; // Error: cannot explicitly instantiate template
function with `auto ref`
}
```
The spec nowhere says that one can’t explicitly instantiate function templates
with `auto ref` parameters.
I suggest we extend template type parameters and let them be bound not just to
a type, but also, optionally, a `ref`. Any template type parameter is
effectively a bool–type pair where the bool says if `ref` was given as an
argument.
Supplying `ref` only makes a difference when the type parameter is used as a
function parameter type. In every other use, it is ignored. When a template
type parameter is `ref` and used as a function parameter type, that parameter
must be `auto ref`, otherwise it is an error. If it is an `auto ref` parameter,
it becomes `ref`. Explicit instantiations of function templates with `auto ref`
parameters become valid and if no `ref` is given for the template type
argument, the `auto ref` becomes pass-by-value.
As for IFTI, nothing changes. The `ref` as part of a template type argument
will be inferred even if the corresponding type of the bool–type pair is given.
(Unlike say in C++, where the information of being reference is part of the
type.)
Example:
```d
void f(T)(auto ref T x) {}
void main()
{
int x;
f(x); // infers T = ref int, therefore auto ref = ref
f(0); // infers T = int, therefore auto ref = Ø
f!int(x); // same as first, T = ref int, ref inferred
f!int(0); // same as second, no ref inferred as argument is rvalue
// nothing really changed up until here
auto fp1 = !int; // Okay, T = int, pass-by-value
auto fp2 = !(ref int); // T = ref int, pass-by-reference
alias f_int = f!int; // Okay, T = int, pass-by-value
alias f_ref_int = f!(ref int); // T = ref int, pass-by-reference
```
--
[Issue 24610] Basic range-based `toString` not recognized
https://issues.dlang.org/show_bug.cgi?id=24610 Max Samukha changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #2 from Max Samukha --- Ok, my bad. The range wants a char, not string. (Anyway, nothing is more annoying than the silent acceptance of malformed toString.) --
[Issue 24610] Basic range-based `toString` not recognized
https://issues.dlang.org/show_bug.cgi?id=24610 --- Comment #1 from Max Samukha --- `import std.stdio;` is unnecessary. --
[Issue 24610] New: Basic range-based `toString` not recognized
https://issues.dlang.org/show_bug.cgi?id=24610
Issue ID: 24610
Summary: Basic range-based `toString` not recognized
Product: D
Version: D2
Hardware: x86_64
OS: Windows
Status: NEW
Severity: normal
Priority: P1
Component: phobos
Assignee: nob...@puremagic.com
Reporter: maxsamu...@gmail.com
import std.array;
import std.format;
struct S
{
void toString(Output)(ref Output output)
{
import std.range: put;
output.put("S");
}
}
void main()
{
S s;
auto output = appender!(char[]);
s.toString(output);
assert(output[] == "S"); // ok
output.clear();
formattedWrite!"%s"(output, s);
import std.stdio;
assert(output[] == "S"); // fail
}
The `toString` is implemented according to the spec
(https://dlang.org/phobos/std_format_write.html), and the formatter should use
it.
--
[Issue 24597] FreeBSD/OpenBSD: Enable ELF_COMDAT
https://issues.dlang.org/show_bug.cgi?id=24597 --- Comment #3 from Dlang Bot --- dlang/dmd pull request #16589 "merge stable" was merged into master: - aa5f1b4a6014a52c7118dde37274f8d336dc2ec0 by Brian Callahan: Fix Bugzilla 24597 https://github.com/dlang/dmd/pull/16589 --
[Issue 24566] condition that starts with runtime value and uses compile time array does not short circuit
https://issues.dlang.org/show_bug.cgi?id=24566 --- Comment #3 from Dlang Bot --- dlang/dmd pull request #16589 "merge stable" was merged into master: - d92734bdac94e09538911838051f8edb54b25185 by Timon Gehr: Fix bugzilla issue 24566 - condition that starts with runtime value and uses compile time array does not short circuit https://github.com/dlang/dmd/pull/16589 --
[Issue 24595] OpenBSD: Use .init_array/.fini_array
https://issues.dlang.org/show_bug.cgi?id=24595 --- Comment #3 from Dlang Bot --- dlang/dmd pull request #16589 "merge stable" was merged into master: - f56d15b9f007d55b4e17c9d7942eed38fbc7db39 by Brian Callahan: Fix Bugzilla 24595 (#16575) https://github.com/dlang/dmd/pull/16589 --
[Issue 24603] Can copy from non-void array into void[] in safe code
https://issues.dlang.org/show_bug.cgi?id=24603 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Dlang Bot --- dlang/dmd pull request #16584 "Fix Bugzilla 24603 - Can copy from non-void array into void[] in safe…" was merged into master: - f42dc60597bc904bee9b2377877d511f9dae3cf5 by Nick Treleaven: Fix Bugzilla 24603 - Can copy from non-void array into void[] in safe code Deprecate in safe code. https://github.com/dlang/dmd/pull/16584 --
[Issue 24596] Rebindable2 corrupts objects
https://issues.dlang.org/show_bug.cgi?id=24596 --- Comment #3 from Dlang Bot --- dlang/phobos pull request #9015 "merge stable" was merged into master: - 539dc473ba79db0e5e8cf9ee059a5cc137b88bda by FeepingCreature: Fix bugzilla issue 24596: std.typecons.Rebindable2: Don't destroy classes! Only destroy structs! (#9012) https://github.com/dlang/phobos/pull/9015 --
