Repository navigation
Rollup of 14 pull requests - #164026
Closed
JonathanBrouwer wants to merge 35 commits into
Closed
Rollup of 14 pull requests#164026JonathanBrouwer wants to merge 35 commits into
JonathanBrouwer wants to merge 35 commits into
Conversation
… bare trait object types (`(use<…>)+`)
```
error[E0277]: `{closure@$DIR/suggest-calling-fn-in-for-loop-issue-161564.rs:33:19: 33:21}` is not an iterator
--> $DIR/suggest-calling-fn-in-for-loop-issue-161564.rs:34:14
|
LL | for _ in closure {}
| ^^^^^^^ `{closure@$DIR/suggest-calling-fn-in-for-loop-issue-161564.rs:33:19: 33:21}` is not an iterator
|
help: the trait `Iterator` is not implemented for closure `{closure@$DIR/suggest-calling-fn-in-for-loop-issue-161564.rs:33:19: 33:21}`
--> $DIR/suggest-calling-fn-in-for-loop-issue-161564.rs:33:19
|
LL | let closure = || vec![1u8].into_iter();
| ^^
= note: required for `{closure@$DIR/suggest-calling-fn-in-for-loop-issue-161564.rs:33:19: 33:21}` to implement `IntoIterator`
help: use parentheses to call this closure
|
LL | for _ in closure() {}
| ++
```
… old solver and update `incorrect-skip-binder-for-item-bound` test accordingly.
`CanonicalVarValues` is serving two roles. There are the places where it's a real substitution (e.g. return value of `instantiate`), and places where it's just a result never used for instantiation (e.g. `Response` and `inspect::State` and `EvalCtxt`). The latter can just be `I::GenericArgs`. Simplifications from this: - Removes some `var_values.var_values` chains. - `make_identity` can be inlined into its single caller. - `CanonicalVarValues::is_identity*` can be moved to methods of `Response`. - `CanonicalVarValues::dummy` is no longer needed.
Similar to the previous commit, but for the old solver.
…r=adwinwhite Syntactically reject leading parenthesized precise capturing lists in bare trait object types (`(use<…>)+`) Follow-up to rust-lang#162269. Addresses fmease/rasur#7 (item 6). <sub>(No LLM was or will be used by me during the entire creation process of this PR)</sub>
…iveness, r=tmiasko MIR move elimination [3/6]: PreciseLiveness Depends on rust-lang#163335 This PR implements the lifetime analysis used by the `MoveElimination` pass from rust-lang/rfcs#3943. `PreciseLiveness` calculates, at a sub-statement granularity, the points in a function where a local requires storage to be allocated. This is more fine-grained than `MaybeStorageLive`, and takes borrows into account. r? tmiasko
…=Kobzol fix(bootstrap/darwin): fix rpath for distributed LLD Closes rust-lang#163947 by mirroring the existing rpath tweak for linux on darwin. ## Concerns - [ ] Is there an easy way to reliably test the effect of this fix (there doesn't seem to be dist tests for darwin in particular)? I'd love to add one if possible.
…oss35 cfi: mangle `f128` as `e` rather than `g` on platforms without `_Float128` On the Linux platform, only `x86` and `x86_64` support `Float128`. (see https://github.com/llvm/llvm-project/blob/bd5b1f58ae58cceab2cadb882cceb1d96f4ad33e/clang/lib/Basic/Targets/OSTargets.h#L431) Therefore, for aarch64, the `f128` type corresponds exclusively to `long double`. In addition, `aarch64` does not overload `getLongDoubleMangling` and `getFloat128Mangling`.(see https://github.com/llvm/llvm-project/blob/bd5b1f58ae58cceab2cadb882cceb1d96f4ad33e/clang/include/clang/Basic/TargetInfo.h#L822) Therefore, `aarch64` on Linux should send `e` instead of `g`. For Windows and Apple `aarch64`, the `long double` type is 64-bit, so these targets need to be excluded. The corresponding tests are added. LLM disclosure: This commit is entirely handwritten. r? @tgross35
move overflow lint computation into decorator implements rust-lang#163064 (comment) r? adwinwhite
…JohnTitor Updates the expect message library/core/src/time.rs updates the expect message in library/core/src/time.rs. Updated to show the expected state instead of what actually happened. rust-lang#159751
rigid aliases to non-rigid for fully normalized check otherwise we incorrectly mark rust-lang#163724 / rust-lang#152416 as fixed with the new solver 😅 r? adwinwhite
…-possible, r=adwinwhite replace `fully_monomorphized` with `cx.typing_env()` cc rust-lang#163724 reasoning about whether a given `TypingEnv` is correct is non-trivial, so if we've got a context which already provides the correct `TypingEnv`, using that is easier.
Fix debug assert failure in `note_obligation_cause_code_inner` Applied the recommended fix and turned the crash test into a regression test. Closes rust-lang#139381. r? lcnr
const-eval: ICE when we hit a non-const fn We made this a "nice" error solely so we can test miri-unleashed better, but it was never meant to be an error that users can actually get -- just a second line of defense in case there is a bug in our const checking logic. This seems to [cause some confusion](rust-lang#161627 (comment)) so let's make it an ICE when Miri is not unleashed. This also uncovered that even if `const_precise_live_drops` finds a problem, we still run the code that was found to not be const-safe: rust-lang#163973. r? @oli-obk Cc @tmiasko
When mentioning that closure doesn't implement trait, point at closure
```
error[E0277]: `{closure@$DIR/suggest-calling-fn-in-for-loop-issue-161564.rs:33:19: 33:21}` is not an iterator
--> $DIR/suggest-calling-fn-in-for-loop-issue-161564.rs:34:14
|
LL | for _ in closure {}
| ^^^^^^^ `{closure@$DIR/suggest-calling-fn-in-for-loop-issue-161564.rs:33:19: 33:21}` is not an iterator
|
help: the trait `Iterator` is not implemented for closure `{closure@$DIR/suggest-calling-fn-in-for-loop-issue-161564.rs:33:19: 33:21}`
--> $DIR/suggest-calling-fn-in-for-loop-issue-161564.rs:33:19
|
LL | let closure = || vec![1u8].into_iter();
| ^^
= note: required for `{closure@$DIR/suggest-calling-fn-in-for-loop-issue-161564.rs:33:19: 33:21}` to implement `IntoIterator`
help: use parentheses to call this closure
|
LL | for _ in closure() {}
| ++
```
…d, r=Urgau [rustdoc] Prefer local paths over remote ones when foreign item is locally reexported This is the last failure from rust-lang#162808: ``` src/std/sys/fs/unix.rs.html:1171: broken link fragment `#method.new` pointing to `core/io/struct.Error.html` ``` `std` reexports `Error` locally, and `alloc` is the one implementing the `Error::new` method. So `std` has both `Error` and `Error::new` locally. So instead of trying to link to `core::Error::new` (which doesn't exist), we first check if we locally reexport `Error` with the `paths` map and use it as a shortcut. PS: I got annoyed about adding/removing `#[derive(Debug)]` every time so this time I just leave them there. :3 r? @Urgau
cg_llvm: Avoid some explicit casts to `*const c_char` - Follow-up to rust-lang#163789 --- This is another application of the general principle noted in `rustc_codegen_llvm::ffi`: > Normally it's a good idea for Rust-side bindings to match the corresponding C-side function declarations as closely as possible. But when passing `&str` or `&[u8]` data as a pointer/length pair, it's more convenient to declare the Rust-side pointer as `*const c_uchar` instead of `*const c_char`. Both pointer types have the same ABI, and using `*const c_uchar` avoids the need for an extra cast from `*const u8` on the Rust side. For the changes in the main commit, a pointer/length string was being passed with `*const c_char` as the pointer type. This PR changes the Rust-side declaration to take `*const c_uchar` instead. Changing the declared type avoids the need for explicit casts, making it easier to notice any accidental type errors. --- A second commit also removes some pointer casts that were completely unnecessary. There should be no change to compiler output.
…s, r=lcnr Less `CanonicalVarValues` It was bugging me that `CanonicalVarValues` is used in two different ways. Here's my attempt to remedy that. r? @lcnr
Member
Author
|
@bors r+ p=5 force |
Contributor
Contributor
|
This pull request was unapproved due to being closed. |
This file contains hidden or 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
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.
Successful merges:
(use<…>)+) #162652 (Syntactically reject leading parenthesized precise capturing lists in bare trait object types ((use<…>)+))f128aserather thangon platforms without_Float128#163193 (cfi: manglef128aserather thangon platforms without_Float128)fully_monomorphizedwithcx.typing_env()#163745 (replacefully_monomorphizedwithcx.typing_env())note_obligation_cause_code_inner#163912 (Fix debug assert failure innote_obligation_cause_code_inner)*const c_char#164017 (cg_llvm: Avoid some explicit casts to*const c_char)CanonicalVarValues#164025 (LessCanonicalVarValues)r? @ghost
Create a similar rollup