Skip to content
This repository has been archived by the owner on Oct 12, 2022. It is now read-only.

Moved move, moveEmplace, and forward to core.lifetime #2442

Merged
merged 1 commit into from
Jan 8, 2019

Conversation

TurkeyMan
Copy link
Contributor

@TurkeyMan TurkeyMan commented Jan 5, 2019

WIP, I still need to wrangle phobos dependencies...

@dlang-bot
Copy link
Contributor

Thanks for your pull request and interest in making D better, @TurkeyMan! 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 annotated coverage diff directly on GitHub with CodeCov's browser extension
  • 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 fetch digger
dub run digger -- build "master + druntime#2442"

@thewilsonator
Copy link
Contributor

src/core/lifetime.d(307): Deprecation: module `core.internal.traits` member `maxAlignment` is not visible from module `lifetime`
src/core/lifetime.d(1323): Error: template instance `AliasSeq!(fwd, forward!(args[1 .. __dollar]))` template `AliasSeq` is not defined
src/core/lifetime.d(1358): Error: template instance `core.lifetime.__unittest_L1353_C7.bar!(int, string).bar.forward!(_param_0, _param_1)` error instantiating

Looks like you need to explicitly import core.interal.traits.

@TurkeyMan
Copy link
Contributor Author

Yup, is WIP. Just here so people can complain eagerly ;)

@PetarKirov
Copy link
Member

There'll be nothing to complain when the build is fixed ;) Thanks for taking the initiative!

@TurkeyMan
Copy link
Contributor Author

WTF is with Phobos!! The dependence hierarchies are all completely insane!
This is basically impossible, the dependency graph is just wild... move pulls the whole universe!
Check out C++'s std::move, it should be that simple!

@TurkeyMan
Copy link
Contributor Author

I'm not sure what the go with this error is...
I cut and pasted the code from phobos verbatim, and this test works there :/

@wilzbach
Copy link
Member

wilzbach commented Jan 5, 2019

CI says:

src/core/lifetime.d(1904): Error: struct `core.lifetime.__unittest_L1934_C7.NoCopy` is not copyable because it is annotated with `@disable`
src/core/lifetime.d(1715): Error: template instance `core.lifetime.moveEmplace!(NoCopy[2])` error instantiating
src/core/lifetime.d(1709):        instantiated from here: `moveImpl!(NoCopy[2])`
src/core/lifetime.d(1667):        instantiated from here: `trustedMoveImpl!(NoCopy[2])`
src/core/lifetime.d(1948):        instantiated from here: `move!(NoCopy[2])`
src/core/lifetime.d(1904): Error: struct `core.lifetime.__unittest_L1934_C7.NoCopy` is not copyable because it is annotated with `@disable`
src/core/lifetime.d(1715): Error: template instance `core.lifetime.moveEmplace!(NoCopy[2])` error instantiating
src/core/lifetime.d(1709):        instantiated from here: `moveImpl!(NoCopy[2])`
src/core/lifetime.d(1667):        instantiated from here: `trustedMoveImpl!(NoCopy[2])`
src/core/lifetime.d(1948):        instantiated from here: `move!(NoCopy[2])`

Does

make -f posix.mak unittest-debug

work for your locally?

@thewilsonator
Copy link
Contributor

It fails because you haven't copied all of moveEmplace, missing is:

    else static if (isStaticArray!T)
    {
        for (size_t i = 0; i < source.length; ++i)
            move(source[i], target[i]);
    }

@TurkeyMan
Copy link
Contributor Author

Oh.... shit.
I wasn't copying from phobos HEAD, I accidentally pressed "go to definition" in my editor, and it opened the version of the file from my local DMD import path from my local compiler install, which was from the last release >_<

I hope I haven't done that elsewhere!! O_O
I need to audit everything I've done!

@TurkeyMan TurkeyMan force-pushed the move_forward branch 2 times, most recently from 6bc63f1 to 37eb380 Compare January 5, 2019 20:13
Copy link
Contributor

@thewilsonator thewilsonator left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@TurkeyMan
Copy link
Contributor Author

Is this G2G? That one test fail looks completely unrelated...

@wilzbach
Copy link
Member

wilzbach commented Jan 7, 2019

Is this G2G? That one test fail looks completely unrelated...

Yup. Deprecated the build for you.

@TurkeyMan
Copy link
Contributor Author

What does that mean? Can this merge?

// static if (!is(T == class) && hasAliasing!T) if (!__ctfe)
// {
// import std.exception : doesPointTo;
// assert(!doesPointTo(source, source), "Cannot move object with internal pointer.");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How do we ensure we fix this before the next release?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can't ensure that; but I'm starting to look into core.traits, which will lead to the solution.
We are paying an obscenely high compile-time cost for this error message, and it's not even that great!

@wilzbach
Copy link
Member

wilzbach commented Jan 7, 2019

How do we ensure we fix this before the next release?

Okay, I ported doesPointTo for you to druntime. Feel free to move it to core.internal or wherever it belongs. I didn't port hasAliasing as it pulled in too much for now.

@TurkeyMan
Copy link
Contributor Author

I'm not sure your patch is right... you're missing the hasAliasing guard, which will make the assert more inclusive... false positives?

But if you wanna keep it, can you move doesPointTo to core.internal.traits? That's the appropriate dumping ground. I don't want core.lifetime to already be a dumping ground at the moment of its birth...

@wilzbach
Copy link
Member

wilzbach commented Jan 8, 2019

I'm not sure your patch is right... you're missing the hasAliasing guard, which will make the assert more inclusive... false positives?

I'm aware and I wanted to port hasAliasing too. I just ran out of time.

But if you wanna keep it, can you move doesPointTo to core.internal.traits? That's the appropriate dumping ground. I don't want core.lifetime to already be a dumping ground at the moment of its birth...

Yeah I know. Just wanted to quickly test whether it works on all CIs and didn't have much time.

@wilzbach
Copy link
Member

wilzbach commented Jan 8, 2019

That's the appropriate dumping ground

So yeah I managed to port hasAliasing and doesPointTo. It's a bit of rabbit hole though:

 2 files changed, 1922 insertions(+), 6 deletions(-)

However, of course we can remove all these lines from Phobos and replace them with aliases.

@wilzbach wilzbach force-pushed the move_forward branch 2 times, most recently from c312ede to 5df245f Compare January 8, 2019 01:02
@TurkeyMan
Copy link
Contributor Author

We can't remove them from phobos unless we put then in a public module, with doco generated and tests... then we can make phobos aliases.

@TurkeyMan
Copy link
Contributor Author

TurkeyMan commented Jan 8, 2019

See... look at that patch now... look how much code you pulled.
I got here too, and then I came to my senses, concluded that it was completely unreasonable to draw on that much code to emit an error message, and commented out the line.
I personally think the line should remain commented out ;)

I don't think the error message is reasonable with respect to the volume of supporting code.
The error's just not even that great!

@TurkeyMan
Copy link
Contributor Author

I'm not comfortable to pull this. Can you make your amendment a separate PR on top of my original one, and then we can discuss the best approach and where to draw the lines without blocking my original PR?

@wilzbach
Copy link
Member

wilzbach commented Jan 8, 2019

We can't remove them from phobos unless we put then in a public module, with doco generated and tests... then we can make phobos aliases.

Why shouldn't we be able to alias them? Even DMD's documentation generator supports exposing aliased symbols. We would just need to keep the public tests in Phobos.

@wilzbach
Copy link
Member

wilzbach commented Jan 8, 2019

concluded that it was completely unreasonable to draw on that much code

Not sure as we'll probably end up pulling most of this code from druntime at some point anyhow.

@TurkeyMan
Copy link
Contributor Author

Why shouldn't we be able to alias them?

I noticed while moving some other stuff, that the phobos stuff is not necessarily in sync with core.internal... a full audit needs to happen.
Phobos has received development, and core.internal is wherever it was when it was copied.

Any effort to create core.traits should just delete core.internal.traits, and move directly from phobos one symbol at a time.

Not sure as we'll probably end up pulling most of this code from druntime at some point anyhow.

Right, but that's a carefully considered process.

Anyway, I made a new PR where we can discuss that pickle.

@TurkeyMan
Copy link
Contributor Author

I also noticed some code in core.internal.traits which was simplified compared to the phobos source material, because a subset of functionality wasn't used by whatever caused it to be pulled in, and it minimised dependencies for unused paths.

@thewilsonator
Copy link
Contributor

Auto-merge toggled on

@wilzbach
Copy link
Member

wilzbach commented Jan 31, 2019

FYI I started to remove the now duplicate implementations in Phobos:

But we can't move emplace yet as we need a public version of emplaceRef. Though imho we should simply set it public as emplaceRef is used all over in Phobos (see e.g. https://github.com/dlang/phobos/search?q=emplaceRef&unscoped_q=emplaceRef).
It's also part of the proposed RCArray PR for druntime (#2348).

CC @edi33416

@andralex
Copy link
Member

We can for now make emplaceRef public and docummented. @wilzbach would that work?

@wilzbach
Copy link
Member

We can for now make emplaceRef public and docummented. @wilzbach would that work?

Yup, that's basically what I proposed ;-)

@andralex
Copy link
Member

Another possibility is to overload, where are the ambiguities?

This pull request was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants