Specify bit validity and padding of some types #1
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Update subtyping.md
This reverts commit b83d8e6.
This reverts commit 4662059.
Revert let chains reference docs
…e-cast-documentation #[non_exhaustive] on variant blocks cross-crate as casts
allow to quickly edit a page directly on github
Update examples of what implements `Termination`
The reference currently states that "[t]he size of a value is always a multiple of its alignment." This might be taken to imply that a type's size is greater than or equal to its alignment. This commit clarifies that 0 is a valid multiple; zero-sized types have 0 size and nonzero alignment.
* fix "typo" when declaring semantics of `return` from within async block * remove confusing false comment from the example
Clarify reference on async blocks
This was mostly mechanical. There are only two things of note: 1. A couple sentences ended with commas instead of periods. I changed them to periods. They were both in the Binding Modes section, so I assume they were added together. 2. In the static/dynamic behavior for or patterns, for two sections, I separated lines based on commas instead of the one really large sentence they are.
Remove `ne` from derive example
…ever Remove doc of unstable feature of never type
Co-authored-by: Ralf Jung <[email protected]>
Add CI trigger for merge queues.
Say that division by zero for primitive types panics
Co-authored-by: Ralf Jung <[email protected]>
…r-change Make unsafe keyword docs less confusing
Operator expressions: make the note about division by zero clearer.
mention the extra const UB
I personally found this description of UB confusing, since the use of "reached" suggests that UB only happens for read bytes, and the definition of immutability is not given, allowing for multiple interpretations: does the "data" have to be immutable from the first read? From the creation of the reference? Between reads from the immutable accessor, but not otherwise? etc. This clarifies the actual UB conditions, based on this Zulip interaction: https://rust-lang.zulipchat.com/#narrow/stream/136281-t-opsem/topic/What.20exactly.20are.20.22immutable.22.20and.20.22reached.22.20in.20shared.20ref.20UB.3F and this reference discussion: rust-lang#1227 in two ways: * The definition of "data" is clarified to be stated in terms of bytes, in a way that should avoid ambiguity about which bytes are considered. Based on the GH issue, this clarification should also allow for use of a `*mut` pointer through a shared reference, which is not in itself UB. Based on the Zulip issue, the definition includes padding bytes, which may be surprising. * The definition of immutability & mutation for a set of bytes is clarified to mean forbidding *all* non-0-byte writes.
This is part of the feedback on rust-lang#1385. Ralf made the point that the immutability definition could be restated solely in terms of bytes, which has the added benefit of no longer requiring the note on padding (since it's a natural consequence of the byte version.) The new wording for shared references also clarifies the case of mutable references behind shared ones, and reintroduces some of the transitivity property that I removed in my previous commit. The wording is separate from that for immutable bindings, since those don't have transitive immutability. This also bumps the definition of bytes pointed to by references and pointers into its own subsection, so that it can be linked to by the UB definition, to avoid duplication. Co-authored-by: Ralf Jung <[email protected]>
These changes should preserve the meaning of the contents. Co-authored-by: Ralf Jung <[email protected]>
…arification Clarify UB around immutability & mutation
Fix merge queue building twice.
Clearly specify the `instruction_set` effects
Co-authored-by: Ryan Scheel <[email protected]>
compile_fail is a dangerous thing to use since it doesn't validate which error is generated (it could be something like a typo).
add section about implied bounds
Specify the bit validity and padding of the primitive numeric types, bool, char, and pointer and reference types. Closes rust-lang#1291
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Specify the bit validity and padding of the primitive numeric types, bool, char, and pointer and reference types.
Closes rust-lang#1291