XXX fold gcc setup into illumos-toolchain.sh #1
Conversation
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
Tweak output for invalid negative impl errors Follow up to rust-lang#69722. Tweak negative impl errors emitted in the HIR: ``` error[E0192]: invalid negative impl --> $DIR/E0192.rs:9:6 | LL | impl !Trait for Foo { } | ^^^^^^ | = note: negative impls are only allowed for auto traits, like `Send` and `Sync` ```
Currently, constructing a waker requires calling the unsafe
`Waker::from_raw` API. This API requires the user to manually construct
a vtable for the waker themself - which is both cumbersome and very
error prone. This API would provide an ergonomic, straightforward and
guaranteed memory-safe way of constructing a waker.
It has been our longstanding intention that the `Waker` type essentially
function as an `Arc<dyn Wake>`, with a `Wake` trait as defined here. Two
considerations prevented the original API from being shipped as simply
an `Arc<dyn Wake>`:
- We want to support futures on embedded systems, which may not have an
allocator, and in optimized executors for which this API may not be
best-suited. Therefore, we have always explicitly supported the
maximally-flexible (but also memory-unsafe) `RawWaker` API, and
`Waker` has always lived in libcore.
- Because `Waker` lives in libcore and `Arc` lives in liballoc, it has
not been feasible to provide a constructor for `Waker` from `Arc<dyn
Wake>`.
Therefore, the Wake trait was left out of the initial version of the
task waker API.
However, as Rust 1.41, it is possible under the more flexible orphan
rules to implement `From<Arc<W>> for Waker where W: Wake` in liballoc.
Therefore, we can now define this constructor even though `Waker` lives
in libcore.
This PR adds these APIs:
- A `Wake` trait, which contains two methods
- A required method `wake`, which is called by `Waker::wake`
- A provided method `wake_by_ref`, which is called by
`Waker::wake_by_ref` and which implementors can override if they
can optimize this use case.
- An implementation of `From<Arc<W>> for Waker where W: Wake + Send +
Sync + 'static`
- A similar implementation of `From<Arc<W>> for RawWaker`.
Co-Authored-By: Ashley Mannix <[email protected]>
Co-Authored-By: Ashley Mannix <[email protected]>
Co-Authored-By: Ashley Mannix <[email protected]>
Changes: ```` rustup rust-lang#69968 Fix documentation generation for configurable lints Fix single binding in closure Improvement: Don't show function body in needless_lifetimes ````
update miri r? @ghost Cc @oli-obk Fixes rust-lang#70220
Co-Authored-By: Mazdak Farrokhzad <[email protected]>
…oats
Add Wake trait for safe construction of Wakers.
Currently, constructing a waker requires calling the unsafe `Waker::from_raw` API. This API requires the user to manually construct a vtable for the waker themself - which is both cumbersome and very error prone. This API would provide an ergonomic, straightforward and guaranteed memory-safe way of constructing a waker.
It has been our longstanding intention that the `Waker` type essentially function as an `Arc<dyn Wake>`, with a `Wake` trait as defined here. Two considerations prevented the original API from being shipped as simply an `Arc<dyn Wake>`:
- We want to support futures on embedded systems, which may not have an allocator, and in optimized executors for which this API may not be best-suited. Therefore, we have always explicitly supported the maximally-flexible (but also memory-unsafe) `RawWaker` API, and `Waker` has always lived in libcore.
- Because `Waker` lives in libcore and `Arc` lives in liballoc, it has not been feasible to provide a constructor for `Waker` from `Arc<dyn Wake>`.
Therefore, the Wake trait was left out of the initial version of the task waker API.
However, as Rust 1.41, it is possible under the more flexible orphan rules to implement `From<Arc<W>> for Waker where W: Wake` in liballoc. Therefore, we can now define this constructor even though `Waker` lives in libcore.
This PR adds these APIs:
- A `Wake` trait, which contains two methods
- A required method `wake`, which is called by `Waker::wake`
- A provided method `wake_by_ref`, which is called by `Waker::wake_by_ref` and which implementors can override if they can optimize this use case.
- An implementation of `From<Arc<W>> for Waker where W: Wake + Send + Sync + 'static`
- A similar implementation of `From<Arc<W>> for RawWaker`.
rustc_mir: remove extra space when pretty-printing MIR.
Add test for issue rust-lang#53275 Fixes rust-lang#53275
…y-spans-into-invalid-lines, r=estebank Revised span-to-lines conversion to produce an empty vec on DUMMY_SP. This required revising some of the client code to stop relying on the returned set of lines being non-empty. Fix rust-lang#68808
add err_machine_stop macro We have that for all other error kinds, but here I somehow forgot it. r? @oli-obk
…ble_warning, r=Dylan-DPC Reword unused variable warning Fixes rust-lang#66636
Rename remaining occurences of Void to Opaque. Two mentions of the type were missed when the type was renamed.
Split long derive lists into two derive attributes.
permit negative impls for non-auto traits This is a prototype impl that extends `impl !Trait` beyond auto traits. It is not integrated with coherence or anything else, and hence only serves to prevent downstream impls (but not to allow downstream crates to rely on the absence of such impls for coherence purposes). Fixes rust-lang#66544 TODO: - [x] need a test that you can't rely on negative impls for coherence purposes - [x] test that negative impls cannot specialize positive ones - [x] test that positive impls cannot specialize negative ones - [x] extend negative impl to `Clone` in order to fully fix rust-lang#66544 - [x] and maybe make `CoerceUnsized` unsafe? -- that problem is now split out into rust-lang#68015 - [x] introduce feature flag and prepare a write-up - [x] improve diagnostics?
Miri nits: comment and var name improvement r? @eddyb
Fix for rust-lang#62691: use the largest niche across all fields fixes rust-lang#62691 (The second commit is a small optimization but it makes the code less pretty and i don't know if it is worth it.)
parser: recover on `...` as a pattern, suggesting `..` Fixes rust-lang#70388 My first PR to rust. So please let me know if I'm doing something wrong.
simplify match stmt
We actually have a surprising amount of
```rust
match expr {
$($p:pat)|+ => true,
_ => false,
}
```
While I would prefer this to be replaced with `matches!`, most cases are
fairly readable anyway so we can just let them be for now.
Rollup of 5 pull requests Successful merges: - rust-lang#68004 (permit negative impls for non-auto traits) - rust-lang#70385 (Miri nits: comment and var name improvement) - rust-lang#70411 (Fix for rust-lang#62691: use the largest niche across all fields) - rust-lang#70417 (parser: recover on `...` as a pattern, suggesting `..`) - rust-lang#70424 (simplify match stmt) Failed merges: r? @ghost
…he static libraries
Co-Authored-By: Patrick Mooney <[email protected]>
jclulow
pushed a commit
that referenced
this pull request
Jun 8, 2020
…ing opaque return type
Go from
```
error[E0495]: cannot infer an appropriate lifetime due to conflicting requirements
--> file8.rs:22:5
|
22 | / move || {
23 | | *dest = g.get();
24 | | }
| |_____^
|
note: first, the lifetime cannot outlive the anonymous lifetime #1 defined on the function body at 18:1...
--> file8.rs:18:1
|
18 | / fn bat<'a, G: 'a, T>(g: G, dest: &mut T) -> impl FnOnce() + '_ + 'a
19 | | where
20 | | G: Get<T>
21 | | {
... |
24 | | }
25 | | }
| |_^
note: ...so that the types are compatible
--> file8.rs:22:5
|
22 | / move || { //~ ERROR cannot infer an appropriate lifetime
23 | | *dest = g.get();
24 | | }
| |_____^
= note: expected `&mut T`
found `&mut T`
note: but, the lifetime must be valid for the lifetime `'a` as defined on the function body at 18:8...
--> file8.rs:18:8
|
18 | fn bat<'a, G: 'a, T>(g: G, dest: &mut T) -> impl FnOnce() + '_ + 'a
| ^^
note: ...so that return value is valid for the call
--> file8.rs:18:45
|
18 | fn bat<'a, G: 'a, T>(g: G, dest: &mut T) -> impl FnOnce() + '_ + 'a
| ^^^^^^^^^^^^^^^^^^^^^^^
```
to
```
error[E0621]: explicit lifetime required in the type of `dest`
--> file8.rs:18:45
|
18 | fn bat<'a, G: 'a, T>(g: G, dest: &mut T) -> impl FnOnce() + '_ + 'a
| ------ ^^^^^^^^^^^^^^^^^^^^^^^ lifetime `'a` required
| |
| help: add explicit lifetime `'a` to the type of `dest`: `&'a mut T`
```
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.
Moves gcc setup into your
illumos-toolchain.shscript and cleans up the source and build directories after success.