Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix Issue 9274 and 11499 - is + alias this = wrong code #8839

Merged
merged 2 commits into from
Nov 6, 2018

Conversation

RazvanN7
Copy link
Contributor

@RazvanN7 RazvanN7 commented Oct 17, 2018

deduceType does what its name suggests : it deduces types. While doing so, it also checks for alias this, but it leaves no trace of whether the argument was matched through alias this or not. IsExp semantic uses deduceType for complex patterns therefore when it analyzes the code in the bug report it bounds the deduced type to the alias this leaving no trace of this whatsoever.

@andralex @WalterBright this is yet another example where having an alias this match would prove useful, but since we do not have one, this workaround is employed.

@dlang-bot
Copy link
Contributor

Thanks for your pull request and interest in making D better, @RazvanN7! 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

Auto-close Bugzilla Severity Description
9274 normal is + alias this = wrong code
11499 major is-expression misbehaving with 'alias this'

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 + dmd#8839"

Copy link
Member

@PetarKirov PetarKirov left a comment

Choose a reason for hiding this comment

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

Looks good on first look, though the ocean failure may be a genuine one:

./src/ocean/core/Traits.d(2025): Error: static assert:  "Argument has no parameters."
./src/ocean/core/Traits.d(2036):        instantiated from here: `ParameterTupleOf!(MyType)`
./src/ocean/core/Traits.d(2064):        instantiated from here: `ParameterTupleOf!(foo)`
submodules/makd/Makd.mak:595: recipe for target '/var/lib/buildkite-agent/builds/buildkite-agent-05-1/dlang/dmd/build/sociomantic-tsunami-ocean/build/production/tmp/allunittests' failed

}

static assert(!is(S == float[])); // ok
static assert(!is(S == T[], T)); // fails
Copy link
Member

@PetarKirov PetarKirov Oct 17, 2018

Choose a reason for hiding this comment

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

It's probably tested elsewhere, but I'd like to see positive tests next to the negative ones for completeness:

static assert(is(S : float[]));
static assert(is(S : T[], T));

Copy link
Contributor

Choose a reason for hiding this comment

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

Added.

}

static assert(!is(B == A!int)); // OK
static assert(!is(B == A!X, X)); // assertion fails
Copy link
Member

Choose a reason for hiding this comment

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

ditto

Copy link
Contributor

Choose a reason for hiding this comment

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

Added.

@RazvanN7
Copy link
Contributor Author

RazvanN7 commented Oct 18, 2018

@ZombineDev It seems that sociomantic-tsunami/ocean is taking advantage of the bug. The test case is the following:

template Typedef(T, string name)                                                                                                              
{
        mixin(`
            enum Typedef =
                ("static struct " ~ name ~
                "{ " ~
                "alias IsTypedef = void;" ~
                T.stringof ~ " value; " ~
                "alias value this;" ~
                "this(" ~ T.stringof ~ " rhs) { this.value = rhs; }" ~
                " }");
        `);
}

template ParameterTupleOf ( alias fn )
{
    alias ParameterTupleOf!(typeof(fn)) ParameterTupleOf;
}

template ParameterTupleOf( Fn )
{
      static if( is( Fn Params == function ) )
          pragma(msg, "function");
      else static if( is( Fn Params == delegate ) )
          pragma(msg, "delegate");
      else static if( is( Fn Params == Params* ) )
          pragma(msg, "pointer");
      else
          static assert( false, "Argument has no parameters." );
}

void main()
{
      mixin (Typedef!(void function(int, char[]), "MyType"));
      MyType foo;                                                                                                                             
      alias ParameterTupleOf!(foo) Params;
}

As you can see the type of foo is not a function, a delegate or a pointer; it's a struct and since == was used it does not match to anything. Previously, because of the bug, the struct could be implicitly converted to a function pointer through the alias this in the struct, but that was not correct behavior. I suggest that the == is actually switched to :.

I don't know what to do here, since a deprecation doesn't seem to make any sense because we are not making code that did not compile to compile (in the general case), but we are silently changing behavior.

Maybe output a warning? Or just mandate the faulting code to change the == to : ?

@jacob-carlborg
Copy link
Contributor

Maybe output a warning? Or just mandate the faulting code to change the == to : ?

Can we deprecate the existing behavior?

@RazvanN7
Copy link
Contributor Author

RazvanN7 commented Oct 18, 2018

@jacob-carlborg As I stated earlier, it's a bit weird to trigger a deprecation, because we would do it on compilable code. If folks used an is expression on a struct with an alias this we are now changing the behavior of the code, we are not triggering an error.

@PetarKirov
Copy link
Member

PetarKirov commented Oct 18, 2018

How about a transition switch?

@wilzbach
Copy link
Member

Transition switches haven't really worked in the past. Only when they were added to temporarily retain a behavior ...

@andralex
Copy link
Member

This is accept-invalid, we must simply fix it.

Copy link
Member

@andralex andralex left a comment

Choose a reason for hiding this comment

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

Please mind @ZombineDev 's suggestions.

@thewilsonator
Copy link
Contributor

(I'm assuming BuildKite was red because this PR wasn't updated after the tsunami bug was fixed. If its still red please remove the auto merge)

@RazvanN7
Copy link
Contributor Author

RazvanN7 commented Nov 6, 2018

(I'm assuming BuildKite was red because this PR wasn't updated after the tsunami bug was fixed. If its still red please remove the auto merge)

You are right, but I'm not sure what the procedure with the tsunami update is (i.e. if there's a waiting time before the changes from the sociomantic repo get pushed to the project tested by buildkite)

cc @mihails-strasuns-sociomantic

Later edit: seems that the tsunami repo passes all tests now. This is good to merge

@thewilsonator
Copy link
Contributor

ocean is green, looks like this will go straight through.

@mihails-strasuns-sociomantic
Copy link
Contributor

if there's a waiting time before the changes from the sociomantic repo get pushed to the project tested by buildkite

buildkite agent picks latest released tag automatically so it is simply a matter of waiting until release with the fix is out and restarting the build

@thewilsonator
Copy link
Contributor

@RazvanN7 Or not, semaphore timed out. Please merge it when DAutoTest is done, I'm going to sleep.

@mihails-strasuns-sociomantic Thanks! Good to know.

@RazvanN7 RazvanN7 merged commit 80ce8b1 into dlang:master Nov 6, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants