Remove term "indirection" and its derivatives - #715
Conversation
76e05c8 to
d8a34a8
Compare
This PR removes the term "indirection" and its derivatives from the FLS as the Rust Project does not use this term. The preferred alternative is "pointer", "pointer type", etc. Closes: #710
d8a34a8 to
5f464ca
Compare
There was a problem hiding this comment.
Thanks @kirtchev-adacore, for taking the time to adopt the Rust Project terminology.
I found a couple of places where we seem to be a bit at odds with what's written up in the Reference. Could you take a look?
|
|
||
| :dp:`fls_3qI8FXMsyk0f` | ||
| A :t:`pointer type` is either a :t:`raw pointer type` or a :t:`reference type`. | ||
| A :t:`pointer type` is a :t:`type` whose :t:`[value]s` refer to memory locations. |
There was a problem hiding this comment.
I took a look at the Rust 1.96 Reference classification. It classifies function pointers as pointer types, but I don't think this PR propagates that broader meaning to existing FLS rules that use pointer type in the narrower, data-pointer sense.
In particular, the existing FLS dereference rule seems to now apply to function pointers and says that *fp denotes a pointed-to memory location, while its type rule falls back to Deref::Target.
On the other hand, the Reference's dereference-operator rule uses built-in dereference for data pointers/Box and otherwise requires Deref, while the documented function-pointer trait implementations do not include Deref.
Maybe we can define this category extensionally as function pointer, raw pointer, or reference types, then audit and narrow the existing data-pointer rules to raw pointers/references?
It seems to me that the memory-location predicate also might not characterize function pointers, which the Reference defines as referring to functions, and does not clearly account for valid null raw-pointer values such as core::ptr::null().
| A :t:`pointer` is a :t:`value` of a :t:`pointer type`. | ||
|
|
||
| :dp:`fls_8RBNIR0E6pnI` | ||
| A :t:`pointer` is :t:`dangling` if it is either :c:`null` or not all of the bytes at the referred memory location are part of the same allocation. |
There was a problem hiding this comment.
Over in the Reference it derives a pointer's pointed-to bytes from its value and pointee size, then defines dangling pointers by whether all those bytes belong to one live allocation.
It explicitly says a zero-sized pointee is never dangling even when the pointer is null, so core::ptr::null::<()>() is a counterexample to this definition. Omitting "live" also leaves a pointer to deallocated storage not clearly covered.
Might be better here if we follow the Reference wording and limit this data-pointer rule to raw pointers/references, since pointer now also includes function pointers. What do you think?
2 participants
This PR removes the term "indirection" and its derivatives from the FLS as the Rust Project does not use this term. The preferred alternative is "pointer", "pointer type", etc.
Closes: #710