Skip to content

Conversation

flip1995
Copy link
Member

@flip1995 flip1995 commented Feb 6, 2025

r? @ghost

changelog: none

flip1995 and others added 24 commits January 28, 2025 19:33
…solver, r=lcnr

Do not consider child bound assumptions for rigid alias

r? lcnr

See first commit for the important details. For second commit, I also stacked a somewhat opinionated name change, though I can separate that if needed.

Fixes rust-lang/trait-system-refactor-initiative#149
Refactor FnKind variant to hold &Fn

Pulling the change suggested in #128045 to reduce the impact of changing `Fn` item.

r? `@oli-obk`
Co-authored-by: FedericoBruzzone <[email protected]>
… enabled

Similar to how the alignment is already checked, this adds a check
for null pointer dereferences in debug mode. It is implemented similarly
to the alignment check as a MirPass.

This is related to a 2025H1 project goal for better UB checks in debug
mode: rust-lang/rust-project-goals#177.
Insert null checks for pointer dereferences when debug assertions are enabled

Similar to how the alignment is already checked, this adds a check
for null pointer dereferences in debug mode. It is implemented similarly
to the alignment check as a `MirPass`.

This inserts checks in the same places as the `CheckAlignment` pass and additionally
also inserts checks for `Borrows`, so code like
```rust
let ptr: *const u32 = std::ptr::null();
let val: &u32 = unsafe { &*ptr };
```
will have a check inserted on dereference. This is done because null references
are UB. The alignment check doesn't cover these places, because in `&(*ptr).field`,
the exact requirement is that the final reference must be aligned. This is something to
consider further enhancements of the alignment check.

For now this is implemented as a separate `MirPass`, to make it easy to disable
this check if necessary.

This is related to a 2025H1 project goal for better UB checks in debug
mode: rust-lang/rust-project-goals#177.

r? `@saethlin`
Implement MIR lowering for unsafe binders

This is the final bit of the unsafe binders puzzle. It implements MIR, CTFE, and codegen for unsafe binders, and enforces that (for now) they are `Copy`. Later on, I'll introduce a new trait that relaxes this requirement to being "is `Copy` or `ManuallyDrop<T>`" which more closely models how we treat union fields.

Namely, wrapping unsafe binders is now `Rvalue::WrapUnsafeBinder`, which acts much like an `Rvalue::Aggregate`. Unwrapping unsafe binders are implemented as a MIR projection `ProjectionElem::UnwrapUnsafeBinder`, which acts much like `ProjectionElem::Field`.

Tracking:
- rust-lang/rust#130516
`rustc_middle` is a huge crate and it's always good to move stuff out of
it. There are lots of similar methods already on `Span`, so these two
functions, `in_external_macro` and `is_from_async_await`, fit right in.
The diff is big because `in_external_macro` is used a lot by clippy
lints.
Rename `tcx.ensure()` to `tcx.ensure_ok()`, and improve the associated docs

This is all based on my archaeology for https://rust-lang.zulipchat.com/#narrow/channel/182449-t-compiler.2Fhelp/topic/.60TyCtxtEnsure.60.

The main renamings are:
- `tcx.ensure()` → `tcx.ensure_ok()`
- `tcx.ensure_with_value()` → `tcx.ensure_done()`
- Query modifier `ensure_forwards_result_if_red` → `return_result_from_ensure_ok`

Hopefully these new names are a better fit for the *actual* function and purpose of these query call modes.
All callers of EarlyDiagCtxt::early_error now emit a fatal error.
…rieb

Convert two `rustc_middle::lint` functions to `Span` methods.

`rustc_middle` is a huge crate and it's always good to move stuff out of it. There are lots of similar methods already on `Span`, so these two functions, `in_external_macro` and `is_from_async_await`, fit right in. The diff is big because `in_external_macro` is used a lot by clippy lints.

r? ``@Noratrieb``
Couple of cleanups to DiagCtxt and EarlyDiagCtxt
These are hooks to:

  1. control whether contract checks are run
  2. allow 3rd party tools to intercept and reintepret the results of running contracts.
…ract lang items

includes post-developed commit: do not suggest internal-only keywords as corrections to parse failures.

includes post-developed commit: removed tabs that creeped in into rustfmt tool source code.

includes post-developed commit, placating rustfmt self dogfooding.

includes post-developed commit: add backquotes to prevent markdown checking from trying to treat an attr as a markdown hyperlink/

includes post-developed commit: fix lowering to keep contracts from being erroneously inherited by nested bodies (like closures).

Rebase Conflicts:
 - compiler/rustc_parse/src/parser/diagnostics.rs
 - compiler/rustc_parse/src/parser/item.rs
 - compiler/rustc_span/src/hygiene.rs

Remove contracts keywords from diagnostic messages
#[contracts::requires(...)]  + #[contracts::ensures(...)]

cc rust-lang/rust#128044

Updated contract support: attribute syntax for preconditions and postconditions, implemented via a series of desugarings  that culminates in:
1. a compile-time flag (`-Z contract-checks`) that, similar to `-Z ub-checks`, attempts to ensure that the decision of enabling/disabling contract checks is delayed until the end user program is compiled,
2. invocations of lang-items that handle invoking the precondition,  building a checker for the post-condition, and invoking that post-condition checker at the return sites for the function, and
3. intrinsics for the actual evaluation of pre- and post-condition predicates that third-party verification tools can intercept and reinterpret for their own purposes (e.g. creating shims of behavior that abstract away the function body and replace it solely with the pre- and post-conditions).

Known issues:

 * My original intent, as described in the MCP (rust-lang/compiler-team#759) was   to have a rustc-prefixed attribute namespace (like   rustc_contracts::requires). But I could not get things working when I tried   to do rewriting via a rustc-prefixed builtin attribute-macro. So for now it  is called `contracts::requires`.

 * Our attribute macro machinery does not provide direct support for attribute arguments that are parsed like rust expressions. I spent some time trying to add that (e.g. something that would parse the attribute arguments as an AST while treating the remainder of the items as a token-tree), but its too big a lift for me to undertake. So instead I hacked in something approximating that goal, by semi-trivially desugaring the token-tree attribute contents into internal AST constucts. This may be too fragile for the long-term.
   * (In particular, it *definitely* breaks when you try to add a contract to a function like this: `fn foo1(x: i32) -> S<{ 23 }> { ... }`, because its token-tree based search for where to inject the internal AST constructs cannot immediately see that the `{ 23 }` is within a generics list. I think we can live for this for the short-term, i.e. land the work, and continue working on it while in parallel adding a new attribute variant that takes a token-tree attribute alongside an AST annotation, which would completely resolve the issue here.)

* the *intent* of `-Z contract-checks` is that it behaves like `-Z ub-checks`, in that we do not prematurely commit to including or excluding the contract evaluation in upstream crates (most notably, `core` and `std`). But the current test suite does not actually *check* that this is the case. Ideally the test suite would be extended with a multi-crate test that explores the matrix of enabling/disabling contracts on both the upstream lib and final ("leaf") bin crates.
@rustbot rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties label Feb 6, 2025
@flip1995 flip1995 added this pull request to the merge queue Feb 6, 2025
Merged via the queue into rust-lang:master with commit 3e3715c Feb 6, 2025
11 checks passed
@flip1995 flip1995 deleted the rustup branch February 6, 2025 14:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-review Status: Awaiting review from the assignee but also interested parties
Projects
None yet
Development

Successfully merging this pull request may close these issues.