repr(align(n)) added to struct or enum

[max-heller]

Closes #74

Couple questions @obi1kenobi:

• Is there a difference between making separate lints for Structs and Enums vs making one for ImplOwners?
• Does rustdoc know the alignment of types without #[repr(align(n))]? It would also be semver-violating to change the alignment of a type by e.g. adding a field with higher alignment, right?

[obi1kenobi]

The query looks great! The next step I'd suggest is adding a test case, which has a handy (if unfortunately long) checklist here. Looking at the test cases for the similar lints would probably again be helpful.

• Is there a difference between making separate lints for Structs and Enums vs making one for ImplOwners?

It's predominantly a matter of providing good error messages for the user, otherwise both query approaches would catch the same things. Similarly to the Rust compiler, when the user sees an error, they are already disappointed that something has gone wrong and we need to give them the most clear and actionable information possible so as to make the fix process as smooth as possible. It's worth making it a bit inconvenient for us to write these "more detailed than strictly necessary" checks if that produces a better user experience for folks seeing the error, because we write these checks ~once but users will see them thousands of times or more.

This is your PR, so it's ultimately your call. Consider the error message the user should see. Would it help the user to know if the problematic type is an enum or struct or union or something else? Would we have different advice to give the user depending on whether the type is an enum or struct or union or something else?

• Does rustdoc know the alignment of types without #[repr(align(n))]? It would also be semver-violating to change the alignment of a type by e.g. adding a field with higher alignment, right?

I believe that the alignment of types without explicit #[repr(align(...))] is not defined, so it also won't be in the rustdoc JSON since it can't be depended on. But I think it would be semver-major to change the alignment from one #[repr(align(...))] to another #[repr(align(...))] value — you're welcome to open a PR for that as well, if you'd like, since the query will be very similar to the one here.

I'm not sure if adding a field with higher alignment would change the alignment of the parent type, though. It seems to me like it might not? But these things are tricky. The Nomicon might have more information, and if not, then in my experience, trying to write an example piece of code that gets broken by that change is the best way to be sure.

[obi1kenobi]

Just a heads-up that in the interest of making it easier to merge this crate into cargo, the plan is to change the license to Apache 2.0 OR MIT (matching cargo's own licensing) from the original Apache 2.0: #84

If that's alright with you, then please proceed with the PR 😊 If not, then I'm afraid we won't be able to merge the changes since that could prevent merging into cargo, which would be extremely undesirable.

[obi1kenobi]

No rush at all, just checking in to see how you're doing. Any questions? Anything I can do to help?

[max-heller]

Just a bit busy with classes starting up, should be able to wrap things up next weekend.

[obi1kenobi]

No worries at all, just wanted to make sure you aren't blocked on something I could help with 👍 Good luck with classes!

[obi1kenobi]

Hi! We recently merged a significant revamp of the directory structure and how the tests are organized, and if you're interested in continuing with this PR either now or in January, I wanted to let you know that I'd be happy to help.

If you've moved on to other projects, that's totally fine — no worries! Just let me know so I can reassign this lint to someone else.

If I don't hear back by Jan 15, I'll assume you've moved on to other things and I'll close this PR.

[obi1kenobi]

Closing as abandoned by the author, without prejudice. We'd love to have you back!