[1.95.0] Document provenance and its use in const eval

[kirtchev-adacore]

The information has been taken from

• core::ptr Provenance
• reference#2091
• reference#2139

[PLeVasseur]

Hey @kirtchev-adacore, thanks for taking the time to write this up.

I spotted some things we could tune up here and there for precision and to match current understandings for provenance that seem to exist in the Project.

I know the release is tomorrow and we meet Friday, but hopefully this is not too much 😅

View changes since this review

[PLeVasseur]

Thanks for incorporating the ideas.
Really just a couple of small nits left.

Perhaps we punt on one of the items I raised? I can open an issue.

View changes since this review

[tshepang]

• I understand "access" as ability to read from the memory locations, such that a read is implied (unless you find the suggestion too vague)
• "write to memory" does not indicate which memory

Suggested change

	:dt:`Provenance` is an optional property of :t:`[pointer]s` that restricts the memory locations the :t:`pointer` may access, the timespan during which the accesses may occur, and whether the accesses may read from or write to memory.
	:dt:`Provenance` is an optional property of :t:`[pointer]s` that restricts the memory locations the :t:`pointer` may access, the timespan during which the accesses may occur, and whether the :t:`pointer` can write to such memory locations.

View changes since the review

[kirtchev-adacore]

Note that you left out reads! This is important, as provenance dictates read and write permissions.

[tshepang]

access sounds like it implies reads, at least in the context of a programming language

[kirtchev-adacore]

I do not agree. "Memory access" has always meant reads and writes. You have RAM (Random Access Memory), which is both read and written, as opposed to ROM (Read-only Memory).

Also, from core::ptr:

Whether a pointer is valid depends on the operation it is used for (read or write), and the extent of the memory that is accessed (i.e., how many bytes are read/written)

If you do not like the verb "to access", then you will have to suggest a better alternative.

[tshepang]

If access means read and/or write, then we are here saying: "restricts the memory locations the pointer may read-write, when those reads-writes can happen, and whether those are reads and/or writes".

That is, "access" implies reads, but only includes writes optionally (hence my suggestion).

An alternative, in case that still doesn't work (to avoid "access'):

Provenance is an optional property of pointers that restricts the memory locations the pointer may read, the timespan during which the read may occur, and whether the pointer can also write to such memory locations.

It's a little vague, so maybe:

Provenance is an optional property of pointers that restricts the memory locations the pointer may read, the timespan during which the read may occur, and whether those reads can also include writes.

Not sure. What do you think.

[kirtchev-adacore]

More like "and whether the reads and/or writes are allowed in the first place".

I do not think your suggestion is correct, as once again you are leaving out writes from several of the provenance properties. I am not sure why you are trying to "save on text", and cause the rule to imply additional semantics. One of the goals of the FLS is to spell out rules clearly, even if there is repetition, so that there is no doubt, implication, or ambiguity.

Basically "provenance" says

• You are allowed to access memory locations from 0x000A to 0x001A.
• You are allowed to access those memory locations from this part of your program to this part of your program.
• You are allowed to read and/or write from/to those memory locations.

There is "write-only" memory from the point of view of your program! For example, GPU memory can behave this way. Your program simply dumps data onto the GPU buffers, and the GPU reads it. Your program does not read from the GPU.

[tshepang]

There is "write-only" memory from the point of view of your program! For example, GPU memory can behave this way.

good to know

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

delegated to me