- 29 7月, 2021 19 次提交
-
-
由 bors 提交于
Make const panic!("..") work in Rust 2021. During const eval, this replaces calls to core::panicking::panic_fmt and std::panicking::being_panic_fmt with a call to a new const fn: core::panicking::const_panic_fmt. That function uses fmt::Arguments::as_str() to get the str and calls panic_str with that instead. panic!() invocations with formatting arguments are still not accepted, as the creation of such a fmt::Arguments cannot be done in constant functions right now. r? `@RalfJung`
-
由 bors 提交于
Create `QuerySideEffects` and use it for diagnostics The code for saving and loading diagnostics during execution is generalized to handle a new `QuerySideEffects` struct. Currently, this struct just holds diagnostics - in a follow-up PR, I plan to add support for storing attriutes marked as used during query execution. This is a pure refactor, with no intended behavior changes.
-
由 bors 提交于
Remove unsound TrustedRandomAccess implementations Removes the implementations that depend on the user-definable trait `Copy`. Fixes #85873 in the most straightforward way. <hr> _Edit:_ This PR now contains additional trait infrastructure to avoid performance regressions around in-place collect, see the discussion in this thread starting from the codegen test failure at https://github.com/rust-lang/rust/pull/85874#issuecomment-872327577. With this PR, `TrustedRandomAccess` gains additional documentation that specifically allows for and specifies the safety conditions around subtype coercions – those coercions can happen in safe Rust code with the `Zip` API’s usage of `TrustedRandomAccess`. This PR introduces a new supertrait of `TrustedRandomAccess`(currently named `TrustedRandomAccessNoCoerce`) that _doesn’t allow_ such coercions, which means it can be still be useful for optimizing cases such as in-place collect where no iterator is handed out to a user (who could do coercions) after a `get_unchecked` call; the benefit of the supertrait is that it doesn’t come with the additional safety conditions around supertraits either, so it can be implemented for more types than `TrustedRandomAccess`. The `TrustedRandomAccess` implementations for `vec::IntoIter`, `vec_deque::IntoIter`, and `array::IntoIter` are removed as they don’t conform with the newly documented safety conditions, this way unsoundness is removed. But this PR in turn (re-)adds a `TrustedRandomAccessNoCoerce` implementation for `vec::IntoIter` to avoid performance regressions from stable in a case of in-place collecting of `Vec`s [the above-mentioned codegen test failure]. Re-introducing the (currently nightly+beta-only) impls for `VecDeque`’s and `[T; N]`’s iterators is technically possible, but goes beyond the scope of this PR (i.e. it can happen in a future PR).
-
由 bors 提交于
Rollup of 10 pull requests Successful merges: - #81050 (Stabilize core::task::ready!) - #81363 (Remove P: Unpin bound on impl Future for Pin) - #86839 (Add doc aliases to fs.rs) - #87435 (fix example code for E0617) - #87451 (Add support for tuple struct field documentation) - #87491 (Integrate context into the memorial to Anna) - #87521 (Add long explanation for E0498) - #87527 (Don't run MIR unsafeck at all when using `-Zthir-unsafeck`) - #87550 (Add `CI_ONLY_WHEN_CHANNEL` and run `x86_64-gnu-stable` only on nightly) - #87565 (Use backticks when referring to `core::future::Ready` in panic message) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
-
由 Yuki Okushi 提交于
Use backticks when referring to `core::future::Ready` in panic message
-
由 Yuki Okushi 提交于
Add `CI_ONLY_WHEN_CHANNEL` and run `x86_64-gnu-stable` only on nightly Backporting a commit made on #87508. cc ``@Mark-Simulacrum``
-
由 Yuki Okushi 提交于
Don't run MIR unsafeck at all when using `-Zthir-unsafeck` I don't know how I missed this :D r? ``@oli-obk``
-
由 Yuki Okushi 提交于
Add long explanation for E0498 Helps with #61137
-
由 Yuki Okushi 提交于
Integrate context into the memorial to Anna This came up after I reviewed https://github.com/rust-lang/rust/pull/87298, but I didn't propose this in time before that PR was merged. If y'all feel this is too much churn on the file, no worries, feel free to close, but I felt this was a more fitting integration of the memorial into the test suite. CC ``@boringcactus.``
-
由 Yuki Okushi 提交于
Add support for tuple struct field documentation Fixes #42615. This is #80320 updated to new codebase and with added tests. Part of https://github.com/rust-lang/rust/issues/83255. cc ```@camelid``` (since you were involved on the original PR). r? ```@jyn514```
-
由 Yuki Okushi 提交于
fix example code for E0617 Closes #86908
-
由 Yuki Okushi 提交于
Add doc aliases to fs.rs Add aliases for create_dir, create_dir_all, remove_dir, remove_dir_all
-
由 Yuki Okushi 提交于
Remove P: Unpin bound on impl Future for Pin We can safely produce a `Pin<&mut P::Target>` without moving out of the `Pin` by using `Pin::as_mut` directly. The `Unpin` bound was originally added in #56939 following the recommendation of ``@withoutboats`` in https://github.com/rust-lang/rust/issues/55766#issue-378417538 That comment does not give explicit justification for why the bound should be added. The relevant context was: > [ ] Remove `impl<P> Unpin for Pin<P>` > > This impl is not justified by our standard justification for unpin impls: there is no pointer direction between `Pin<P>` and `P`. Its usefulness is covered by the impls for pointers themselves. > > This futures impl (link to the impl changed in this PR) will need to change to add a `P: Unpin` bound. The decision to remove the unconditional impl of `Unpin for Pin` is sound (these days there is just an auto-impl for when `P: Unpin`). But, I think the decision to also add the `Unpin` bound for `impl Future` may have been unnecessary. Or if that's not the case, I'd be very interested to have the argument for why written down somewhere. The bound _appears_ to not be needed, as demonstrated by the change requiring no unsafe code and by the existence of `Pin::as_mut`.
-
由 Yuki Okushi 提交于
Stabilize core::task::ready! _Tracking issue: https://github.com/rust-lang/rust/issues/70922_ This PR stabilizes the `task::ready!` macro. Similar to https://github.com/rust-lang/rust/pull/80886, this PR was waiting on https://github.com/rust-lang/rust/issues/74355 to be fixed. The `task::ready!` API has existed in the futures ecosystem for several years, and was added on nightly last year in https://github.com/rust-lang/rust/pull/70817. The motivation for this macro is the same as it was back then: virtually every single manual future implementation makes use of this; so much so that it's one of the few things included in the [futures-core](https://docs.rs/futures-core/0.3.12/futures_core) library. r? ``@tmandry`` cc/ ``@rust-lang/wg-async-foundations`` ``@rust-lang/libs`` ## Example ```rust use core::task::{Context, Poll}; use core::future::Future; use core::pin::Pin; async fn get_num() -> usize { 42 } pub fn do_poll(cx: &mut Context<'_>) -> Poll<()> { let mut f = get_num(); let f = unsafe { Pin::new_unchecked(&mut f) }; let num = ready!(f.poll(cx)); // ... use num Poll::Ready(()) } ```
-
由 Ibraheem Ahmed 提交于
-
由 Ibraheem Ahmed 提交于
-
由 bors 提交于
update Miri Fixes https://github.com/rust-lang/rust/issues/87518 Cc `@rust-lang/miri` r? `@ghost`
-
由 D1mon 提交于
Add `mkdir` to `create_dir`, `rmdir` to `remove_dir`.
-
由 bors 提交于
Rollup of 10 pull requests Successful merges: - #87315 (Add docs for raw-dylib to unstable book) - #87330 (Use hashbrown's `extend_reserve()` in `HashMap`) - #87443 (Don't treat git repos as non-existent when `ignore_git` is set) - #87453 (Suggest removing unnecessary &mut as help message) - #87500 (Document math behind MIN/MAX consts on integers) - #87501 (Remove min_type_alias_impl_trait in favor of type_alias_impl_trait) - #87507 (SGX mutex is *not* moveable) - #87513 (bootstrap.py: change `git log` option to indicate desired behavior) - #87523 (Stop creating a reference then immediately dereferencing it.) - #87524 (Fix ICE in `diagnostic_hir_wf_check`) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
-
- 28 7月, 2021 21 次提交
-
-
由 Mara Bos 提交于
-
由 Mara Bos 提交于
-
由 Mara Bos 提交于
Co-authored-by: NRalf Jung <post@ralfj.de>
-
由 Mara Bos 提交于
-
由 Mara Bos 提交于
-
由 Mara Bos 提交于
-
由 Mara Bos 提交于
-
由 Mara Bos 提交于
-
由 Mara Bos 提交于
-
由 Mara Bos 提交于
During const eval, this replaces calls to core::panicking::panic_fmt and std::panicking::being_panic_fmt with a call to a new const fn: core::panicking::const_panic_fmt. That function uses fmt::Arguments::as_str() to get the str and calls panic_str with that instead. panic!() invocations with formatting arguments are still not accepted, as the creation of such a fmt::Arguments cannot be done in constant functions right now.
-
由 Pietro Albini 提交于
-
由 Frank Steffahn 提交于
-
由 Frank Steffahn 提交于
-
由 Frank Steffahn 提交于
-
由 Frank Steffahn 提交于
-
由 Frank Steffahn 提交于
-
由 Frank Steffahn 提交于
Add TrustedRandomAccessNoCoerce supertrait without requirements or guarantees about subtype coercions Update all the TrustedRandomAccess impls to also implement the new supertrait
-
由 Frank Steffahn 提交于
Include new details regarding coercions to a subtype. These conditions also explain why the previously removed implementations for {array, vec, vec_deque}::IntoIter<T> were unsound, because they introduced an extra `T: Clone` for the TrustedRandomAccess impl, even though their parameter T is covariant.
-
由 Frank Steffahn 提交于
Removes the implementations that depend on the user-definable trait `Copy`.
-
由 Yuki Okushi 提交于
Fix ICE in `diagnostic_hir_wf_check` Fixes #87495. The [documentation for `ObligationCauseCode::WellFormed`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_infer/traits/enum.ObligationCauseCode.html#variant.WellFormed) says that > it is always correct [...] to specify `WellFormed(None)` instead of `WellFormed(Some(...))`, which seems to have caused the issue here, as `diagnostic_hir_wf_check` does not expect to be called with an associated constant and will ICE: https://github.com/rust-lang/rust/blob/fd853c00e255559255885aadff9e93a1760c8728/compiler/rustc_typeck/src/hir_wf_check.rs#L131-L134 Therefore, I have changed `check_associated_item()` to pass a `WellFormed(None)` for associated constants. r? ``@Aaron1011``
-
由 Yuki Okushi 提交于
Stop creating a reference then immediately dereferencing it. Stop creating a reference then immediately dereferencing it.
-