www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Re: DIP 1028 dub packages test package "sml"

reply WebFreak001 <d.forum webfreak.org> writes:
On Saturday, 4 January 2020 at 14:46:40 UTC, Gregor Mückl wrote:

 On Saturday, 4 January 2020 at 10:22:34 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


 I unfortunately have to question some of the results in that 
 list. I have a single, simple package called "sml" in dub and 
 it actually compiles (without  safe by default). This 
 contradicts what your list is stating.


I only test git packages, so your package is not processed 
because:

remote: Mercurial (hg) is required to use this repository.
remote:
remote: https://confluence.atlassian.com/x/vLRCMw
fatal: unable to access 'https://bitbucket.org/gmueckl/sml-d/': 
The requested URL returned error: 405
Jan 04 2020
next sibling parent reply WebFreak001 <d.forum webfreak.org> writes:
 https://i.webfreak.org/safe-test/index.html


The list is now sorted alphabetically.
Jan 04 2020
next sibling parent Joakim =?UTF-8?B?QnLDpG5uc3Ryw7Zt?= <notfornow dev.null.com> writes:
On Saturday, 4 January 2020 at 15:22:49 UTC, WebFreak001 wrote:

 https://i.webfreak.org/safe-test/index.html


 The list is now sorted alphabetically.


Thank you
Jan 04 2020
prev sibling parent reply WebFreak001 <d.forum webfreak.org> writes:
 https://i.webfreak.org/safe-test/index.html


Update:
now built using
phobos commit c039fed84 (std.bitmanip.bitfields issues fixed)
dmd commit 0ab7e90df (changes delegate to  safe by default)

now: (with dub build, not building tests)
478 packages compile
740 packages are still broken
499 packages are not buildable in the first place (eventually a 
lot only expected to be used as dependency and not standalone 
compilable)

so out of the compiling ones 39.2% currently work with no problem.

History: (adjusted to fix some build issues on my side)

dmd made delegates without safety attribute  safe by default:
compiles: 478, broken: 740, n/a: 499
works: 39.2%

phobos fixed the myToString method (fixes bitfields and some 
others)
compiles: 456, broken: 762, n/a: 499
works: 37.4%

initial tests:
compiles: 324, broken: 894, n/a: 499
works: 26.6%

I think we can still fix a little bit but I don't think we can go 
above 50% just by fixing phobos, dependencies on dub now also 
need to be updated (my index currently only uses a fixed version 
and isn't updated with any new releases)
Jan 06 2020
next sibling parent reply Atila Neves <atila.neves gmail.com> writes:
On Monday, 6 January 2020 at 23:05:29 UTC, WebFreak001 wrote:

 [...]


 Update:
 now built using
 phobos commit c039fed84 (std.bitmanip.bitfields issues fixed)
 dmd commit 0ab7e90df (changes delegate to  safe by default)

 [...]


There are still false negatives - autowrap definitely builds.
Jan 07 2020
parent reply WebFreak001 <d.forum webfreak.org> writes:
On Tuesday, 7 January 2020 at 10:43:44 UTC, Atila Neves wrote:

 On Monday, 6 January 2020 at 23:05:29 UTC, WebFreak001 wrote:

 [...]


 Update:
 now built using
 phobos commit c039fed84 (std.bitmanip.bitfields issues fixed)
 dmd commit 0ab7e90df (changes delegate to  safe by default)

 [...]


 There are still false negatives - autowrap definitely builds.


Running pre-generate commands for autowrap:pynih...
make: Entering directory 
'/srv/http/org.webfreak.symbols/clones-2020-01-04_00-35-08/5dafbb00bce0bf24b5b71996-autowrap/pynih'
make: 'source/python/raw.d' is up to date.
make: Leaving directory 
'/srv/http/org.webfreak.symbols/clones-2020-01-04_00-35-08/5dafbb00bce0bf24b5b71996-autowrap/pynih'
Invalid source/import path: 
/srv/http/org.webfreak.symbols/clones-2020-01-04_00-35-08/5dafbb00bce0bf24b5b71996-autowrap/python/source
Invalid source/import path: 
/srv/http/org.webfreak.symbols/clones-2020-01-04_00-35-08/5dafbb00bce0bf24b5b71996-autowrap/python/source
Invalid variable: PYTHON_LIB_DIR
Jan 07 2020
parent reply Atila Neves <atila.neves gmail.com> writes:
On Tuesday, 7 January 2020 at 11:12:28 UTC, WebFreak001 wrote:

 On Tuesday, 7 January 2020 at 10:43:44 UTC, Atila Neves wrote:

 On Monday, 6 January 2020 at 23:05:29 UTC, WebFreak001 wrote:

 [...]


 Update:
 now built using
 phobos commit c039fed84 (std.bitmanip.bitfields issues fixed)
 dmd commit 0ab7e90df (changes delegate to  safe by default)

 [...]


 There are still false negatives - autowrap definitely builds.


 Running pre-generate commands for autowrap:pynih...
 make: Entering directory 
 '/srv/http/org.webfreak.symbols/clones-2020-01-04_00-35-08/5dafbb00bce0bf24b5b71996-autowrap/pynih'
 make: 'source/python/raw.d' is up to date.
 make: Leaving directory 
 '/srv/http/org.webfreak.symbols/clones-2020-01-04_00-35-08/5dafbb00bce0bf24b5b71996-autowrap/pynih'
 Invalid source/import path: 
 /srv/http/org.webfreak.symbols/clones-2020-01-04_00-35-08/5dafbb00bce0bf24b5b71996-autowrap/python/source
 Invalid source/import path: 
 /srv/http/org.webfreak.symbols/clones-2020-01-04_00-35-08/5dafbb00bce0bf24b5b71996-autowrap/python/source
 Invalid variable: PYTHON_LIB_DIR


Ah. I guess this project assumes that every project can be 
built/tested with dub as-is (dub build / dub test). For the ones 
with .travis.yml files it might be worth parsing the YAML and 
running the "script" section instead (it'll usually be dub test 
anyway).
Jan 07 2020
next sibling parent Jon Degenhardt <jond noreply.com> writes:
On Tuesday, 7 January 2020 at 16:45:09 UTC, Atila Neves wrote:

 On Tuesday, 7 January 2020 at 11:12:28 UTC, WebFreak001 wrote:

 On Tuesday, 7 January 2020 at 10:43:44 UTC, Atila Neves wrote:

 On Monday, 6 January 2020 at 23:05:29 UTC, WebFreak001 wrote:

 [...]


 Update:
 now built using
 phobos commit c039fed84 (std.bitmanip.bitfields issues fixed)
 dmd commit 0ab7e90df (changes delegate to  safe by default)

 [...]


 There are still false negatives - autowrap definitely builds.


 Running pre-generate commands for autowrap:pynih...
 make: Entering directory 
 '/srv/http/org.webfreak.symbols/clones-2020-01-04_00-35-08/5dafbb00bce0bf24b5b71996-autowrap/pynih'
 make: 'source/python/raw.d' is up to date.
 make: Leaving directory 
 '/srv/http/org.webfreak.symbols/clones-2020-01-04_00-35-08/5dafbb00bce0bf24b5b71996-autowrap/pynih'
 Invalid source/import path: 
 /srv/http/org.webfreak.symbols/clones-2020-01-04_00-35-08/5dafbb00bce0bf24b5b71996-autowrap/python/source
 Invalid source/import path: 
 /srv/http/org.webfreak.symbols/clones-2020-01-04_00-35-08/5dafbb00bce0bf24b5b71996-autowrap/python/source
 Invalid variable: PYTHON_LIB_DIR


 Ah. I guess this project assumes that every project can be 
 built/tested with dub as-is (dub build / dub test). For the 
 ones with .travis.yml files it might be worth parsing the YAML 
 and running the "script" section instead (it'll usually be dub 
 test anyway).


The CI system has entries for custom build instructions 
(https://github.com/dlang/ci/blob/master/buildkite/build_project.sh#L124).
Something similar could work for this. If available in a public repo then
project owners could submit the instructions for their own repos.

Such a setup could also provide a place to add projects that 
don't have dub entries. tilix, onedrive, and sambamba, are highly 
starred github projects that don't have dub entries. Including a 
few of these would be ideal. Of course, this would raise the cost 
of running building and running the tests.

A perhaps cheaper option would be to setup special builds of the 
CI buildkite tests that turn on safety by default. A much smaller 
set of projects, but would provide more detailed info.
Jan 07 2020
prev sibling parent reply WebFreak001 <d.forum webfreak.org> writes:
On Tuesday, 7 January 2020 at 16:45:09 UTC, Atila Neves wrote:

 On Tuesday, 7 January 2020 at 11:12:28 UTC, WebFreak001 wrote:

 On Tuesday, 7 January 2020 at 10:43:44 UTC, Atila Neves wrote:

 On Monday, 6 January 2020 at 23:05:29 UTC, WebFreak001 wrote:

 [...]


 Update:
 now built using
 phobos commit c039fed84 (std.bitmanip.bitfields issues fixed)
 dmd commit 0ab7e90df (changes delegate to  safe by default)

 [...]


 There are still false negatives - autowrap definitely builds.


 Running pre-generate commands for autowrap:pynih...
 make: Entering directory 
 '/srv/http/org.webfreak.symbols/clones-2020-01-04_00-35-08/5dafbb00bce0bf24b5b71996-autowrap/pynih'
 make: 'source/python/raw.d' is up to date.
 make: Leaving directory 
 '/srv/http/org.webfreak.symbols/clones-2020-01-04_00-35-08/5dafbb00bce0bf24b5b71996-autowrap/pynih'
 Invalid source/import path: 
 /srv/http/org.webfreak.symbols/clones-2020-01-04_00-35-08/5dafbb00bce0bf24b5b71996-autowrap/python/source
 Invalid source/import path: 
 /srv/http/org.webfreak.symbols/clones-2020-01-04_00-35-08/5dafbb00bce0bf24b5b71996-autowrap/python/source
 Invalid variable: PYTHON_LIB_DIR


 Ah. I guess this project assumes that every project can be 
 built/tested with dub as-is (dub build / dub test). For the 
 ones with .travis.yml files it might be worth parsing the YAML 
 and running the "script" section instead (it'll usually be dub 
 test anyway).


well this project should just give a general idea of the state of 
the ecosystem and not fully be able to build all projects. Right 
now this is a 50 line D file I manually run inside a GNU screen 
on a copy of my dub projects folder and then sort the output 
index.html using vim :p

In reality a few more projects will actually build properly 
there, but a lot of project which currently are marked as working 
won't actually work because of used templates not being 
instantiated right now.

So only really by having broken applications using the libraries 
it's possible to know which libraries are broken.
Jan 07 2020
parent Mathias Lang <pro.mathias.lang gmail.com> writes:
On Tuesday, 7 January 2020 at 21:04:38 UTC, WebFreak001 wrote:

 well this project should just give a general idea of the state 
 of the ecosystem and not fully be able to build all projects. 
 Right now this is a 50 line D file I manually run inside a GNU 
 screen on a copy of my dub projects folder and then sort the 
 output index.html using vim :p

 In reality a few more projects will actually build properly 
 there, but a lot of project which currently are marked as 
 working won't actually work because of used templates not being 
 instantiated right now.

 So only really by having broken applications using the 
 libraries it's possible to know which libraries are broken.


Replying to 
https://forum.dlang.org/post/kgztbeomocgzyiylamwn forum.dlang.org 
as well.

Thanks for the explanation. So what happens is that, thanks to 
`-b syntax`, semantic3 is not called on the functions which are 
outside the (dub) package. In other word, the following code:
```
--- foo.d
module foo;
import bar;
void main ()  safe
{
     callSafe();
}
--- bar.d
module bar;
void callSafe()  safe
{
     notReally();
}
void notReally()  system {}
```

Will not error out (try it: `dmd -o- foo.d`). Which is the 
expected behavior in that case.

So all we need now is to have explicit ` system` on all 
functions, as Walter has proposed in the other thread.
Jan 08 2020
prev sibling parent reply Andrea Fontana <nospam example.com> writes:
On Monday, 6 January 2020 at 23:05:29 UTC, WebFreak001 wrote:

 I think we can still fix a little bit but I don't think we can 
 go above 50% just by fixing phobos, dependencies on dub now 
 also need to be updated (my index currently only uses a fixed 
 version and isn't updated with any new releases)


We should try to write a tool like dustmite to annotate 
everything with  system and then removing the  system annotations 
while it works. :)
Jan 07 2020
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Jan 07, 2020 at 11:12:14AM +0000, Andrea Fontana via Digitalmars-d
wrote:

 On Monday, 6 January 2020 at 23:05:29 UTC, WebFreak001 wrote:

 
 I think we can still fix a little bit but I don't think we can go
 above 50% just by fixing phobos, dependencies on dub now also need
 to be updated (my index currently only uses a fixed version and
 isn't updated with any new releases)


 
 We should try to write a tool like dustmite to annotate everything
 with  system and then removing the  system annotations while it works.
 :)


This is actually a good idea!  It would alleviate the tedium of doing it
manually, and it can be run as an upgrade tool on your source tree and
more-or-less guarantee compilable code afterwards.  This should address
many of the complaints about code breakage.


T

-- 
2+2=4. 2*2=4. 2^2=4. Therefore, +, *, and ^ are the same operation.
Jan 07 2020
prev sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Tuesday, January 7, 2020 11:44:15 AM MST H. S. Teoh via Digitalmars-d 
wrote:

 On Tue, Jan 07, 2020 at 11:12:14AM +0000, Andrea Fontana via Digitalmars-d 


wrote:

 On Monday, 6 January 2020 at 23:05:29 UTC, WebFreak001 wrote:

 I think we can still fix a little bit but I don't think we can go
 above 50% just by fixing phobos, dependencies on dub now also need
 to be updated (my index currently only uses a fixed version and
 isn't updated with any new releases)


 We should try to write a tool like dustmite to annotate everything
 with  system and then removing the  system annotations while it works.

 :)


 This is actually a good idea!  It would alleviate the tedium of doing it
 manually, and it can be run as an upgrade tool on your source tree and
 more-or-less guarantee compilable code afterwards.  This should address
 many of the complaints about code breakage.


One thing anyone writing such a tool would have to remember though is that
any functions within a template or which have their return type inferred
shouldn't have any attributes slapped on them, because they're inferred for
those types of functions.

- Jonathan M Davis
Jan 07 2020
prev sibling next sibling parent Gregor =?UTF-8?B?TcO8Y2ts?= <gregormueckl gmx.de> writes:
On Saturday, 4 January 2020 at 15:19:39 UTC, WebFreak001 wrote:

 I only test git packages, so your package is not processed 
 because:

 remote: Mercurial (hg) is required to use this repository.
 remote:
 remote: https://confluence.atlassian.com/x/vLRCMw
 fatal: unable to access 'https://bitbucket.org/gmueckl/sml-d/': 
 The requested URL returned error: 405


Thanks for looking into this. Good to know the cause. There's 
probably not a lot of packages using Mercurial, so this shouldn't 
skew the results much.
Jan 04 2020
prev sibling next sibling parent reply Paul Backus <snarwin gmail.com> writes:
On Saturday, 4 January 2020 at 15:19:39 UTC, WebFreak001 wrote:

 On Saturday, 4 January 2020 at 14:46:40 UTC, Gregor Mückl wrote:

 On Saturday, 4 January 2020 at 10:22:34 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






You have a spurious failure for sumtype v0.9.4 because you are 
compiling with DMD 2.060, an unsupported compiler version. Using 
the most recent stable DMD release will probably give you better 
results.
Jan 04 2020
parent reply WebFreak001 <d.forum webfreak.org> writes:
On Saturday, 4 January 2020 at 17:07:32 UTC, Paul Backus wrote:

 On Saturday, 4 January 2020 at 15:19:39 UTC, WebFreak001 wrote:

 On Saturday, 4 January 2020 at 14:46:40 UTC, Gregor Mückl 
 wrote:

 On Saturday, 4 January 2020 at 10:22:34 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






 You have a spurious failure for sumtype v0.9.4 because you are 
 compiling with DMD 2.060, an unsupported compiler version. 
 Using the most recent stable DMD release will probably give you 
 better results.


thanks I fixed the tags and am updating it right now with the 
bitfields patch applied
Jan 04 2020
parent WebFreak001 <d.forum webfreak.org> writes:
On Saturday, 4 January 2020 at 21:38:32 UTC, WebFreak001 wrote:

 On Saturday, 4 January 2020 at 17:07:32 UTC, Paul Backus wrote:

 On Saturday, 4 January 2020 at 15:19:39 UTC, WebFreak001 wrote:

 On Saturday, 4 January 2020 at 14:46:40 UTC, Gregor Mückl 
 wrote:

 On Saturday, 4 January 2020 at 10:22:34 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






 You have a spurious failure for sumtype v0.9.4 because you are 
 compiling with DMD 2.060, an unsupported compiler version. 
 Using the most recent stable DMD release will probably give 
 you better results.


 thanks I fixed the tags and am updating it right now with the 
 bitfields patch applied


alright changing this has fixed 8 packages in total building 
properly now. (unknown about other packages still not building 
properly, but at least meeting toolchain requirements)
Jan 04 2020
prev sibling next sibling parent reply JN <666total wp.pl> writes:
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.
Jan 04 2020
parent reply WebFreak001 <d.forum webfreak.org> writes:
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
Jan 04 2020
next sibling parent reply Jon Degenhardt <jond noreply.com> writes:
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
Jan 04 2020
next sibling parent Jon Degenhardt <jond noreply.com> writes:
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
Jan 04 2020
prev sibling parent reply ag0aep6g <anonymous example.com> writes:
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
Jan 04 2020
parent reply Jon Degenhardt <jond noreply.com> writes:
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.
Jan 04 2020
parent reply Jon Degenhardt <jond noreply.com> writes:
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?
Jan 04 2020
parent James Blachly <james.blachly gmail.com> writes:
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]
Jan 06 2020
prev sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
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
Jan 04 2020
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
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...
Jan 04 2020
parent Paul Backus <snarwin gmail.com> writes:
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?
Jan 04 2020
prev sibling parent WebFreak001 <d.forum webfreak.org> writes:
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
Jan 05 2020
prev sibling parent ShadoLight <ettienne.gilbert gmail.com> writes:
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
Jan 05 2020