On Saturday, 4 January 2020 at 22:43:10 UTC, Jon Degenhardt wrote:
> On the second issue, to make progress building tsv-utils in @safe mode, it'd be necessary to  mark the tsv-utils routines that call getopt as @trusted so that they can be used in an @safe main(). I'd be reluctant to do this. For this safe evaluation effort, an option would be to create a separate phobos branch and mark std.getopt functions @trusted to allow evaluation of calling code to proceed.

Nevermind the second idea, creating a branch marking getopt code @trusted. This won't help. The code calling getopt would need to be marked @trusted.

It would be very useful to bypass failures related to getopt use to see what else remains. I don't immediately see an easy path to do this though without actually rewriting the calling code.

As a general matter I think it would be useful to include more application code in these tests, as they may have different issues than the library code common in dub packages.

--Jon

On 04.01.20 23:43, Jon Degenhardt wrote:
> Looking at the tsv-utils error log, an issue that will affect applications more often than libraries is that uses of the std.getopt package are normally @system. That's because getopt assumes the caller will pass the addresses of variables. If the variable is local, the compilation will fail in @safe code. The code will typically be "safe" in that these references are not leaving the caller's scope, but the compiler still rejects the code in @safe mode.

With DIP 1000, that should work. But it looks like std.getopt needs a little push.

An attempt: https://github.com/dlang/phobos/pull/7344

On Sunday, 5 January 2020 at 00:34:42 UTC, ag0aep6g wrote:
> On 04.01.20 23:43, Jon Degenhardt wrote:
>> Looking at the tsv-utils error log, an issue that will affect applications more often than libraries is that uses of the std.getopt package are normally @system. That's because getopt assumes the caller will pass the addresses of variables. If the variable is local, the compilation will fail in @safe code. The code will typically be "safe" in that these references are not leaving the caller's scope, but the compiler still rejects the code in @safe mode.
>
> With DIP 1000, that should work. But it looks like std.getopt needs a little push.
>
> An attempt: https://github.com/dlang/phobos/pull/7344

Thanks for taking a look at this.

Does this mean DIP 1000 modifies the rule against taking the address of local variables in @safe functions? I did not realize this. Is there documentation somewhere describing the DIP 1000 rules for @safe functions? It's hard to tell from the DIP 1000 doc, and the rationale for "Superseded" status indicates that the implementation doesn't match the text of the DIP.

On Sunday, 5 January 2020 at 01:13:14 UTC, Jon Degenhardt wrote:
> On Sunday, 5 January 2020 at 00:34:42 UTC, ag0aep6g wrote:
>> With DIP 1000, that should work. But it looks like std.getopt needs a little push.
>>
>> An attempt: https://github.com/dlang/phobos/pull/7344
>
> Thanks for taking a look at this.
>
> Does this mean DIP 1000 modifies the rule against taking the address of local variables in @safe functions? I did not realize this. Is there documentation somewhere describing the DIP 1000 rules for @safe functions? It's hard to tell from the DIP 1000 doc, and the rationale for "Superseded" status indicates that the implementation doesn't match the text of the DIP.

Looking more closely at DIP 1000 doc - It appears to be saying that the compiler will try to prove addresses taken of local variable cannot be escaped. If the compiler can prove this, the function will pass @safe even it the address of locals is taken. If the compiler cannot prove it, the code will need to be rewritten to pass @safe.

So no hard rules about taking the address of local variables or not. Developers need to try it and see. Is this a reasonable summary?

On 1/4/20 4:40 PM, WebFreak001 wrote:
> On Saturday, 4 January 2020 at 20:58:46 UTC, JN wrote:
>> On Saturday, 4 January 2020 at 15:19:39 UTC, WebFreak001 wrote:
>>> I have done this for all dub packages now so everyone can review what this change actually does to their packages:
>>>
>>> https://i.webfreak.org/safe-test/index.html
>>>
>>
>> Looking at the error log, looks like most of the packages are failing here:
>>
>> /opt/dmd-safe/dmd/generated/linux/release/64/../../../../../phobos/std/bitmanip.d(64): Error: cast from `char[]` to `string` not allowed in safe code
>>
>> A single fix here might unblock a large chunk of projects.
> 
> that thing has a fix PR now, with it applied it looks much better:
> 
> https://github.com/dlang/phobos/pull/7343#issuecomment-570820743
> 
> https://i.webfreak.org/safe-test/phobos-7343.html
> 
> Will update index.html once it's merged

Hmm.... I see arsd-official passes. I have trouble believing that. I see a number of safety violations, is this right?

-Steve

On Sunday, 5 January 2020 at 03:04:38 UTC, Steven Schveighoffer wrote:
> Hmm.... I see arsd-official passes. I have trouble believing that. I see a number of safety violations, is this right?

yeah i suspect my thing isn't actually compiling there. I was going to test it locally today but got busy writing websocket client code and haven't gotten around to it yet.

Though I suspect most my code will pass, in my writing today I kept doing `writeln(cast(string) some_mutable_ubyte_array);` and i realized @safe by default would be constantly complaining about that.

I suspect it will drive me absolutely nuts at least while debugging stuff...

On Sunday, 5 January 2020 at 03:09:49 UTC, Adam D. Ruppe wrote:
> On Sunday, 5 January 2020 at 03:04:38 UTC, Steven Schveighoffer wrote:
>> Hmm.... I see arsd-official passes. I have trouble believing that. I see a number of safety violations, is this right?
>
> yeah i suspect my thing isn't actually compiling there. I was going to test it locally today but got busy writing websocket client code and haven't gotten around to it yet.
>
> Though I suspect most my code will pass, in my writing today I kept doing `writeln(cast(string) some_mutable_ubyte_array);` and i realized @safe by default would be constantly complaining about that.
>
> I suspect it will drive me absolutely nuts at least while debugging stuff...

You can always use `debug writeln(...);`, which ignores @safe, right?

On Sunday, 5 January 2020 at 03:04:38 UTC, Steven Schveighoffer wrote:
> On 1/4/20 4:40 PM, WebFreak001 wrote:
>> On Saturday, 4 January 2020 at 20:58:46 UTC, JN wrote:
>>> On Saturday, 4 January 2020 at 15:19:39 UTC, WebFreak001 wrote:
>>>> I have done this for all dub packages now so everyone can review what this change actually does to their packages:
>>>>
>>>> https://i.webfreak.org/safe-test/index.html
>>>>
>>>
>>> Looking at the error log, looks like most of the packages are failing here:
>>>
>>> /opt/dmd-safe/dmd/generated/linux/release/64/../../../../../phobos/std/bitmanip.d(64): Error: cast from `char[]` to `string` not allowed in safe code
>>>
>>> A single fix here might unblock a large chunk of projects.
>> 
>> that thing has a fix PR now, with it applied it looks much better:
>> 
>> https://github.com/dlang/phobos/pull/7343#issuecomment-570820743
>> 
>> https://i.webfreak.org/safe-test/phobos-7343.html
>> 
>> Will update index.html once it's merged
>
> Hmm.... I see arsd-official passes. I have trouble believing that. I see a number of safety violations, is this right?
>
> -Steve

$ dub build --build=syntax
Performing "syntax" build using /usr/bin/dmd for x86_64.
arsd-official 5.0.0+commit.5.ga023662: building configuration "library"...

it doesn't test subPackages yet but just the "package.d" with 1 line of code being "module arsd" compiles fine with @safe by default

On Saturday, 4 January 2020 at 15:19:39 UTC, WebFreak001 wrote:
[snip]
>>> I have done this for all dub packages now so everyone can review what this change actually does to their packages:
>>>
>>> https://i.webfreak.org/safe-test/index.html
>>>
>>
[snip]

Nice! And surprisingly useful/interesting to "just scroll" down and view the results for all the packages you are familiar with :-).

Is it not possible to have a similar list permanently on a dub page (periodically updated of course), showing the build status with the latest official DMD compiler? Even if it is only updated/re-generated each time a new version of the compiler is released? I know there is a "list view" of the packages on dub (which can be sorted by column), but this does not show build status.

Also, there are some compile failures in your list - such as for dpp/sumtype/etc - which fails because of build requirements not satisfied:

Installed dmd- with frontend 2.060 does not comply with sumtype frontend requirement: >=2.88.0

On 1/4/20 8:39 PM, Jon Degenhardt wrote:
> On Sunday, 5 January 2020 at 01:13:14 UTC, Jon Degenhardt wrote:
> 
> Looking more closely at DIP 1000 doc - It appears to be saying that the compiler will try to prove addresses taken of local variable cannot be escaped. If the compiler can prove this, the function will pass @safe even it the address of locals is taken. If the compiler cannot prove it, the code will need to be rewritten to pass @safe.
> 
> So no hard rules about taking the address of local variables or not. Developers need to try it and see. Is this a reasonable summary?

+1, I would love for this to be documented somewhere [that is easy to find]