The previous definition used the phrase "representation", which is ambiguous given the current state of memory model nomenclature in Rust. The new wording clarifies that size and bit validity are guaranteed to match the corresponding native integer type.

Co-authored-by: Taiki Endo <te316e89@gmail.com>

Co-authored-by: Taiki Endo <te316e89@gmail.com>

…he body id

Signed-off-by: xiaoxiangxianzi <zhaoyizheng@outlook.com>

Fix drop and drop_in_place by transforming self of drop and
drop_in_place methods into Drop trait objects.

Clarify atomic bit validity

The previous definition used the phrase "representation", which is ambiguous given the current state of memory model nomenclature in Rust. For integer types and for `AtomicPtr<T>`, the new wording clarifies that size and bit validity are guaranteed to match the corresponding native integer type/`*mut T`. For `AtomicBool`, the new wording clarifies that size, alignment, and bit validity are guaranteed to match `bool`.

Note that we use the phrase "size and alignment" rather than "layout" since the latter term also implies that the field types are the same. This isn't true - `AtomicXxx` doesn't store an `xxx`, but rather an `UnsafeCell<xxx>`. This distinction is important for some `unsafe` code, which needs to reason about the presence or absence of interior mutability in order to ensure that their code is sound (see e.g. google/zerocopy#251).

…place, r=compiler-errors

CFI: Fix drop and drop_in_place

Fix drop and drop_in_place by transforming self of drop and drop_in_place methods into a Drop trait objects.

This was split off from rust-lang#116404.

cc `@compiler-errors` `@workingjubilee`

…trochenkov

Delegation: fix ICE on wrong `Self` instantiation

fixes rust-lang#119921
fixes rust-lang#119919

There is no way to instantiate `Self` param for caller in delegation item if

1. callee is a trait method && callee contains `Self` param
2. delegation item isn't an associative item

In general, we can consider `Self` param as independent type param in these cases:

```rust

trait Trait {
    fn foo(_: Option<&Self>) {...}
}

reuse Trait::foo;
// will be desugared to:
fn foo<T: Trait>(x: Option<&T>) { Trait::foo(x) }
```

But this requires early bound parameters support. For now, I suggest banning such cases to avoid ICE's.

r? ``@petrochenkov``

…iler-errors

Load missing type of impl associated constant from trait definition

fixes rust-lang#123092

Also does some cleanups I discovered while analyzing this issue

chore: fix some comments

…sDenton

Some wording improvement

"Data" is usually considered as plural uncountable, therefore "some" seems to make more sense imo.

…pratt

`num::NonZero::get` can be 1 transmute instead of 2

Just something I noticed in passing.  No need for a `match` in here to call `unreachable_unchecked`, as `transmute_unchecked` will add the appropriate `llvm.assume` <https://rust.godbolt.org/z/W5hjeETnc>.

…ng, r=compiler-errors

Let nils know about changes to target docs

i'll probably expand the paths and add a message after rust-lang#121051 but i honestly don't expect that to land very soon lol, so it would be nice to get notified about changes already and watch what's happening there

approve this pr if you're cool