Some more changes from @CAD97's review

text/0000-ptr-to-field.md

@@ -91,8 +91,6 @@ impl<T: ?Sized> *mut T {
 
 These will allowing projections through raw pointers without dereferencing the raw pointer. This is useful for building projections through other abstractions like smart pointers (`Rc<T>`, `Pin<&T>`)!
 
-This is the extent of the core api of this RFC.
-
 Using this we can do something like this
 ```rust
 struct Foo {
@@ -162,13 +160,13 @@ raw pointer projections need to be implemented as intrinsics because there is no
 
 We need both `project_unchecked` and `wrapping_project` because there are some important optimization available inside of LLVM related to aliasing and escape analysis. In particular the LLVM `inbounds` assertion tells LLVM that a pointer offset stays within the same allocation and if the pointer is invalid or the offset does not stay within the same allocation it is considered UB. This behaviour is exposed via `project_unchecked`. This can be used by implementations of the `Project` trait for smart pointers that are always valid, like `&T` to enable better codegen. `wrapping_project` on the other hand will not assert `inbounds`, and will just wrap around if the pointer offset is larger than `usize::max_value()`. This safe defined behaviour, even if it is almost always a bug, unlike `project_unchecked` which is UB on invalid pointers or offsets.
 
-This corresponds with `core::ptr::add` and `core::ptr::wrapping_add` in safety and behaviour.
+This corresponds with `<*const _>::add` and `<*const _>::wrapping_add` in safety and behaviour.
 
 `inverse_project_unchecked` and `inverse_wrapping_project` are have all of the same safety requirements as their counterparts, and some more.
 
 `inverse_project_unchecked` and `inverse_wrapping_project` produces a valid pointer without UB if and only if the initial pointer is both valid and points to a field in the parent type used to perform the inverse projection. `inverse_wrapping_project` will never cause UB, but may produce invalid pointers. `inverse_project_unchecked` will cause UB if the condition above is not met. This is different from `project_unchecked` and `wrapping_project` because they only need to validate the original pointer, not the resulting pointer.
 
-`inverse_project_unchecked` and `inverse_wrapping_project` correspond to `core::ptr::sub` and `core::ptr::wrapping_sub` in safety and behaviour.
+`inverse_project_unchecked` and `inverse_wrapping_project` correspond to `<*const _>::sub` and `<*const _>::wrapping_sub` in safety and behaviour.
 
 For example of where `project_unchecked` would be UB.