Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

reference type safety invariant docs: clarification #125043

Merged
merged 1 commit into from
May 22, 2024

Conversation

RalfJung
Copy link
Member

@RalfJung RalfJung commented May 12, 2024

The old text could have been read as saying that you can call a function if these requirements are upheld, which is definitely not true as they are an underapproximation of the actual safety invariant.

I removed the part about functions relaxing the requirements via their documentation... this seems incoherent with saying that it may actually be unsound to ever temporarily violate the requirement. Furthermore, a function cannot just relax this for its return value, that would in general be unsound. And the part about "unsafe code in a safe function may assume these invariants are ensured of arguments passed by the caller" also interacts with relaxing things: clearly, if the invariant has been relaxed, unsafe code cannot rely on it any more. There may be a place to give general guidance on what kinds of function contracts can exist, but the reference type is definitely not the right place to write that down.

I also took a clarification from #121965 that is orthogonal to the rest of that PR.

Cc @joshlf @scottmcm

@rustbot
Copy link
Collaborator

rustbot commented May 12, 2024

r? @cuviper

rustbot has assigned @cuviper.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels May 12, 2024
@scottmcm
Copy link
Member

Thanks, Ralf! I agree this is a better phrasing of the current state of the world.

@bors r+ rollup

@bors
Copy link
Contributor

bors commented May 22, 2024

📌 Commit 7c76eec has been approved by scottmcm

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels May 22, 2024
@scottmcm scottmcm assigned scottmcm and unassigned cuviper May 22, 2024
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request May 22, 2024
…, r=scottmcm

reference type safety invariant docs: clarification

The old text could have been read as saying that you can call a function if these requirements are upheld, which is definitely not true as they are an underapproximation of the actual safety invariant.

I removed the part about functions relaxing the requirements via their documentation... this seems incoherent with saying that it may actually be unsound to ever temporarily violate the requirement. Furthermore, a function *cannot* just relax this for its return value, that would in general be unsound. And the part about "unsafe code in a safe function may assume these invariants are ensured of arguments passed by the caller" also interacts with relaxing things: clearly, if the invariant has been relaxed, unsafe code cannot rely on it any more. There may be a place to give general guidance on what kinds of function contracts can exist, but the reference type is definitely not the right place to write that down.

I also took a clarification from rust-lang#121965 that is orthogonal to the rest of that PR.

Cc `@joshlf` `@scottmcm`
bors added a commit to rust-lang-ci/rust that referenced this pull request May 22, 2024
…iaskrgr

Rollup of 7 pull requests

Successful merges:

 - rust-lang#124227 (Make sure that the method resolution matches in `note_source_of_type_mismatch_constraint`)
 - rust-lang#124896 (miri: rename intrinsic_fallback_checks_ub to intrinsic_fallback_is_spec)
 - rust-lang#125015 (Pattern types: Prohibit generic args on const params)
 - rust-lang#125043 (reference type safety invariant docs: clarification)
 - rust-lang#125259 (An async closure may implement `FnMut`/`Fn` if it has no self-borrows)
 - rust-lang#125306 (Force the inner coroutine of an async closure to `move` if the outer closure is `move` and `FnOnce`)
 - rust-lang#125378 (remove tracing tree indent lines)

r? `@ghost`
`@rustbot` modify labels: rollup
fmease added a commit to fmease/rust that referenced this pull request May 22, 2024
…, r=scottmcm

reference type safety invariant docs: clarification

The old text could have been read as saying that you can call a function if these requirements are upheld, which is definitely not true as they are an underapproximation of the actual safety invariant.

I removed the part about functions relaxing the requirements via their documentation... this seems incoherent with saying that it may actually be unsound to ever temporarily violate the requirement. Furthermore, a function *cannot* just relax this for its return value, that would in general be unsound. And the part about "unsafe code in a safe function may assume these invariants are ensured of arguments passed by the caller" also interacts with relaxing things: clearly, if the invariant has been relaxed, unsafe code cannot rely on it any more. There may be a place to give general guidance on what kinds of function contracts can exist, but the reference type is definitely not the right place to write that down.

I also took a clarification from rust-lang#121965 that is orthogonal to the rest of that PR.

Cc ``@joshlf`` ``@scottmcm``
bors added a commit to rust-lang-ci/rust that referenced this pull request May 22, 2024
Rollup of 7 pull requests

Successful merges:

 - rust-lang#125043 (reference type safety invariant docs: clarification)
 - rust-lang#125306 (Force the inner coroutine of an async closure to `move` if the outer closure is `move` and `FnOnce`)
 - rust-lang#125355 (Use Backtrace::force_capture instead of Backtrace::capture in rustc_log)
 - rust-lang#125378 (remove tracing tree indent lines)
 - rust-lang#125391 (Minor serialize/span tweaks)
 - rust-lang#125395 (Remove unnecessary `.md` from the documentation sidebar)
 - rust-lang#125399 (Stop using `to_hir_binop` in codegen)

r? `@ghost`
`@rustbot` modify labels: rollup
bors added a commit to rust-lang-ci/rust that referenced this pull request May 22, 2024
Rollup of 7 pull requests

Successful merges:

 - rust-lang#125043 (reference type safety invariant docs: clarification)
 - rust-lang#125306 (Force the inner coroutine of an async closure to `move` if the outer closure is `move` and `FnOnce`)
 - rust-lang#125355 (Use Backtrace::force_capture instead of Backtrace::capture in rustc_log)
 - rust-lang#125382 (rustdoc: rename `issue-\d+.rs` tests to have meaningful names (part 7))
 - rust-lang#125391 (Minor serialize/span tweaks)
 - rust-lang#125395 (Remove unnecessary `.md` from the documentation sidebar)
 - rust-lang#125399 (Stop using `to_hir_binop` in codegen)

r? `@ghost`
`@rustbot` modify labels: rollup
bors added a commit to rust-lang-ci/rust that referenced this pull request May 22, 2024
Rollup of 7 pull requests

Successful merges:

 - rust-lang#125043 (reference type safety invariant docs: clarification)
 - rust-lang#125306 (Force the inner coroutine of an async closure to `move` if the outer closure is `move` and `FnOnce`)
 - rust-lang#125355 (Use Backtrace::force_capture instead of Backtrace::capture in rustc_log)
 - rust-lang#125382 (rustdoc: rename `issue-\d+.rs` tests to have meaningful names (part 7))
 - rust-lang#125391 (Minor serialize/span tweaks)
 - rust-lang#125395 (Remove unnecessary `.md` from the documentation sidebar)
 - rust-lang#125399 (Stop using `to_hir_binop` in codegen)

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit ab9e0a7 into rust-lang:master May 22, 2024
6 checks passed
@rustbot rustbot added this to the 1.80.0 milestone May 22, 2024
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request May 22, 2024
Rollup merge of rust-lang#125043 - RalfJung:ref-type-safety-invariant, r=scottmcm

reference type safety invariant docs: clarification

The old text could have been read as saying that you can call a function if these requirements are upheld, which is definitely not true as they are an underapproximation of the actual safety invariant.

I removed the part about functions relaxing the requirements via their documentation... this seems incoherent with saying that it may actually be unsound to ever temporarily violate the requirement. Furthermore, a function *cannot* just relax this for its return value, that would in general be unsound. And the part about "unsafe code in a safe function may assume these invariants are ensured of arguments passed by the caller" also interacts with relaxing things: clearly, if the invariant has been relaxed, unsafe code cannot rely on it any more. There may be a place to give general guidance on what kinds of function contracts can exist, but the reference type is definitely not the right place to write that down.

I also took a clarification from rust-lang#121965 that is orthogonal to the rest of that PR.

Cc ```@joshlf``` ```@scottmcm```
@RalfJung RalfJung deleted the ref-type-safety-invariant branch May 23, 2024 06:16
@joshlf joshlf mentioned this pull request May 25, 2024
87 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-libs Relevant to the library team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants