Fix Issue 18157 - std.file.rmdirRecurse should be usable in @safe #7675

ljmf00 · 2020-10-22T16:56:48Z

rmdirRecurse should be @safe as the cast(string) is safe in this context and
dirEntries, even though @System, it uses a RefCounted iterator which inside
will always make the reference deleted as the reference will never be passed
outside the function scope.

Signed-off-by: Luís Ferreira contact@lsferreira.net

dlang-bot · 2020-10-22T16:56:50Z

Thanks for your pull request and interest in making D better, @ljmf00! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please verify that your PR follows this checklist:

My PR is fully covered with tests (you can see the coverage diff by visiting the details link of the codecov check)
My PR is as minimal as possible (smaller, focused PRs are easier to review than big ones)
I have provided a detailed rationale explaining my changes
New or modified functions have Ddoc comments (with Params: and Returns:)

Please see CONTRIBUTING.md for more information.

If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment.

Bugzilla references

Your PR doesn't reference any Bugzilla issue.

If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog.

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub run digger -- build "master + phobos#7675"

ljmf00 · 2020-10-22T17:11:02Z

Please tell if I'm thinking in a wrong way and there's logic that need to be added in order to make this properly @safe , but AFAIK this shouldn't be a problem.

thewilsonator

The general idea is to have @trusted as narrow in scope as possible

std/file.d

thewilsonator · 2020-10-25T01:18:39Z

std/file.d

@@ -4444,6 +4445,7 @@ void rmdirRecurse(scope const(char)[] pathname)
 }

 /// ditto
+@trusted


What needs to be @trusted in this function?

dirEntries is @System, so that's why it needs @trusted attribute. In this context, I consider this being safe because dirEntries returns a RefCounted wrapped variable, that, inside this will always be eliminated, so it doesn't make much sense to be unsafe here, IMHO.

The unsafe part is here:

foreach (DirEntry e; dirEntries(de.name, SpanMode.depth, false)) { attrIsDir(e.linkAttributes) ? rmdir(e.name) : remove(e.name); }

is it the call to dirEntries, or the iteration or both? What about rmdir/remove?

Can't we use a local @trusted lambda + a comment to make sure nothing unsafe gets added in the future?

is it the call to dirEntries, or the iteration or both? What about rmdir/remove?

both rmdir and remove uses a @trusted trustedRmdir and removeImpl respectively, so, when called it's both @safe calls.

Can't we use a local @trusted lambda + a comment to make sure nothing unsafe gets added in the future?

Sure, I'll do it.

Also, if you follow this example here,

phobos/std/datetime/timezone.d

Line 2451 in 453faad

foreach (DirEntry de; dirEntries(tzDatabaseDir, SpanMode.depth))

, they are also using dirEntries in a @trusted function, so maybe it should be a good idea to wrap it too. I'll do it in another PR.

thewilsonator · 2020-10-26T05:40:19Z

Does this have an issue number?

wilzbach

.

ljmf00 · 2020-10-26T13:48:17Z

Does this have an issue number?

Yes, https://issues.dlang.org/show_bug.cgi?id=18157 . I'll change the PR title.

Also, I don't think the dependency there to https://issues.dlang.org/show_bug.cgi?id=18155 is necessary, because, since dirEntries are using a RefConted object to increase performance and to not rely on GC.

ljmf00 · 2020-10-26T14:08:59Z

My fault, I referenced the wrong issue. Already updated the title again.

edi33416

Can it also be marked as pure?

std/file.d

ljmf00 · 2020-10-26T15:45:42Z

Can it also be marked as pure?

No. This function can't be pure in any way because it calls impure functions and this perform I/O.

@safe

`rmdirRecurse` should be @safe as the cast(string) is safe in this context and dirEntries, even though @System, it uses a RefCounted iterator which inside will always make the reference deleted as the reference will never be passed outside the function scope. Signed-off-by: Luís Ferreira <contact@lsferreira.net>

edi33416

lgtm

atilaneves · 2020-10-27T18:51:35Z

std/file.d

-        }
+        // dirEntries is @system because it uses a DirIterator with a
+        // RefCounted variable, but here, no references to the payload is
+        // escaped to the outside, so this should be @trusted


Can't this be verified by the compiler by making the ref DirEntry de scope?

No because .dirEntries is @System and scope will do nothing about safety here. RefCounted is @System because the implementation uses malloc/free.

See this interesting discussion about @safe ref counting on dlang forum: https://forum.dlang.org/thread/r8ilpu$2mk7$1@digitalmars.com

std/file.d

ljmf00 · 2020-11-02T20:14:51Z

@wilzbach the bot didn't detected the issue Fix even though merged with Fix Issue xxx https://issues.dlang.org/show_bug.cgi?id=18157. Can this be closed?

wilzbach · 2020-11-02T20:54:39Z

The bot only parses the commit messages as they are used to assemble the changelog. That's why it's important to check whether the issue displays in its commit message. We can't do much more than closing the issue manually and likely it will end up in the changelog because of the merge commit title.

ljmf00 requested a review from CyberShadow as a code owner October 22, 2020 16:56

thewilsonator reviewed Oct 25, 2020

View reviewed changes

ljmf00 requested a review from thewilsonator October 26, 2020 00:15

wilzbach reviewed Oct 26, 2020

View reviewed changes

ljmf00 force-pushed the remove-safe branch from 6221a15 to 8d9ee71 Compare October 26, 2020 13:37

ljmf00 requested a review from wilzbach October 26, 2020 13:37

ljmf00 changed the title ~~file: make rmdirRecurse @safe~~ Fix Issue 18157: file: make rmdirRecurse @safe Oct 26, 2020

ljmf00 changed the title ~~Fix Issue 18157: file: make rmdirRecurse @safe~~ Fix Issue 18155 - std.file.dirEntries should be usable in @safe Oct 26, 2020

ljmf00 changed the title ~~Fix Issue 18155 - std.file.dirEntries should be usable in @safe~~ Fix Issue 18157 - std.file.rmdirRecurse should be usable in @safe Oct 26, 2020

edi33416 requested changes Oct 26, 2020

View reviewed changes

std/file.d Outdated Show resolved Hide resolved

ljmf00 force-pushed the remove-safe branch from 8d9ee71 to a4fe9ae Compare October 26, 2020 15:46

ljmf00 requested a review from edi33416 October 26, 2020 15:46

edi33416 approved these changes Oct 26, 2020

View reviewed changes

atilaneves reviewed Oct 27, 2020

View reviewed changes

thewilsonator reviewed Oct 28, 2020

View reviewed changes

std/file.d Show resolved Hide resolved

thewilsonator approved these changes Oct 29, 2020

View reviewed changes

thewilsonator added the auto-merge label Oct 29, 2020

dlang-bot merged commit 5ce45f9 into dlang:master Oct 29, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fix Issue 18157 - std.file.rmdirRecurse should be usable in @safe #7675

Fix Issue 18157 - std.file.rmdirRecurse should be usable in @safe #7675

ljmf00 commented Oct 22, 2020

dlang-bot commented Oct 22, 2020

ljmf00 commented Oct 22, 2020 •

edited

thewilsonator left a comment

thewilsonator Oct 25, 2020

ljmf00 Oct 26, 2020

thewilsonator Oct 26, 2020

wilzbach Oct 26, 2020

ljmf00 Oct 26, 2020

thewilsonator commented Oct 26, 2020

wilzbach left a comment

ljmf00 commented Oct 26, 2020

ljmf00 commented Oct 26, 2020

edi33416 left a comment

ljmf00 commented Oct 26, 2020

edi33416 left a comment

atilaneves Oct 27, 2020

ljmf00 Oct 27, 2020

ljmf00 Oct 27, 2020

ljmf00 commented Nov 2, 2020

wilzbach commented Nov 2, 2020

Fix Issue 18157 - std.file.rmdirRecurse should be usable in @safe #7675

Fix Issue 18157 - std.file.rmdirRecurse should be usable in @safe #7675

Conversation

ljmf00 commented Oct 22, 2020

dlang-bot commented Oct 22, 2020

Bugzilla references

Testing this PR locally

ljmf00 commented Oct 22, 2020 • edited

thewilsonator left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

thewilsonator commented Oct 26, 2020

wilzbach left a comment

Choose a reason for hiding this comment

ljmf00 commented Oct 26, 2020

ljmf00 commented Oct 26, 2020

edi33416 left a comment

Choose a reason for hiding this comment

ljmf00 commented Oct 26, 2020

edi33416 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ljmf00 commented Nov 2, 2020

wilzbach commented Nov 2, 2020

ljmf00 commented Oct 22, 2020 •

edited