Skip to content

Rollup of 4 pull requests #119707

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

Closed
wants to merge 62 commits into from
Closed
Changes from 1 commit
Commits
Show all changes
62 commits
Select commit Hold shift + click to select a range
4c4c6a6
Preparing for merge from rustc
Jan 5, 2024
d11a2bd
Merge from rustc
Jan 5, 2024
39c714b
Auto merge of #3252 - rust-lang:rustup-2024-01-05, r=RalfJung
bors Jan 5, 2024
80ee0c0
remove redundant clone
matthiaskrgr Jan 5, 2024
d334a4b
Auto merge of #3253 - matthiaskrgr:noclone, r=RalfJung
bors Jan 5, 2024
7e4e9ad
Preparing for merge from rustc
Jan 6, 2024
078f228
Merge from rustc
Jan 6, 2024
46f53c8
fmt
Jan 6, 2024
1c98b78
implement the rounding intrinsics using apfloat rounding
RalfJung Jan 6, 2024
58c80a0
merge intrinsics-math into float tests
RalfJung Jan 6, 2024
ac4526d
these should be exact
RalfJung Jan 6, 2024
0814a56
Auto merge of #3254 - rust-lang:rustup-2024-01-06, r=saethlin
bors Jan 6, 2024
643e7f0
./miri build: also build tests, to avoid rebuilds later
RalfJung Jan 6, 2024
66b15ae
cargo update
RalfJung Jan 6, 2024
b8209e2
use jemalloc as global allocator
RalfJung Jan 7, 2024
c4a11ea
only use jemalloc on Unix
RalfJung Jan 7, 2024
d93ca6e
Auto merge of #3259 - RalfJung:jemalloc, r=RalfJung
bors Jan 7, 2024
8675aa1
Auto merge of #3256 - RalfJung:rounding, r=RalfJung
bors Jan 7, 2024
6f017d2
Auto merge of #3257 - RalfJung:build-tests, r=RalfJung
bors Jan 7, 2024
a543448
update lockfile
RalfJung Jan 7, 2024
8af1a6a
Make ImplTraitPosition display more descriptive
compiler-errors Jan 7, 2024
0f39574
Inline some helpers no longer needed due to RPITIT being stable
compiler-errors Jan 7, 2024
bfd63b2
Rewrite `Pin<P>` docs to clarify guarantees and uses
mcy Aug 30, 2021
8241ca6
mostly done
fu5ha Sep 25, 2023
ba3b934
Fix examples, finish polishing
fu5ha Sep 25, 2023
584f098
fix broken links
fu5ha Sep 25, 2023
ec8a01a
fix one more broken link
fu5ha Sep 25, 2023
46f9d77
update doubly linked list commentary and fix links
fu5ha Sep 25, 2023
db5b19e
improve intro and `Unpin`-related discussion
fu5ha Sep 26, 2023
6818d92
improve intro and discussion of pinning as library contract
fu5ha Sep 26, 2023
bebbe24
improve `Pin` struct docs and add examples
fu5ha Sep 26, 2023
82a6817
fix link in footnote
fu5ha Sep 27, 2023
e2e8746
reword unpin auto impl section
fu5ha Sep 27, 2023
7c9c712
improve structural Unpin + formatting
fu5ha Sep 27, 2023
252a83b
add section on manual owning ptr managed solution via @kpreid
fu5ha Sep 28, 2023
f2447a6
fix typos
fu5ha Sep 28, 2023
921d37d
fix imports
fu5ha Sep 28, 2023
6d5f43d
edit new section for typos and better wording
fu5ha Sep 28, 2023
de2e748
fix typos and edit prose
fu5ha Sep 28, 2023
6e88279
`Pin<P>` -> `Pin<Ptr>`
fu5ha Oct 3, 2023
469c78b
improve `Pin` and `Pin::new` docs
fu5ha Oct 3, 2023
e0210e6
justify motivation of `Unpin` better
fu5ha Oct 3, 2023
f0827b3
fix broken link
fu5ha Oct 3, 2023
d7a886a
update ui tests
fu5ha Oct 3, 2023
9997114
improve `Pin::new_unchecked` docs
fu5ha Oct 3, 2023
058fb50
trim section on managed-box model
fu5ha Oct 3, 2023
0050676
Rephrase unpin docs in terms of pinning-agnosticness
Manishearth Jan 7, 2024
936ceb2
lifetime -> lifespan where relevant. improve docs on as_ref()
Manishearth Jan 7, 2024
4c25246
Clean up guarantees wording
Manishearth Jan 7, 2024
68bdedd
Apply suggestions from code review
Manishearth Jan 7, 2024
6553d0d
punctuation in parens
Manishearth Jan 7, 2024
6a54ed7
valid
Manishearth Jan 7, 2024
a573c7c
footnote on dropping futures
Manishearth Jan 7, 2024
b1830f1
clean up structural pinning
Manishearth Jan 7, 2024
df6d449
Update library/core/src/pin.rs
Manishearth Jan 7, 2024
7fd841c
link
Manishearth Jan 7, 2024
3acc5a0
effects: support ~const in assoc fns in trait impls
fmease Jan 7, 2024
7e38b70
Split note, fix const/static impl trait error
compiler-errors Jan 7, 2024
f863229
Rollup merge of #116129 - fu5ha:better-pin-docs-2, r=Amanieu
matthiaskrgr Jan 7, 2024
bfb63bc
Rollup merge of #119702 - RalfJung:miri, r=RalfJung
matthiaskrgr Jan 7, 2024
253efc9
Rollup merge of #119703 - compiler-errors:impl-trait-tweaks, r=fmease
matthiaskrgr Jan 7, 2024
e7abeb0
Rollup merge of #119705 - fmease:tilde-const-assoc-fns-trait-impls, r…
matthiaskrgr Jan 7, 2024
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
trim section on managed-box model
  • Loading branch information
fu5ha authored and Manishearth committed Jan 7, 2024

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
commit 058fb50ecdb19cb36b009285e811b87fd7fe254d
13 changes: 4 additions & 9 deletions library/core/src/pin.rs
Original file line number Diff line number Diff line change
@@ -183,22 +183,17 @@
//! access to that data to ensure no *moves* or other invalidation occurs, and finally
//! provide a safe interface on top.
//!
//! There are a couple of linked disadvantages to using this model. The core issue is a lack
//! of generality. This is an issue because it means that each individual type that implements
//! such an interface does so on its own. Each developer implementing such a type must themselves
//! think through all the guarantees needed to ensure the API they present is sound. We would
//! rather build a shared understanding of the problem space and encode that understanding into a
//! shared interface to solve it which everyone helps validate.
//!
//! In addition, in this model, each individual object must assume it is *on its own* to ensure
//! There are a couple of linked disadvantages to using this model. The most significant is that
//! each individual object must assume it is *on its own* to ensure
//! that its data does not become *moved* or otherwise invalidated. Since there is no shared
//! contract between values of different types, an object cannot assume that others interacting
//! with it will properly respect the invariants around interacting with its data and must
//! therefore protect it from everyone. Because of this, *composition* of address-sensitive types
//! requires at least a level of pointer indirection each time a new object is added to the mix
//! (and, practically, a heap allocation).
//!
//! This is the key thing that drove Rust towards a different model. It is particularly a problem
//! Although there were other reason as well, this issue of expensive composition is the key thing
//! that drove Rust towards adopting a different model. It is particularly a problem
//! when one considers, for exapmle, the implications of composing together the [`Future`]s which
//! will eventaully make up an asynchronous task (including address-sensitive `async fn` state
//! machines). It is plausible that there could be many layers of [`Future`]s composed together,