Automatic Rustup #3624
Merged
Automatic Rustup #3624
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
Uplift `Binder`, `OutlivesPredicate` into `rustc_type_ir` Almost done with all the types 🙏 r? lcnr
…bank 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
offset: allow zero-byte offset on arbitrary pointers As per prior `@rust-lang/opsem` [discussion](rust-lang/opsem-team#10) and [FCP](rust-lang/unsafe-code-guidelines#472 (comment)): - 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 rust-lang/rust#65108 [Tracking issue](rust-lang/rust#117945) | [T-lang summary](rust-lang/rust#117329 (comment)) Cc `@nikic`
Add a footer in FileEncoder and check for it in MemDecoder We have a few reports of ICEs due to decoding failures, where the fault does not lie with the compiler. The goal of this PR is to add some very lightweight and on-by-default validation to the compiler's outputs. If validation fails, we emit a fatal error for rmeta files in general that mentions the path that didn't load, and for incremental compilation artifacts we emit a verbose warning that tries to explain the situation and treat the artifacts as outdated. The validation currently implemented here is very crude, and yet I think we have 11 ICE reports currently open (you can find them by searching issues for `1002111927320821928687967599834759150`) which this simple validation would have detected. The structure of the code changes here should permit the addition of further validation code, such as a checksum, if it is merited. I would like to have code to detect corruption such as reported in rust-lang/rust#124719, but I'm not yet sure how to do that efficiently, and this PR is already a good size. The ICE reports I have in mind that this PR would have smoothed over are: rust-lang/rust#124469 rust-lang/rust#123352 rust-lang/rust#123376 [^1] rust-lang/rust#99763 rust-lang/rust#93900. --- [^1]: This one might be a compiler bug, but even if it is I think the workflow described is pushing the envelope of what we can support. This issue is one of the reasons this warning still asks people to file an issue.
miri: rename intrinsic_fallback_checks_ub to intrinsic_fallback_is_spec Checking UB is not the only concern, we also have to make sure we are not losing out on non-determinism. r? ``@oli-obk`` (not urgent, take your time)
…r=spastorino Pattern types: Prohibit generic args on const params Addresses https://github.com/rust-lang/rust/pull/123689/files#r1562676629. NB: Technically speaking, *not* prohibiting generics args on const params is not a bug as `pattern_types` is an *internal* feature and as such any uncaught misuses of it are considered to be the fault of the user. However, permitting this makes me slightly uncomfortable esp. since we might want to make pattern types available to the public at some point and I don't want this oversight to be able to slip into the language (for comparison, ICEs triggered by the use of internal features are like super fine). Furthermore, this is an ad hoc fix. A more general fix would be changing the representation of the pattern part of pattern types in such a way that it can reuse preexisting lowering routines for exprs / anon consts. See also this [Zulip discussion](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/pattern.20type.20HIR.20nodes/near/432410768) and #124650. Also note that we currently don't properly typeck the pattern of pat tys. This however is out of scope for this PR. cc ``@oli-obk`` r? ``@spastorino`` as discussed
Disallow cast with trailing braced macro in let-else
This fixes an edge case I noticed while porting #118880 and #119062 to syn.
Previously, rustc incorrectly accepted code such as:
```rust
let foo = &std::ptr::null as &'static dyn std::ops::Fn() -> *const primitive! {
8
} else {
return;
};
```
even though a right curl brace `}` directly before `else` in a `let...else` statement is not supposed to be valid syntax.
An async closure may implement `FnMut`/`Fn` if it has no self-borrows There's no reason that async closures may not implement `FnMut` or `Fn` if they don't actually borrow anything with the closure's env lifetime. Specifically, #123660 made it so that we don't always need to borrow captures from the closure's env. See the doc comment on `should_reborrow_from_env_of_parent_coroutine_closure`: https://github.com/rust-lang/rust/blob/c00957a3e269219413041a4e3565f33b1f9d0779/compiler/rustc_hir_typeck/src/upvar.rs#L1777-L1823 If there are no such borrows, then we are free to implement `FnMut` and `Fn` as permitted by our closure's inferred `ClosureKind`. As far as I can tell, this change makes `async || {}` work in precisely the set of places they used to work before #120361. Fixes #125247. r? oli-obk
…elwoerister Fix `unexpected_cfgs` lint on std closes #125291 r? rust-lang/compiler
Rollup of 5 pull requests Successful merges: - #124896 (miri: rename intrinsic_fallback_checks_ub to intrinsic_fallback_is_spec) - #125015 (Pattern types: Prohibit generic args on const params) - #125049 (Disallow cast with trailing braced macro in let-else) - #125259 (An async closure may implement `FnMut`/`Fn` if it has no self-borrows) - #125296 (Fix `unexpected_cfgs` lint on std) r? `@ghost` `@rustbot` modify labels: rollup
reference type safety invariant docs: clarification The old text could have been read as saying that you can call a function if these requirements are upheld, which is definitely not true as they are an underapproximation of the actual safety invariant. I removed the part about functions relaxing the requirements via their documentation... this seems incoherent with saying that it may actually be unsound to ever temporarily violate the requirement. Furthermore, a function *cannot* just relax this for its return value, that would in general be unsound. And the part about "unsafe code in a safe function may assume these invariants are ensured of arguments passed by the caller" also interacts with relaxing things: clearly, if the invariant has been relaxed, unsafe code cannot rely on it any more. There may be a place to give general guidance on what kinds of function contracts can exist, but the reference type is definitely not the right place to write that down. I also took a clarification from rust-lang/rust#121965 that is orthogonal to the rest of that PR. Cc ```@joshlf``` ```@scottmcm```
…-obk Force the inner coroutine of an async closure to `move` if the outer closure is `move` and `FnOnce` See the detailed comment in `upvar.rs`. Fixes #124867. Fixes #124487. r? oli-obk
…nnethercote Use Backtrace::force_capture instead of Backtrace::capture in rustc_log After rust-lang/rust#125063, the compiler and custom drivers won't automatically set the RUST_BACKTRACE environment variable anymore, so we have to call `Backtrace::force_capture` instead of `Backtrace::capture` to unconditionally capture a backtrace. rustc_log handles enabling backtraces via env vars itself, so we don't want RUST_BACKTRACE to make a difference.
rustdoc: rename `issue-\d+.rs` tests to have meaningful names (part 7) Follow up * rust-lang/rust#116214 * rust-lang/rust#116432 * rust-lang/rust#116824 * rust-lang/rust#118105 * rust-lang/rust#119561 * rust-lang/rust#123574 As always, it's easier to review the commits one at a time. Don't use the Files Changed tab. It's confusing.
…-errors Minor serialize/span tweaks r? ``@jackh726``
Remove unnecessary `.md` from the documentation sidebar Oversight from rust-lang/rust#124772, caught in rust-lang/rust#124772 (comment). r? weihanglo
Stop using `to_hir_binop` in codegen This came up in rust-lang/rust#125359 (comment) , and looking into it we can just use the `mir::BinOp`s directly instead of `hir::BinOpKind`s. (AKA rather than going `mir::BinOp` → `hir::BinOpKind` → `IntPredicate`, just go `mir::BinOp` → `IntPredicate`.)
Rollup of 7 pull requests Successful merges: - #125043 (reference type safety invariant docs: clarification) - #125306 (Force the inner coroutine of an async closure to `move` if the outer closure is `move` and `FnOnce`) - #125355 (Use Backtrace::force_capture instead of Backtrace::capture in rustc_log) - #125382 (rustdoc: rename `issue-\d+.rs` tests to have meaningful names (part 7)) - #125391 (Minor serialize/span tweaks) - #125395 (Remove unnecessary `.md` from the documentation sidebar) - #125399 (Stop using `to_hir_binop` in codegen) r? `@ghost` `@rustbot` modify labels: rollup
|
@bors r+ |
|
☀️ Test successful - checks-actions |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.