RFC: Add an attribute for raising the alignment of various items #3806
There are no files selected for viewing
|
There was a problem hiding this comment. I must also note that I have voiced, repeatedly, that attributes do not compose very well in Rust compared to things more deeply embedded in the type, and the idea that this will compose as well as it does in C seems doubtful. I have made a separate note in one case of such. Nonetheless it is obviously the case that there are many positions where this attribute is desirable to have but there is no real way to introduce it to the type, or such is not reasonable. I wish this had been more incremental, in starting with such cases first. There was a problem hiding this comment. This does, actually, seem like it's part of the unnameable type of the function itself, and that really this should be carried into the type of function pointers derived from it. The interaction of this with traits and refinement makes this more apparent. One could imagine, e.g., the function type implementing a trait like There was a problem hiding this comment. It's notable as well, in light of other recent discussions, that inverse marker effects -- i.e., constraining properties of functions -- can in theory be modeled with traits. Probably alignment isn't what we'd think of as an (inverse) effect -- it's not (the absence of) a side effect of the function that exceeds its signature -- but if we squint, it does maybe have some modeling similarities. There was a problem hiding this comment. I have hoped for some time to be able to implement instead a trait like There was a problem hiding this comment.
Added to the future possibilities. There was a problem hiding this comment. Exposing the chosen alignment as a property of the fn item type seems like a sensible extension to me (though it pokes a small hole in the arguments against I'm more worried about putting this information into fn pointer types. Those already have a lot of dimensions (safe vs unsafe, calling convention, lifetimes, and probably I'm also not sure if changing the "canonical" fn pointer type for a fn item type would be a breaking change (beyond new possibilities for inference failure). If it is, then figuring out the details about "aligned fn pointer types" might be a blocker for stabilizing There was a problem hiding this comment. It's true, we usually prefer to lean on coercions instead of subtyping for things like function pointers but that can have problems due to having coercions select different implementations for the same item according to fairly subtle rules. There was a problem hiding this comment. Not just due to which coercion is chosen, but also because coercions don't help when the type that needs coercion is behind any sort of type constructor (including very basic ones like |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -269,6 +269,13 @@ fn main() { | |
| } | ||
| ``` | ||
|
|
||
| ### `derive` macro helper ambiguity | ||
|
|
||
| Some existing `derive` macros in the ecosystem currently declare `align` as a | ||
| helper attribute. To avoid breakage, we specify that `derive` helper attributes | ||
| shadow built-in attributes of the same name (so the built-in attribute does not | ||
| take effect). A warn-by-default lint is triggered when this occurs. | ||
|
Comment on lines
+272
to
+277
There was a problem hiding this comment. you might want to link to
I don't understand it fully, but I believe that what @petrochenkov points out is that it's not so simple to have a builtin attribute shadow a user-defined procedural macro. There was a problem hiding this comment. I don’t fully understand it either, but I think we avoid the problems mentioned?
There was a problem hiding this comment. Is There was a problem hiding this comment. Yes, I am aware, there will need to be some implementation work There was a problem hiding this comment. Do you have concrete steps in mind? Presumably that work is not really blocked on the rfc, we could already implement it for the current There was a problem hiding this comment. Also FWIW, a possible option is to intentionally accept this kind of breakage. The mitigation (rename to There was a problem hiding this comment. Sure, do you feel that we have a good picture of the scope of this breakage? Based on the links at rust-lang/rust#143834, and looking at crates.io stats, these crates have low thousands number of recent downloads. On the other hand, this problem will just pop up again elsewhere. I'm just not that familiar with the name resolution details. It seems reasonable to, like the prelude, have user code override automatically imported names, but then again name resolution is infamously complex and subtle. There was a problem hiding this comment. I'm not sure re. the degree of breakage as I didn't have the bandwidth to look into how much breakage there was specifically. |
||
|
|
||
| ## On function items | ||
|
|
||
| On function items, `#[align(…)]` sets the alignment of the function’s entry | ||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have no objection per se to the introduction of
#[align]syntactically but I feel this will have a number of surprising complexities that will equate to the breaking change ofsize != stride. It feels like this tries to persuade the reader that hiding this break of assumptions in an attribute that doesn't start with#[reprwill render it harmless. If you point at something withrepr(align(N)), you are guaranteed padding that you can freely clobber, for instance, but pointers to things with this attribute have no such guarantee. This feels very likely to makeunsafecode more confusing to write, in a similar way to what has driven us to say that we will not breaksize == stride.Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, that is the point. If you need the guarantee, use a
#[repr(align)]wrapper type. References to#[align]things have the same type as any other reference, because they provide the same guarantees as any other reference.