-
Notifications
You must be signed in to change notification settings - Fork 12.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rollup of 10 pull requests #98730
Rollup of 10 pull requests #98730
Conversation
Fixes rust-lang#72793 r? @oli-obk
It helps programmers coming from other languages modified: compiler/rustc_resolve/src/late/diagnostics.rs modified: src/test/ui/lint/recommend-literal.rs modified: src/test/ui/lint/recommend-literal.stderr modified: compiler/rustc_resolve/src/late/diagnostics.rs modified: src/test/ui/lint/recommend-literal.rs modified: src/test/ui/lint/recommend-literal.stderr modified: compiler/rustc_resolve/src/late/diagnostics.rs modified: src/test/ui/lint/recommend-literal.rs modified: src/test/ui/lint/recommend-literal.stderr
[core] add `Exclusive` to sync (discussed here: https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Adding.20.60SyncWrapper.60.20to.20std) `Exclusive` is a wrapper that exclusively allows mutable access to the inner value if you have exclusive access to the wrapper. It acts like a compile time mutex, and hold an unconditional `Sync` implementation. ## Justification for inclusion into std - This wrapper unblocks actual problems: - The example that I hit was a vector of `futures::future::BoxFuture`'s causing a central struct in a script to be non-`Sync`. To work around it, you either write really difficult code, or wrap the futures in a needless mutex. - Easy to maintain: this struct is as simple as a wrapper can get, and its `Sync` implementation has very clear reasoning - Fills a gap: `&/&mut` are to `RwLock` as `Exclusive` is to `Mutex` ## Public Api ```rust // core::sync #[derive(Default)] struct Exclusive<T: ?Sized> { ... } impl<T: ?Sized> Sync for Exclusive {} impl<T> Exclusive<T> { pub const fn new(t: T) -> Self; pub const fn into_inner(self) -> T; } impl<T: ?Sized> Exclusive<T> { pub const fn get_mut(&mut self) -> &mut T; pub const fn get_pin_mut(Pin<&mut self>) -> Pin<&mut T>; pub const fn from_mut(&mut T) -> &mut Exclusive<T>; pub const fn from_pin_mut(Pin<&mut T>) -> Pin<&mut Exclusive<T>>; } impl<T: Future> Future for Exclusive { ... } impl<T> From<T> for Exclusive<T> { ... } impl<T: ?Sized> Debug for Exclusive { ... } ``` ## Naming This is a big bikeshed, but I felt that `Exclusive` captured its general purpose quite well. ## Stability and location As this is so simple, it can be in `core`. I feel that it can be stabilized quite soon after it is merged, if the libs teams feels its reasonable to add. Also, I don't really know how unstable feature work in std/core's codebases, so I might need help fixing them ## Tips for review The docs probably are the thing that needs to be reviewed! I tried my best, but I'm sure people have more experience than me writing docs for `Core` ### Implementation: The API is mostly pulled from https://docs.rs/sync_wrapper/latest/sync_wrapper/struct.SyncWrapper.html (which is apache 2.0 licenesed), and the implementation is trivial: - its an unsafe justification for pinning - its an unsafe justification for the `Sync` impl (mostly reasoned about by ````@danielhenrymantilla```` here: Actyx/sync_wrapper#2) - and forwarding impls, starting with derivable ones and `Future`
fix data race in thread::scope Puts the `ScopeData` into an `Arc` so it sticks around as long as we need it. This means one extra `Arc::clone` per spawned scoped thread, which I hope is fine. Fixes rust-lang#98498 r? `````@m-ou-se`````
…Value, r=nikic llvm-wrapper: adapt for LLVMConstExtractValue removal `LLVMConstExtractValue` was removed recently from LLVM: llvm/llvm-project@5548e80. This adapts llvm-wrapper to use the new alternative where available, following https://rust-lang.zulipchat.com/#narrow/stream/187780-t-compiler.2Fwg-llvm/topic/LLVMConstExtractValue.20removal.
…, r=notriddle Fix source sidebar bugs This PR fixes the following two bugs: ![Screenshot from 2022-06-29 14-39-58](https://user-images.githubusercontent.com/3050060/176449070-3e3762da-2bfe-4acf-8eb0-34f6eb4c94ed.png) ![Screenshot from 2022-06-29 15-05-09](https://user-images.githubusercontent.com/3050060/176449073-b164820b-bd71-4b1a-990c-bba4e5fce196.png) I added regression tests to prevent them to happen again. I think we should backport it to beta as well. You can test it [here](https://rustdoc.crud.net/imperio/source-sidebar-fixes/src/std/lib.rs.html). cc ```@jsha``` r? ```@notriddle```
For diagnostic information of Boolean, remind it as use the type: 'bool' Fixes rust-lang#98492. It helps programmers coming from other languages modified: compiler/rustc_resolve/src/late/diagnostics.rs
add test for 72793 Fixes rust-lang#72793 r? ````@oli-obk````
interpret: add From<&MplaceTy> for PlaceTy We have a similar instance for `&MPlaceTy` to `OpTy`. Also add the same for `&mut`. This avoids having to write `&(*place).into()`, which we have a few times here and at least twice in Miri (and it comes up again in my current patch). r? ```@oli-obk```
use "or pattern"
…sers, r=Dylan-DPC Remove unneeded methods declaration for old web browsers All these methods were not defined for IE mostly. But since we don't support it anymore, no need to keep them around. cc ```@jsha``` r? ```@notriddle```
…=jyn514 get rid of tidy 'unnecessarily ignored' warnings I think these warnings are quite pointless: when I say `allow(foo)` in my code, that doesn't necessarily mean that I expect `foo` to happen -- it just means that I am okay with `foo` happening. For example, having to add and remove `ignore-tidy-linelength` as the longest line in the file keeps growing and shrinking is just annoying and doesn't benefit anyone, IMO. This usually incurs *two* CI roundtrips: first CI tells you that line lengths in your test file are ignored unnecessarily, so you go and remove that attribute; then CI tells you that now your line numbers changed, so you re-bless your tests (often takes >5min if parts of rustc need rebuilding because `./x.py fmt` changed something somewhere). That's just a lot of wasted effort and time and patience.
⌛ Testing commit 6e918b4 with merge 8205cde30d7065268efdd11579b14e875706fd21... |
💔 Test failed - checks-actions |
@bors retry artifact upload timeout |
⌛ Testing commit 6e918b4 with merge e0000266accac8b548df6606132358f3ebea26df... |
@bors retry auto (dist-arm-linux, ubuntu-20.04-xl) hang during artifact upload |
⌛ Testing commit 6e918b4 with merge fcea282328b404ddd8840cc71b117a8eb56e01f3... |
💔 Test failed - checks-actions |
@bors retry network failure
|
☀️ Test successful - checks-actions |
Finished benchmarking commit (ca1e68b): comparison url. Instruction count
Max RSS (memory usage)Results
CyclesResults
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. @rustbot label: -perf-regression Footnotes |
Successful merges:
Exclusive
to sync #97629 ([core] addExclusive
to sync)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup