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.

Sign up for GitHub

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

Jump to bottom

ICE: function not fully analyzed; previous unreported errors compiling std.variant.VariantN!(16LU, int, string).VariantN.__xopEquals? #1698

Closed
ximion opened this issue Aug 16, 2016 · 8 comments
Closed

ICE: function not fully analyzed; previous unreported errors compiling std.variant.VariantN!(16LU, int, string).VariantN.__xopEquals? #1698

ximion opened this issue Aug 16, 2016 · 8 comments

Comments

@ximion
Copy link
Contributor

ximion commented Aug 16, 2016

This is a "spinoff" of issue #1696

I am split-compiling a project. After fixing a lot of issues in the form of:
error: module utils from file /path/to/project/source/mod/utils.d conflicts with another module utils from file source/mod/utils.d

I "fixed" them by manually defining module for those projects. This smells like another bug, since there was no actual conflict - the paths are the same, the only exception is that one is absolute and the other one is relative.

After resolving these issues, LDC now runs into an ICE when compiling the project:

ldc2  '-Iasgen@exe' '-I..' '-I.' '-Isource/' '-I../source/' '-Isource/bindings/auto' '-I../source/bindings/auto' '-I/usr/include/d/mustache-d/src/' '-I/usr/include/d/mustache-d/src/' '-w' '-g'  -of 'asgen@exe/source_engine.d.o' -c ../source/engine.d
Error: Internal Compiler Error: function not fully analyzed; previous unreported errors compiling std.variant.VariantN!(16LU, int, string).VariantN.__xopEquals?

Any idea what could be wrong here? Can I get LDC to show the "unreported errors" somehow?
@ximion ximion changed the title ICE: : function not fully analyzed; previous unreported errors compiling std.variant.VariantN!(16LU, int, string).VariantN.__xopEquals? ICE: function not fully analyzed; previous unreported errors compiling std.variant.VariantN!(16LU, int, string).VariantN.__xopEquals? Aug 16, 2016
@ximion ximion mentioned this issue Aug 17, 2016
Closed
@kinke
Copy link
Member

kinke commented Aug 18, 2016 •
edited

What you're running into is this, so apparently the automatically generated __xopEquals() function is missing some semantic passes. Sounds interesting, and a reduced test case would be nice (dustmite?).

@ximion
Copy link
Contributor Author

ximion commented Aug 18, 2016

First of all, Dustmite is amazing! It's an incredibly helpful tool!
Here is a minimized testcase, reproducing this ICE: ldc_testcase-ICE_1698.zip

@kinke
Copy link
Member

kinke commented Aug 19, 2016 •
edited

Hmm this is a strange one. I reduced it to:

M.d:

import N;

void foo(C) {}

N.d:

import std.variant;

class E {
    this(void delegate() ) {}
}

class R
{
    Algebraic!int[string][] W;

    auto Y()
    {
        new E(
        {
            foreach (AB; W) AB["path"].get!string;
        });
    }
}

class C
{
    R DB;
}
  1. ldc2 -c M.d results in the ICE.
  2. As soon as the return type of method N.R.Y() is changed from auto to void, it compiles fine.
  3. If the return type is left at auto and the lambda is rewritten from { <body> } to () => { <body> }, LDC complains: N.d(13): Error: constructor N.E.this (void delegate()) is not callable using argument types (void delegate() @system delegate() pure nothrow @nogc @safe). If the return type of Y() is again changed to void, it compiles fine again.
  4. DMD nightly from a week ago or so compiles all these cases without issues.

@kinke
Copy link
Member

kinke commented Aug 19, 2016 •
edited

Hmm it gets a bit stranger when actually using Y() in module M. M.d:

import N;

void foo(C c) { c.DB.Y(); }
  1. LDC's ICE is gone with original N.d.
  2. When using the () => lambda prefix, DMD shows the same error message as LDC. Changing the return type of Y() to void fixes things. Edit: The prefix was wrong, it should be () { ... }.

So there seems to be at least one front-end bug wrt. return type deduction and the full lambda syntax.

@kinke
Copy link
Member

kinke commented Aug 19, 2016

N.d, a bit shorter and still causing the LDC ICE:

import std.variant;

class C
{
    Algebraic!int[string][] W;

    auto foo()
    {
        auto d = {
            foreach (w; W)
                w["path"].get!string;
        };
    }
}

@kinke
Copy link
Member

kinke commented Aug 19, 2016 •
edited

The difference between auto and void return types, in the -vv log, is that we're doing an additional semantic3 pass for auto here when generating the vtable, and that may pull in the std.variant stuff (we end up trying to emit the Algebraic TypeInfo and fail to define its __xopEquals).

kinke added a commit to kinke/ldc that referenced this issue Aug 19, 2016
@kinke
Run semantic3() before defining special member functions (xopEquals e…
642ca60 
…tc.)

This fixes issue ldc-developers#1698.
This was referenced Aug 19, 2016
Merged
Closed
dnadlinger added a commit that referenced this issue Aug 20, 2016
@dnadlinger
Merge pull request #1709 from kinke/fix1698
c379d79 
Fix issue #1698 (missing semantic3() for special member functions)
kinke added a commit that referenced this issue Aug 20, 2016
@kinke
dmd-testsuite: Add test for issue #1698 / #1360
18809fb
@ximion
Copy link
Contributor Author

ximion commented Aug 20, 2016

Nice, thank you for investigating & resolving this issue!

@kinke
Copy link
Member

kinke commented Aug 20, 2016

You're welcome; thanks for the report, as I'm sure others would have run into this sooner or later too (or already had).

@PaulDiraq PaulDiraq mentioned this issue Jul 5, 2017
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@dnadlinger @ximion @kinke