Skip to content

Conversation

@WalterBright
Copy link
Member

…-betterC

@dlang-bot
Copy link
Contributor

Thanks for your pull request, @WalterBright!

Bugzilla references

Auto-close Bugzilla Severity Description
18905 regression [Reg 2.079] C++ classes can no longer be used with -betterC

⚠️⚠️⚠️ Warnings ⚠️⚠️⚠️

To target stable perform these two steps:

  1. Rebase your branch to upstream/stable:
git rebase --onto upstream/stable upstream/master
  1. Change the base branch of your PR to stable

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#8304"

@WalterBright
Copy link
Member Author

The code between the new { ... } is not indented in order to keep the diffs simple. This section of code should be pulled out into a separate function, which I will do as a separate refactoring PR.

@@ -0,0 +1,3 @@
// https://issues.dlang.org/show_bug.cgi?id=18905
Copy link
Contributor

Choose a reason for hiding this comment

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

Don't you need -betterC compiler flags here? Also, you might want to add this to the existing betterc.d test file.

Copy link
Member Author

Choose a reason for hiding this comment

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

Yes, good catch!

return;
}

const bool gentypeinfo = global.params.useTypeInfo && Type.dtypeinfo;
Copy link
Contributor

Choose a reason for hiding this comment

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

If you merge dlang/druntime#2184, then you'll only need to check Type.dtypeinfo because the runtime will no longer import the TypeInfo classes when compiling with -betterC. There are other places in the DMD source code that can be simplified due to that PR.

Copy link
Member Author

Choose a reason for hiding this comment

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

I'm not so sure about that. 2184 seems to be more concerned with the nothrow issue, which is unrelated to this PR's fix. It isn't ready yet, either, and this PR fix works and is pretty simple.

Copy link
Contributor

@JinShil JinShil May 29, 2018

Choose a reason for hiding this comment

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

2184 is actually more concerned with preventing the import of code which is not relevant to a -betterC build. The nothrow addition was added because -betterC code should be nothrow at all times. If you want me to separate the two into different PRs, I can. Just let me know. And, it is all green and ready to go.

Copy link
Member Author

Choose a reason for hiding this comment

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

I'm not too happy about the nothrow business, as I mentioned. But we should discuss that elsewhere, not here. I also do not believe that 2184 will resolve this issue, as note it took two different tests to get it through the test suite, not just checking typeinfo.

Copy link
Contributor

Choose a reason for hiding this comment

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

Understood. Please see dlang/druntime#2194. It prevents unnecessary imports in -betterC, and removes the nothrow issue.

@JinShil
Copy link
Contributor

JinShil commented May 29, 2018

The code between the new { ... } is not indented in order to keep the diffs simple.

I don't think you need to worry about that anymore. GitHub now has a "Hide whitespace changes" option under the "Diff Settings" on the review tab to aid with that:

image

...but it's no big deal either way.

@WalterBright
Copy link
Member Author

I know about the no whitespace view, but I wanted to yank all that code out into a separate function anyway, and that view won't help with that. If I yank it out now, then nobody will want to review this because it's multiple screens of diffs.

@JinShil JinShil dismissed their stale review May 29, 2018 05:03

Change was made

@WalterBright
Copy link
Member Author

@CyberShadow the following error appears in the CyberShadow/DAutoTest:

posix.mak:760: recipe for target 'dpl-docs' failed

but scanning the voluminous log, I can't see what the actual error is. Please advise!

@CyberShadow
Copy link
Member

It looks like a problem with Dub. It seems to have exited with a non-zero exit code without printing an error message.

Try rebasing and force-pushing to force a rebuild.

@WalterBright
Copy link
Member Author

Try rebasing and force-pushing to force a rebuild.

Already tried it. Same result.

@CyberShadow
Copy link
Member

@s-ludwig @wilzbach Any idea?

@CyberShadow
Copy link
Member

It still looks like an intermittent failure. See http://dtest.dlang.io/history/master - a build of the master branch recently failed with a similar problem, but got fixed by itself.

@CyberShadow
Copy link
Member

Also the last stable branch build is failing with the same issue:
http://dtest.dlang.io/history/stable

@wilzbach
Copy link
Contributor

It looks like dub upgrade segfaults? IIRC you add this to the dlang.org build process as part of DAutotest?
So maybe doing gdb -return-child-result -q -ex run -ex bt -batch --args dub upgrade ... instead could help to identify the segfault?

@dlang-bot dlang-bot merged commit 3354a6b into dlang:master May 29, 2018
@WalterBright WalterBright deleted the fix18905 branch May 29, 2018 18:27
Copy link
Member

@MartinNowak MartinNowak left a comment

Choose a reason for hiding this comment

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

Should have targeted stable.

}
}
flags |= ClassFlags.noPointers;
L2:
Copy link
Member

Choose a reason for hiding this comment

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

Please avoid seemingly unrelated refactorings in bugfixes or mention why they were necessary.

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.

6 participants