- 24 3月, 2020 17 次提交
-
-
由 Camille GILLOT 提交于
-
由 Camille GILLOT 提交于
-
由 Camille GILLOT 提交于
-
由 Camille GILLOT 提交于
-
由 Camille GILLOT 提交于
-
由 Camille GILLOT 提交于
-
由 bors 提交于
Rollup of 9 pull requests Successful merges: - #68700 (Add Wake trait for safe construction of Wakers.) - #69494 (Stabilize --crate-version option in rustdoc) - #70080 (rustc_mir: remove extra space when pretty-printing MIR.) - #70195 (Add test for issue #53275) - #70199 (Revised span-to-lines conversion to produce an empty vec on DUMMY_SP.) - #70299 (add err_machine_stop macro) - #70300 (Reword unused variable warning) - #70315 (Rename remaining occurences of Void to Opaque.) - #70318 (Split long derive lists into two derive attributes.) Failed merges: r? @ghost
-
由 Mazdak Farrokhzad 提交于
Split long derive lists into two derive attributes.
-
由 Mazdak Farrokhzad 提交于
Rename remaining occurences of Void to Opaque. Two mentions of the type were missed when the type was renamed.
-
由 Mazdak Farrokhzad 提交于
Reword unused variable warning Fixes #66636
-
由 Mazdak Farrokhzad 提交于
add err_machine_stop macro We have that for all other error kinds, but here I somehow forgot it. r? @oli-obk
-
由 Mazdak Farrokhzad 提交于
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 #68808
-
由 Mazdak Farrokhzad 提交于
Add test for issue #53275 Fixes #53275
-
由 Mazdak Farrokhzad 提交于
rustc_mir: remove extra space when pretty-printing MIR.
-
由 Mazdak Farrokhzad 提交于
Stabilize --crate-version option in rustdoc I don't see any reason to not stabilize it anymore, so let's go! cc @kinnison @ehuss r? @ollie27
-
由 Mazdak Farrokhzad 提交于
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`.
-
由 Felix S Klock II 提交于
Co-Authored-By: NMazdak Farrokhzad <twingoow@gmail.com>
-
- 23 3月, 2020 23 次提交
-
-
由 bors 提交于
update miri r? @ghost Cc @oli-obk Fixes https://github.com/rust-lang/rust/issues/70220
-
由 Ana-Maria Mihalache 提交于
-
由 Saoirse Shipwreckt 提交于
Co-Authored-By: NAshley Mannix <ashleymannix@live.com.au>
-
由 Saoirse Shipwreckt 提交于
Co-Authored-By: NAshley Mannix <ashleymannix@live.com.au>
-
由 Saoirse Shipwreckt 提交于
Co-Authored-By: NAshley Mannix <ashleymannix@live.com.au>
-
由 Without Boats 提交于
-
由 Without Boats 提交于
-
由 Without Boats 提交于
-
由 Without Boats 提交于
-
由 Without Boats 提交于
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`.
-
由 Ana-Maria Mihalache 提交于
-
由 Ralf Jung 提交于
-
由 bors 提交于
Tweak output for invalid negative impl errors Follow up to #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` ```
-
由 Ryan Levick 提交于
-
由 bors 提交于
Rollup of 8 pull requests Successful merges: - #69080 (rustc_codegen_llvm: don't generate any type debuginfo for -Cdebuginfo=1.) - #69940 (librustc_codegen_llvm: Replace deprecated API usage) - #69942 (Increase verbosity when suggesting subtle code changes) - #69968 (rustc: keep upvars tupled in {Closure,Generator}Substs.) - #70123 (Ensure LLVM is in the link path for rustc tools) - #70159 (Update the bundled wasi-libc with libstd) - #70233 (resolve: Do not resolve visibilities on proc macro definitions twice) - #70286 (Miri error type: remove UbExperimental variant) Failed merges: r? @ghost
-
由 Mazdak Farrokhzad 提交于
Miri error type: remove UbExperimental variant In https://github.com/rust-lang/miri/pull/1250, I will move Miri away from that variant, and use a custom `MachineStop` exception instead.
-
由 Mazdak Farrokhzad 提交于
resolve: Do not resolve visibilities on proc macro definitions twice Fixes https://github.com/rust-lang/rust/issues/68921
-
由 Mazdak Farrokhzad 提交于
Update the bundled wasi-libc with libstd Brings in WebAssembly/wasi-libc#184 which can help standalone programs with environment variables!
-
由 Mazdak Farrokhzad 提交于
Ensure LLVM is in the link path for rustc tools The build script for `rustc_llvm` outputs LLVM information in `cargo:rustc-link-lib` and `cargo:rustc-link-search` so the compiler can be linked correctly. However, while the lib is carried along in metadata, the search paths are not. So when cargo is invoked again later for rustc _tools_, they'll also try to link with LLVM, but the necessary paths may be left out. Rustbuild can use the environment to set the LLVM link path for tools -- `LIB` for MSVC toolchains and `LIBRARY_PATH` for everyone else. Fixes #68714.
-
由 Mazdak Farrokhzad 提交于
rustc: keep upvars tupled in {Closure,Generator}Substs. Previously, each closure/generator capture's (aka "upvar") type was tracked as one "synthetic" type parameter in the closure/generator substs, and figuring out where the parent `fn`'s generics end and the synthetics start involved slicing at `tcx.generics_of(def_id).parent_count`. Needing to query `generics_of` limited @davidtwco (who wants to compute some `TypeFlags` differently for parent generics vs upvars, and `TyCtxt` is not available there), which is how I got started on this, but it's also possible that the `generics_of` queries are slowing down `{Closure,Generator}Substs` methods. To give an example, for a `foo::<T, U>::{closure#0}` with captures `x: X` and `y: Y`, substs are: * before this PR: `[T, U, /*kind*/, /*signature*/, X, Y]` * after this PR: `[T, U, /*kind*/, /*signature*/, (X, Y)]` You can see that, with this PR, no matter how many captures, the last 3 entries in the substs (or 5 for a generator) are always the "synthetic" ones, with the last one being the tuple of capture types. r? @nikomatsakis cc @Zoxc
-
由 Mazdak Farrokhzad 提交于
Increase verbosity when suggesting subtle code changes Do not suggest changes that are actually quite small inline, to minimize the likelihood of confusion. Fix #69243.
-
由 Mazdak Farrokhzad 提交于
librustc_codegen_llvm: Replace deprecated API usage
-
由 Mazdak Farrokhzad 提交于
rustc_codegen_llvm: don't generate any type debuginfo for -Cdebuginfo=1. Works towards #69074 by adding more checks for `DebugInfo::Full` in a few places in `rustc_codegen_llvm`, bringing us in line with what `clang -g1` generates (no debuginfo types, nor debuginfo for `static`s). <hr/> My local build's (`debuginfo-level=1`, `debug-assertions=1`) `librustc_driver-*.so` went from just over 1GiB (1019MiB) down to 402MiB. It's still bad, but the `.debug_*` sections themselves (as reported by `objdump`) went from something like 853MiB down to 236MiB, i.e. roughly a 3.6x reduction. <hr/> Sadly, I don't think this is enough to justify *shipping* all of this debuginfo, but now it's more plausible that we could at least *build* with `debuginfo-level=1` *then* strip it. That would give us real backtraces for e.g. ICEs during builds, but I don't know how often that's relevant. We could also look into split DWARF, and maybe have a `rustc-debuginfo` component in `rustup`. There's also the possibility of making it slimmer by omitting parameters to functions, or perhaps some deduplication (I think right now there is no DWARF reuse across CGUs? maybe ThinLTO helps?). r? @michaelwoerister cc @rust-lang/wg-codegen @alexcrichton @Mark-Simulacrum
-