Fix Issue 13392 and 11294 - class + alias this + cast(void*) == overzealous cast

[RazvanN7]

Again op_overload mixes semantics. Before this patch when op_overload was called for a cast expression,
the result could mean 2 things: either an opCast exists or there is an alias this to be used for casting. 2 different semantics squashed in the same function call.

[dlang-bot]

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
✓	11294	normal	Object destruction with alias this
✓	13392	normal	class + alias this + cast(void*) == overzealous cast

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

[thewilsonator]

Running ../dmd/generated/linux/release/64/dmd...
--
  | Serializing composite type BuildRequirements which has no serializable fields
  | Serializing composite type BuildOptions which has no serializable fields
  | source/dub/generators/generator.d(399): Error: template `std.typecons.BitFlags!(BuildOption, cast(Flag)false).BitFlags.opCast` does not match any template declaration

[RazvanN7]

@thewilsonator dlang/dub#1600

[thewilsonator]

You'll need to give this a kick to restart the doc tester.

[RazvanN7]

Is it failing spuriously? I can't imagine how my patch would affect the documentation tester.

[RazvanN7]

Buildkite is failing. I have to investigate.

[RazvanN7]

dls looks like is using an older version of dub

[thewilsonator]

Any idea why iz and mir-algorithm segfault?

[RazvanN7]

@thewilsonator I fixed those. It was an implementation problem. dls is still failing because it is not using the latest version of dub.

@wilzbach Anything we can do about this, except from making a PR to change the dub version in dls?

[thewilsonator]

Thanks.

[RazvanN7]

I think we should wait until we fix dls before merging this, otherwise we will end up failing buildkite for the entire PR queue.

[thewilsonator]

dls has a dub.selections.json committed to the repo (which I think is usually placed under a .gitignore but w/e) but it is using the latest tag of dub. Do we need to do another tag of dub?

[PetarKirov]

@s-ludwig @MartinNowak @wilzbach what do you think about allowing out-of-band patch releases for dub? What I propose is to allow tagging new patch releases, so that projects using dub as a library could receive bug fixes without waiting for a new dmd release.
In this case, we need a new patch release including dlang/dub#1600, in order to make https://github.com/d-language-server/dls compatible with this dmd PR.

The process should be as simple and fast as pushing a new tag to the dub repo. I don't think anything else would be needed.

[s-ludwig]

No real objection from my side, I've even done out-of-band patch releases a few times in the past. However, the change log process has changed recently, which may be a problem. The version file also needs to be updated in addition to the tag.

[wilzbach]

@s-ludwig @MartinNowak @wilzbach what do you think about allowing out-of-band patch releases for dub? What I propose is to allow tagging new patch releases, so that projects using dub as a library could receive bug fixes without waiting for a new dmd release.
In this case, we need a new patch release including dlang/dub#1600, in order to make https://github.com/d-language-server/dls compatible with this dmd PR.

The process should be as simple and fast as pushing a new tag to the dub repo.

Sure, we have done so before, but only as e.g. 1.12.0-1 as then @MartinNowak's release scripts don't need adaption.
Also, it needs to be done from stable and the PR still needs to be cherry-picked to it as the PR was targetting master.

I don't think anything else would be needed.

If DLS has a dub.selections.json, that one might need to be updated and a new version of DLS would need to be tagged too.

[wilzbach]

Also, it needs to be done from stable and the PR still needs to be cherry-picked to it as the PR was targetting master.

-> dlang/dub#1601

[jacob-carlborg]

dls has a dub.selections.json committed to the repo (which I think is usually placed under a .gitignore but w/e) but it is using the latest tag of dub. Do we need to do another tag of dub?

@thewilsonator dub.selections.json should be committed for applications but ignored for libraries.

[PetarKirov]

If DLS has a dub.selections.json, that one might need to be updated and a new version of DLS would need to be tagged too.

Yeah, see: d-language-server/dls#17.

Also, it needs to be done from stable and the PR still needs to be cherry-picked to it as the PR was targetting master.

-> dlang/dub#1601

Thanks!

[wilzbach]

Restarted the dls build as a new version which selects dub v1.12.1-alpha.1 should be up now.

[RazvanN7]

All green! @thewilsonator