As currently written, when a logic error occurs in a collection's trait
parameters, this allows *completely arbitrary* misbehavior, so long as
it does not cause undefined behavior in std. However, because the extent
of misbehavior is not specified, it is allowed for *any* code in std to
start misbehaving in arbitrary ways which are not formally UB; consider
the theoretical example of a global which gets set on an observed logic
error. Because the misbehavior is only bound by not resulting in UB from
safe APIs and the crate-level encapsulation boundary of all of std, this
makes writing user unsafe code that utilizes std theoretically
impossible, as it now relies on undocumented QOI that unrelated parts of
std cannot be caused to misbehave by a misuse of std::collections APIs.

In practice, this is a nonconcern, because std has reasonable QOI and an
implementation that takes advantage of this freedom is essentially a
malicious implementation and only compliant by the most langauage-lawyer
reading of the documentation.

To close this hole, we just add a small clause to the existing logic
error paragraph that ensures that any misbehavior is limited to the
collection which observed the logic error, making it more plausible to
prove the soundness of user unsafe code.

This is not meant to be formal; a formal refinement would likely need to
mention that values derived from the collection can also misbehave after a
logic error is observed, as well as define what it means to "observe" a
logic error in the first place. This fix errs on the side of informality
in order to close the hole without complicating a normal reading which
can assume a reasonable nonmalicious QOI.

See also [discussion on IRLO][1].

[1]: https://internals.rust-lang.org/t/using-std-collections-and-unsafe-anything-can-happen/16640

A pointer to address cast are often special-cased.
Introduce a dedicated cast kind to make them easy distinguishable.

Co-authored-by: lcnr <[email protected]>

Linux's `checkpatch.pl` reports:

```txt
rust-lang#42544: FILE: rust/alloc/vec/mod.rs:2692:
WARNING: Possible repeated word: 'to'
+            // - Elements are :Copy so it's OK to to copy them, without doing
```

Signed-off-by: Miguel Ojeda <[email protected]>

Stabilize the `bundle` native library modifier

And remove the legacy `static-nobundle` linking kind.

Stabilization report - rust-lang#95818 (comment).

cc rust-lang#81490
Closes rust-lang#37403

Put a bound on collection misbehavior

As currently written, when a logic error occurs in a collection's trait parameters, this allows *completely arbitrary* misbehavior, so long as it does not cause undefined behavior in std. However, because the extent of misbehavior is not specified, it is allowed for *any* code in std to start misbehaving in arbitrary ways which are not formally UB; consider the theoretical example of a global which gets set on an observed logic error. Because the misbehavior is only bound by not resulting in UB from safe APIs and the crate-level encapsulation boundary of all of std, this makes writing user unsafe code that utilizes std theoretically impossible, as it now relies on undocumented QOI (quality of implementation) that unrelated parts of std cannot be caused to misbehave by a misuse of std::collections APIs.

In practice, this is a nonconcern, because std has reasonable QOI and an implementation that takes advantage of this freedom is essentially a malicious implementation and only compliant by the most langauage-lawyer reading of the documentation.

To close this hole, we just add a small clause to the existing logic error paragraph that ensures that any misbehavior is limited to the collection which observed the logic error, making it more plausible to prove the soundness of user unsafe code.

This is not meant to be formal; a formal refinement would likely need to mention that values derived from the collection can also misbehave after a logic error is observed, as well as define what it means to "observe" a logic error in the first place. This fix errs on the side of informality in order to close the hole without complicating a normal reading which can assume a reasonable nonmalicious QOI.

See also [discussion on IRLO][1].

[1]: https://internals.rust-lang.org/t/using-std-collections-and-unsafe-anything-can-happen/16640

r? rust-lang/libs-api `@rustbot` label +T-libs-api -T-libs

This technically adds a new guarantee to the documentation, though I argue as written it's one already implicitly provided.

Fix TLS access mir opt test and remove stale files

Thanks `@pietroalbini` for noticing that the TLS test was not doing what it was supposed to. Switched to `PreCodegen` because `SimplifyCfg` does not run on opt level 0.

Also addresses the easy part of rust-lang#97564 .

r? rust-lang/mir-opt

alloc: remove repeated word in comment

Linux's `checkpatch.pl` reports:

```txt
rust-lang#42544: FILE: rust/alloc/vec/mod.rs:2692:
WARNING: Possible repeated word: 'to'
+            // - Elements are :Copy so it's OK to to copy them, without doing
```

Signed-off-by: Miguel Ojeda <[email protected]>

…-obk

Add a pointer to address cast kind

A pointer to address cast are often special-cased. Introduce a dedicated cast kind to make them easy distinguishable.