Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Appearance settings

Conversation

ada4a
Copy link
Contributor

@ada4a ada4a commented Oct 13, 2025

Resolves #3440

changelog: [cast_ptr_alignment]: also lint to-types with unknown alignment

Copy link

github-actions bot commented Oct 13, 2025

Lintcheck changes for 3d18841

Lint Added Removed Changed
clippy::cast_ptr_alignment 30 0 1

This comment will be updated if you push new changes

@ada4a ada4a force-pushed the cast_alignment branch 2 times, most recently from 3cc75c8 to 0f51832 Compare October 14, 2025 10:18
Copy link
Member

@Centri3 Centri3 left a comment

Choose a reason for hiding this comment

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

},
Err(LayoutError::TooGeneric(too_generic_ty)) => {
// a maximally aligned type can be aligned down to anything
if from_layout.align.abi != Align::MAX {
Copy link
Member

Choose a reason for hiding this comment

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

Can you elaborate on this check? I might just be missing something.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Right, that part was a bit awkward to explain -- how about something like this?

// If the from-type already has the maximum possible alignment, then, whatever the unknown alignment
// of the to-type is, it can't possibly be stricter than that of the from-type

Copy link
Member

@Centri3 Centri3 Oct 17, 2025

Choose a reason for hiding this comment

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

Ohh!! Okay I got it now ignore me 😅.

How about something like this?:

// When the to-type has a lower alignment, it's always properly aligned when cast. Only when the to-type has a higher alignment can it not be properly aligned (16 -> 32, 48 is not a multiple of 32!). With the maximum possible alignment, there is no "higher alignment" case.

Copy link
Member

@Centri3 Centri3 Oct 17, 2025

Choose a reason for hiding this comment

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

I just found this a bit confusing and I think elaborating on why we're linting only the higher alignment case somewhere could be helpful to others

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hm, the first two sentences honestly apply to the whole lint, so maybe I could put them onto the match?

diff --git i/clippy_lints/src/casts/cast_ptr_alignment.rs w/clippy_lints/src/casts/cast_ptr_alignment.rs
index 12057fd40..76f4ae00e 100644
--- i/clippy_lints/src/casts/cast_ptr_alignment.rs
+++ w/clippy_lints/src/casts/cast_ptr_alignment.rs
@@ -36,6 +36,9 @@ fn lint_cast_ptr_alignment<'tcx>(cx: &LateContext<'tcx>, expr: &Expr<'_>, cast_f
         && !from_layout.is_zst()
         && !is_used_as_unaligned(cx, expr)
     {
+        // When the to-type has a lower alignment, it's always properly aligned when cast. Only when the
+        // to-type has a higher alignment can it not be properly aligned (16 -> 32, 48 is not a multiple of
+        // 32!)
         match cx.layout_of(to_ptr_ty) {
             Ok(to_layout) => {
                 if from_layout.align.abi < to_layout.align.abi {
@@ -52,6 +55,7 @@ fn lint_cast_ptr_alignment<'tcx>(cx: &LateContext<'tcx>, expr: &Expr<'_>, cast_f
                 }
             },
             Err(LayoutError::TooGeneric(too_generic_ty)) => {
-                // a maximally aligned type can be aligned down to anything
+                // With the maximum possible alignment, there is no "higher alignment" case.
                 if from_layout.align.abi != Align::MAX {
                     span_lint_and_then(
                         cx,

Copy link
Member

Choose a reason for hiding this comment

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

👍

&& !from_layout.is_zst()
&& !is_used_as_unaligned(cx, expr)
{
span_lint(
Copy link
Member

Choose a reason for hiding this comment

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

(It doesn't let me select lines above this): Would you find a let-else more readable?

Copy link
Member

Choose a reason for hiding this comment

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

I generally liked them but it's up to you. I find this current version just fine too

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Do you mean something like this?

let Ok(to_layout) = cx.layout_of(to_ptry_ty) else {
    // the logic for unknown to-alignment
};

// the logic for known-more-strict to-alignment

I don't think that would be possible unfortunately, given that there are multiple kinds of LayoutError, and only LayoutError::TooGeneric gives us access to the exact part of the to-type that made it impossible to calculate the layout and therefore the alignment.

Copy link
Member

Choose a reason for hiding this comment

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

Nope! I mean replacing the whole if let. This does require a ton of returns but I personally like it. Again, up to you—implementation wise, your code is good to me

Copy link
Contributor Author

Choose a reason for hiding this comment

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

At first I thought that would only require putting returns on the let expressions, but really they would be required on the rest of the expression as well, meaning 6 returns in total, which.. I'm not sure is really desirable? It would lead to a lot of boilerplate inbetween the actual logic...

@Centri3
Copy link
Member

Centri3 commented Oct 17, 2025

Considering this is a draft rn, what is still WIP?

@ada4a
Copy link
Contributor Author

ada4a commented Oct 17, 2025

Considering this is a draft rn, what is still WIP?

The implementation should be complete, but I wasn't sure whether this is a desirable change in the first place, which is why I added S-needs-discussion to the original issue. I guess we could start an FCP

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Cast_ptr_alignment false negative in trait method default impl

2 participants

Morty Proxy This is a proxified and sanitized view of the page, visit original site.