offset: allow zero-byte offset on arbitrary pointers
As per prior `@rust-lang/opsem` [discussion](https://github.com/rust-lang/opsem-team/issues/10) and [FCP](https://github.com/rust-lang/unsafe-code-guidelines/issues/472#issuecomment-1793409130):
- Zero-sized reads and writes are allowed on all sufficiently aligned pointers, including the null pointer
- Inbounds-offset-by-zero is allowed on all pointers, including the null pointer
- `offset_from` on two pointers derived from the same allocation is always allowed when they have the same address
This removes surprising UB (in particular, even C++ allows "nullptr + 0", which we currently disallow), and it brings us one step closer to an important theoretical property for our semantics ("provenance monotonicity": if operations are valid on bytes without provenance, then adding provenance can't make them invalid).
The minimum LLVM we require (v17) includes https://reviews.llvm.org/D154051, so we can finally implement this.
The `offset_from` change is needed to maintain the equivalence with `offset`: if `let ptr2 = ptr1.offset(N)` is well-defined, then `ptr2.offset_from(ptr1)` should be well-defined and return N. Now consider the case where N is 0 and `ptr1` dangles: we want to still allow offset_from here.
I think we should change offset_from further, but that's a separate discussion.
Fixes https://github.com/rust-lang/rust/issues/65108
[Tracking issue](https://github.com/rust-lang/rust/issues/117945) | [T-lang summary](https://github.com/rust-lang/rust/pull/117329#issuecomment-1951981106)
Cc `@nikic`
Make sure that the method resolution matches in `note_source_of_type_mismatch_constraint`
`note_source_of_type_mismatch_constraint` is a pile of hacks that I implemented to cover up another pile of hacks.
It does a bunch of re-confirming methods, but it wasn't previously checking that the methods it was looking (back) up were equal to the methods we previously had. This PR adds those checks.
Fixes#118185
Move `#[do_not_recommend]` to the `#[diagnostic]` namespace
This commit moves the `#[do_not_recommend]` attribute to the `#[diagnostic]` namespace. It still requires
`#![feature(do_not_recommend)]` to work.
r? `@compiler-errors`
Translation of the lint message happens when the actual diagnostic is
created, not when the lint is buffered. Generating the message from
BuiltinLintDiag ensures that all required data to construct the message
is preserved in the LintBuffer, eventually allowing the messages to be
moved to fluent.
Remove the `msg` field from BufferedEarlyLint, it is either generated
from the data in the BuiltinLintDiag or stored inside
BuiltinLintDiag::Normal.
Don't do cc detection for synthetic targets
Fixes https://github.com/rust-lang/rust/issues/125365
Synthetic targets only exist for mir-opt tests, and the mir-opt test suite is in general designed to avoid any use of a C compiler. We don't need to do CC detection. It's unclear to me how this code didn't cause issues before.
add pull request template asking for relevant tracking issues
As mentioned at RustNation, I would like to remind PR authors to link to relevant tracking issues when opening PRs as it is otherwise very easy to forget doing so.
There's a certain amount of conflict between making the template as small as possible while still being clear for new contributors. I am very much open to changes here but really want to try this out.
Also unsure how much formal buy-in we need here. Maybe merge this pinging t-compiler and t-libs, and then ask how people feel about this on zulip in a few weeks?
r? `@davidtwco`
Fix incorrect suggestion for undeclared hrtb lifetimes in where clauses.
For poly-trait-ref like `for<'a> Trait<T>` in `T: for<'a> Trait<T> + 'b { }`.
We should merge the hrtb lifetimes: existed `for<'a>` and suggestion `for<'b>` or will get err: [E0316] nested quantification of lifetimes
fixes#122714
