DIP 1028 dub packages test package "sml"

[Jon Degenhardt]

On Saturday, 4 January 2020 at 21:40:23 UTC, 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

This is a very nice effort, thanks! It is definitely worth having 
a realistic sense of the amount and nature of breakage.

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.

This is unfortunate for two reasons. First, might not be easy to 
fix without redesigning or replacing std.getopt, and rewriting 
all the application code that uses it. Second, for this 
safe-testing effort, it may mask other problems that applications 
are likely to have that libraries would not, as the compilation 
is likely to fail early.

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.

A separate issue for the tsv-utils build. The initial failure is 
occurring in the dub build stub (dub_build.d, which uses getopt). 
This is causing the rest of the build fail. This is too bad 
because this is just part of the build system. There is no 
attempt to build any of the actual tools. It'd be interesting to 
see what compilation errors occur in the other tools. (Many will 
fail early due to getopt use, but still...).  What would be 
better for tsv-utils would be to do a git clone and 'make test' 
command. This is what is being done in the dlang buildkite CI 
tests.

--Jon