core.atomic.cas: add 'const' attribute to local variable 'arg1'

[thaven]

Avoid possible unnecessary const to mutable conversion, which is not implicit for pointers. See Issue 21631 for details.

[dlang-bot]

Thanks for your pull request and interest in making D better, @thaven! 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 coverage diff by visiting the details link of the codecov check)
• 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
✓	21631	normal	core.atomic.cas fails to compile with const ifThis (if target is a pointer)

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub run digger -- build "master + druntime#3373"

[RazvanN7]

This seems to break both the dmd's and phobos's test suites.

[Geod24]

That looks like an invalid issue to me. You should not be able to store a const pointer in a non-const pointer.
The code is essentially trying to do the following:

const(int)* ptr;
int* ptr = ptr;

Which is not sound.

[thaven]

@Geod24 not really. The case is more like:

int* a;
const(int)* b;
int* c;

if (a is b)
    a = c;

So it is just comparing pointer to const against pointer to mutable.

[Geod24]

Oh, I see. Indeed. However using const is not going to cut it. Those "implicit conversions" statements IMO are wrong and shouldn't be there. But you'd have to dig the git history to see why they are there in the first place.

[thaven]

Those statements seem to originate from this commit: 1b13903 from PR #2745

[RazvanN7]

ping @thaven . How do we proceed here?

[thaven]

It all depends on what to do about the assignments to 'resolve implicit conversions'. I guess those are there to get more clear error messages in case of a type error related to cas arguments. Maybe @TurkeyMan can shed some light on that.

Anyway, the mere presence of those lines doesn't cause the issue, it's the wrong type on arg1.

[RazvanN7]

This seems to be passing all tests now.