[Issue 20668] Unresolved symbol (array equality) when using separate compilation
https://issues.dlang.org/show_bug.cgi?id=20668 --- Comment #3 from Andrei Horodniceanu --- (In reply to Richard Cattermole from comment #2) > This is likely a template emission eliding bug. > > Try with ``-allinst`` to force emittance. This fixes it, thanks! This issue with tilix has been bugging me for a while, nice to have found a solution. --
[Issue 20668] Unresolved symbol (array equality) when using separate compilation
https://issues.dlang.org/show_bug.cgi?id=20668 Richard Cattermole changed: What|Removed |Added CC||alphaglosi...@gmail.com --- Comment #2 from Richard Cattermole --- This is likely a template emission eliding bug. Try with ``-allinst`` to force emittance. --
[Issue 20668] Unresolved symbol (array equality) when using separate compilation
https://issues.dlang.org/show_bug.cgi?id=20668
Andrei Horodniceanu changed:
What|Removed |Added
CC||a.horodnice...@proton.me
--- Comment #1 from Andrei Horodniceanu ---
This has come up as an issue in tilix
(https://github.com/gnunn1/tilix/issues/2210) making it uncompilable with dmd
and gdc when using meson due to these linking errors.
The reduced files for tilix are:
-
module terminal;
import common;
import session;
class Terminal {
GenericEvent!() event;
}
-
module common;
struct GenericEvent() {
int[] arr;
}
-
module session;
import common;
import terminal;
class Session {
GenericEvent!() event;
}
-
Compile with:
dmd -c terminal.d
dmd -c session.d
dmd -c common.d
dmd -of=main -main common.o session.o terminal.o
The results are:
/usr/lib/gcc/x86_64-pc-linux-gnu/13/../../../../x86_64-pc-linux-gnu/bin/ld:
session.o: in function
`_D6common__T12GenericEventZQp11__xopEqualsMxFKxSQBu__TQBqZQBuZb':
session.d:(.text._D6common__T12GenericEventZQp11__xopEqualsMxFKxSQBu__TQBqZQBuZb[_D6common__T12GenericEventZQp11__xopEqualsMxFKxSQBu__TQBqZQBuZb]+0x25):
undefined reference to
`_D4core8internal5array8equality__T8__equalsTiTiZQoFNaNbNiNeMxAiMxQeZb'
collect2: error: ld returned 1 exit status
Error: linker exited with status 1
cc common.o session.o terminal.o main.o -o main -m64 -Xlinker
--export-dynamic -Xlinker -rpath=/usr/lib/dmd/2.108/lib64
-L/usr/lib/dmd/2.108/lib64 -lphobos2 -lpthread -lm -lrt -ldl
--
[Issue 24527] New: opAssign has no effect during CTFE when an array is wrapped in a range
https://issues.dlang.org/show_bug.cgi?id=24527
Issue ID: 24527
Summary: opAssign has no effect during CTFE when an array is
wrapped in a range
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: issues.dl...@jmdavisprog.com
This code fails
---
import std.range.primitives;
struct Foo(R)
{
@property empty()
{
return _input.empty;
}
@property front()
{
return _input.front;
}
@property front(ElementType!R val)
{
_input.front = val;
}
void popFront()
{
_input.popFront;
}
R _input;
}
auto foo(R)(R r)
{
return Foo!R(r);
}
unittest
{
struct S
{
int entry;
void opAssign(S rhs) { this.entry = rhs.entry; }
}
auto test()
{
auto arr = [S(0),
S(1),
S(2),
S(3),
S(4)];
auto range = arr.foo;
range.front = S(42);
return range;
}
import std.algorithm.comparison;
auto runtime = test;
assert(equal(runtime, [S(42), S(1), S(2), S(3), S(4)]));
enum ctfe = test;
// First element is actually S(0), meaning that it wasn't set.
assert(equal(ctfe, [S(42), S(1), S(2), S(3), S(4)]));
}
void main()
{
}
---
The assignment works just fine if it's done during runtime, but it has no
effect if it's done at compile time.
Assigning to the array directly seems to work, so the range wrapper is
affecting things somehow.
Similarly, if the opAssign is removed from S, then the assignment works, so
it's the combination of using a wrapper struct and defining an opAssign which
is triggering this.
Also, whether the range is returned is irrelevant, you can simply assert that
the value changed after it was set in test, and it will fail during CTFE but
succeed at runtime. I returned the range in the example so that both the
compile-time and runtime results could be shown.
If I changed the example so that S is internal to the test function, and add a
bool that gets set when test is called, e.g.
---
auto test()
{
bool called;
struct S
{
int entry;
void opAssign(S rhs) { called = true; this.entry = rhs.entry; }
}
auto arr = [S(0),
S(1),
S(2),
S(3),
S(4)];
auto range = arr.foo;
called = false;
range.front = S(42);
assert(called);
assert(range.front == S(42));
return range;
}
---
then it shows that opAssign is called, but it fails to actually set the value.
If I change test to
---
auto test()
{
bool called;
struct S
{
int entry;
void opAssign(S rhs)
{
called = true;
this.entry = rhs.entry;
assert(this.entry == 42);
}
}
auto arr = [S(0),
S(1),
S(2),
S(3),
S(4)];
auto range = arr.foo;
called = false;
range.front = S(42);
assert(called);
assert(range.front == S(42));
return range;
}
---
then the assertion inside of opAssign actually passes, but the one checking the
value after the call does not. So, it's like opAssign is operating on a copy
rather than on the actual value.
--
[Issue 24525] auto ref lambda exp not parsed if used as left-most expression in a expression statement
https://issues.dlang.org/show_bug.cgi?id=24525
Nick Treleaven changed:
What|Removed |Added
Severity|enhancement |normal
--- Comment #2 from Nick Treleaven ---
> A declaration `ref () {return a;}` gets parsed
Sorry, that may be what is happening, but there is no identifier for the
declaration, so it should try to parse an ExpressionStatement.
--
[Issue 24525] auto ref lambda exp not parsed if used as left-most expression in a expression statement
https://issues.dlang.org/show_bug.cgi?id=24525
Nick Treleaven changed:
What|Removed |Added
CC||n...@geany.org
Severity|normal |enhancement
--- Comment #1 from Nick Treleaven ---
Under https://dlang.org/spec/statement.html#NonEmptyStatementNoCaseNoDefault
grammar block it says:
> Any ambiguities in the grammar between Statements and Declarations are
> resolved by the declarations taking precedence.
For:
> ref () {return a;}() = 0;
A declaration `ref () {return a;}` gets parsed, not an ExpressionStatement. So
I think this issue is invalid.
It is unfortunate that the function literal syntax starting `ref` or `auto ref`
was added, when the function/delegate keyword starting forms can already handle
those.
--
[Issue 24434] Casting away const with cast() should not produce an lvalue
https://issues.dlang.org/show_bug.cgi?id=24434 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Dlang Bot --- dlang/dmd pull request #16315 "Fix Bugzilla 24434 - Casting away const with cast() is not a @safe lv…" was merged into master: - 2b65bccc71a22fec0bff58b7c40662701941adf4 by Nick Treleaven: Fix Bugzilla 24434 - Casting away const with cast() is not a @safe lvalue https://github.com/dlang/dmd/pull/16315 --
[Issue 23530] casting immutable away allowed in safe
https://issues.dlang.org/show_bug.cgi?id=23530 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Dlang Bot --- dlang/dmd pull request #16315 "Fix Bugzilla 24434 - Casting away const with cast() is not a @safe lv…" was merged into master: - c2eac7ce389eb174cfbb96e66ab4fddb1b48a4b2 by Nick Treleaven: Workaround for safe append Fixes Bugzilla 23530 - casting immutable away allowed in safe. https://github.com/dlang/dmd/pull/16315 --
