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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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