Re: Strange error
On Monday, 22 March 2021 at 07:52:14 UTC, MichaelJames wrote: Tell me, did you manage to solve this problem? https://github.com/dlang/dmd/pull/12300
Re: Manually check struct invariants
On Tuesday, 23 March 2021 at 23:27:54 UTC, Paul Backus wrote: On Tuesday, 23 March 2021 at 22:22:12 UTC, Q. Schroll wrote: For a class object obj, one can use assert(obj) to get its invariants checked. How to do this for structs? https://dlang.org/spec/expression.html#assert_expressions If the first AssignExpression is a pointer to a struct instance for which a Struct Invariant exists, the Struct Invariant must hold. So, you would write `assert(&obj)` for a struct instance. I searched for it, but while for some reason, my brain read "If the first AssignExpression is a reference to a class instance for which a Class Invariant exists, the Class Invariant must hold." it failed to do so for the next sentence. Thank you.
Re: Manually check struct invariants
On 3/23/21 4:14 PM, Imperatorn wrote:> On Tuesday, 23 March 2021 at
22:22:12 UTC, Q. Schroll wrote:
>> For a class object obj, one can use assert(obj) to get its invariants
>> checked. How to do this for structs?
>
> It's called after the constructor has run and before the destructor is
> called.
>
> It's called before entering a member function and after exiting a member
> function.
>
> So technically you could just do like obj.writeln or whatever u have 😁
Just to make sure everyone knows "it" is the invariant block:
struct S {
int i;
int j;
this(int i, int j) {
this.i = i;
this.j = j;
}
invariant() {
assert(i == 2 * j);
}
}
void main() {
auto s = S(1, 10);// Won't pass the invariant check
}
Ali
Re: Manually check struct invariants
On Tuesday, 23 March 2021 at 22:22:12 UTC, Q. Schroll wrote: For a class object obj, one can use assert(obj) to get its invariants checked. How to do this for structs? https://dlang.org/spec/expression.html#assert_expressions If the first AssignExpression is a pointer to a struct instance for which a Struct Invariant exists, the Struct Invariant must hold. So, you would write `assert(&obj)` for a struct instance.
Re: 2.096.0 linker errors
https://github.com/dlang/dub/issues/2119
Re: Manually check struct invariants
On Tuesday, 23 March 2021 at 22:22:12 UTC, Q. Schroll wrote: For a class object obj, one can use assert(obj) to get its invariants checked. How to do this for structs? It's called after the constructor has run and before the destructor is called. It's called before entering a member function and after exiting a member function. So technically you could just do like obj.writeln or whatever u have 😁
Manually check struct invariants
For a class object obj, one can use assert(obj) to get its invariants checked. How to do this for structs?
Re: 2.096.0 linker errors
On Tuesday, 23 March 2021 at 17:19:10 UTC, mw wrote: If it's not a clean up issue, try -- DMD 2.095 or -- LDC 1.25.1 to see if you can build, if yes, then it could be a bug of 2.096 I tried compiling with both DMD 2.095.1 and LDC 1.25.1 and still got the linker errors. Then I tried compiling with and older version of dub (version 1.20.1 which shipped with DMD 2.091.1) but compiling with DMD 2.096.0 (`/opt/dmd.2.091.1/linux/bin64/dub build --compiler=/opt/dmd.2.096.0/linux/bin64/dmd`) and it compiled and linked just fine. So, this appears to be a dub problem. After some additional testing, I found that this compiles with dub version 1.23.0 (shipped with DMD 2.094.1) but not with dub version 1.24.1 (shipped with DMD 2.095.1). I ran `/opt/dmd.2.094.1/linux/bin64/dub build --compiler=/opt/dmd.2.096.0/linux/bin64/dmd -v` and `/opt/dmd.2.096.0/linux/bin64/dub build --compiler=/opt/dmd.2.096.0/linux/bin64/dmd -v` and diffed the compilation and linking commands. The linking commands are the same, but the compilation commands are different. The compilation command generated by the new version of dub is missing a number of files (from a library that I am importing) that the old version of dub includes. All of the places where I was getting linker errors are in these missing files. I am working on creating a minimum test case using dustmite and will file an issue in the dub GitHub project. I will post a link to the issue here when I have created an the issue. Thanks for your help!
Re: 2.096.0 linker errors
If it's not a clean up issue, try -- DMD 2.095 or -- LDC 1.25.1 to see if you can build, if yes, then it could be a bug of 2.096
Re: 2.096.0 linker errors
On Tuesday, 23 March 2021 at 16:04:49 UTC, mw wrote: Just want to make sure: what I mean is $HOME/.dub/ the whole *dir* tree, it contains all the 3rd party packages; not a single file. I don't have a $HOME/.dub/ directory, but I did delete the whole .dub/ directory in the project I am trying to compile.
Re: 2.096.0 linker errors
On Tuesday, 23 March 2021 at 15:27:32 UTC, Curtis wrote: On Tuesday, 23 March 2021 at 00:39:32 UTC, mw wrote: On Monday, 22 March 2021 at 23:35:09 UTC, Curtis wrote: Using 2.096.0, I'm getting a number of "undefined reference" ... The code compiles and links with 2.091.1 but I'm not sure what has changed since then that might cause this problem. I am working on creating a reduced test case using Dustmite but haven't been successful yet as it keeps reducing to an empty set. Any tips on what to do/check? Do 'dub clean --all-packages', (even 'rm -fr ∼/.Dub ) then rebuild from scratch. I think it try to mix the object file generated by the old compiler with the new one. Thanks for the idea. I failed to mention that in my original post, but I did already try removing the .dub file in the project but I still get the linker errors. Just want to make sure: what I mean is $HOME/.dub/ the whole *dir* tree, it contains all the 3rd party packages; not a single file.
Re: 2.096.0 linker errors
On Tuesday, 23 March 2021 at 00:39:32 UTC, mw wrote: On Monday, 22 March 2021 at 23:35:09 UTC, Curtis wrote: Using 2.096.0, I'm getting a number of "undefined reference" ... The code compiles and links with 2.091.1 but I'm not sure what has changed since then that might cause this problem. I am working on creating a reduced test case using Dustmite but haven't been successful yet as it keeps reducing to an empty set. Any tips on what to do/check? Do 'dub clean --all-packages', (even 'rm -fr ∼/.Dub ) then rebuild from scratch. I think it try to mix the object file generated by the old compiler with the new one. Thanks for the idea. I failed to mention that in my original post, but I did already try removing the .dub file in the project but I still get the linker errors.
Re: Implicit conversion of unique chars[] to string
On Tuesday, 23 March 2021 at 01:07:15 UTC, Steven Schveighoffer wrote: And the answer is complex. You can't accept a const range, because they don't work. The only way to have purity infer uniqueness is to accept paramters that the result could not have come from. Usually this means accepting const and returning mutable. How do we want this to work with and without the presence of `return` qualified parameters?
Re: Implicit conversion of unique chars[] to string
On Tuesday, 23 March 2021 at 01:07:15 UTC, Steven Schveighoffer
wrote:
const(char)[] x = "foo";
string chained = chainPath(x, "bar").array;
that calls the template overload
ForeachType!Range[] array(Range)(Range r)
if (isIterable!Range && !isAutodecodableString!Range &&
!isInfinite!Range)
should be able to implicitly convert to string because the .array
expression is inferred `pure`. Or is the compiler pessimistically
assuming that the slice returned from the .array call may reside
from a reference reachable from the range parameter `r`?
See for instance
@safe pure unittest
{
import std.path : chainPath;
import std.array : array;
const(char)[] x1 = "foo";
const string x2 = "bar";
auto y1 = chainPath(x1, x2).array;
pragma(msg, __FILE__, "(", __LINE__, ",1): Debug: ",
typeof(y1));
auto y2 = chainPath(x2, x1).array;
pragma(msg, __FILE__, "(", __LINE__, ",1): Debug: ",
typeof(y2));
}
printing
/home/per/f.d(8,1): Debug: const(char)[]
/home/per/f.d(10,1): Debug: const(char)[]
