-
-
Notifications
You must be signed in to change notification settings - Fork 607
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 Bugzilla 24434 - Casting away const with cast() is not a @safe lv… #16315
Conversation
Thanks for your pull request and interest in making D better, @ntrel! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
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
|
That is triggered in U[] res;
foreach (ref e; a)
res ~= e; // this line So I'm not sure how to fix that. Also the error should maybe be a deprecation. |
Yes, before we have editions, you can use |
See dlang/dmd#16315 With that pull, using a type qualifier cast is not @safe to use as an lvalue.
See dlang/dmd#16315 With that pull, using a type qualifier cast is not @safe to use as an lvalue.
Looks like libdparse needs to be updated? (or not compiled with |
I find it icky that the fix is located in a function that is queried for finding the lvalueness of an expression. There is a function called On a different note: casting away a qualifier returns an lvalue irrespective of the fact if we are in safe code or not. I think that we should just consider banning casting away qualifiers in @safe code. That will put as to safety with regards to code such as this: void main() @safe
{
const int i = 2;
cast()i = 3;
} This currently compiles, and I don't think this patch solves this case (athough, IMO it should). |
@RazvanN7 isSafeCast doesn't know about lvalues. So I tried making even lvalue QualCast unsafe:
utf.d has lots of The algebraic.d one is There is an advantage that this doesn't need the duplication.d change of this pull, which creates a copy instead of
It actually does detect that. I'll add it to the test later. |
Needed for dlang/dmd#16315.
Needed for dlang/dmd#16315.
I undid that change, it is not necessary now I'm doing the check for a qualifier cast correctly. |
Now broken - somehow the |
Fixes Bugzilla 23530 - casting immutable away allowed in safe.
As I can't detect a qualifier cast in toLvalue, I decided to also fix the non-qualifier unsafe lvalue cast bug too. I found the CatAssignExp semantic code that calls castTo for a safe append and added a workaround. |
buildkite is failing on phobos because libdparse 0.19.4 doesn't have the upstream fix:
|
Ping. So does this mean we have to wait for libdparse to be released with the fix before this can be merged? |
Yes, we need to fix libdparse, however, the fix seems trivial. |
@RazvanN7 The fix is already merged: dlang-community/libdparse#514 Does the phobos buildkite test require libdparse to be the last released version? |
See dlang/dmd#16315 With that pull, using a type qualifier cast is not @safe to use as an lvalue.
Currently it is testing against libdparse 0.19.4. The current release of libdparse is 0.23.2 released July 2023. |
@ntrel Phobos seems to continue failing. Does this need a rebase? |
@RazvanN7 There's been a libdparse v0.24.0 release with the fix but I'm not sure where the file is that specifies 0.19.4 for buildkite - @thewilsonator any idea? |
I think it's dlang/tools#471, and dlang/dlang.org#3815 might also be necessary |
buildkite now passing! |
…alue