profile
viewpoint

tmandry/AXSwift 85

Swift wrapper for accessibility clients

tmandry/lavender 36

Generate Visual Studio projects for Bazel (experimental)

tmandry/great-start 2

Great starting point for Rails projects. Includes Mongoid, Devise, RSpec, Spork, Guard, Slim, and Bootstrap.

tmandry/django-fresh 1

Auto-refreshes your browser after updating files in your project in a development environment.

tmandry/adage 0

2D game and AI engine built using Qt/C++ (high school side project)

tmandry/agent 0

The configuration application of the Ultimate Hacking Keyboard

tmandry/alloy 0

Toy OS project in Rust

tmandry/askbot-devel 0

ASKBOT is a StackOverflow-like Q&A forum, based on CNPROG.

tmandry/async-book 0

Asynchronous Programming in Rust

delete branch tmandry/rust

delete branch : force-test-in-process

delete time in a day

Pull request review commentrust-lang/rust

Add more context to E0599 errors

 error[E0599]: no associated item named `ID` found for type `i32` in the current scope   --> $DIR/associated-const-no-item.rs:5:23    |+LL | trait Foo {+   | --------- `Foo` defines an item `ID`, perhaps you need to implement it

It seems like this span should go under the site of the error, not above it

estebank

comment created time in 2 days

Pull request review commentrust-lang/rust

Add more context to E0599 errors

+error[E0599]: no method named `foo` found for reference `&Foo<T>` in the current scope+  --> $DIR/missing-trait-bounds-for-method-call.rs:14:14+   |+LL | struct Foo<T> {+   | ------------- doesn't satisfy `Foo<T>: Bar`+...+LL | trait Bar {+   | --------- `Bar` defines an item `foo`, perhaps you need to implement it+...+LL |         self.foo();+   |              ^^^ method not found in `&Foo<T>`

I think this should go before both the struct and trait above

estebank

comment created time in 2 days

Pull request review commentrust-lang/rust

Add more context to E0599 errors

 error[E0599]: no method named `foo` found for reference `&dyn Foo` in the current scope   --> $DIR/issue-5153.rs:10:27    |+LL |     fn foo(self: Box<Self>);+   |                  --------- the method might not be found because of this arbitrary self type

:100:

estebank

comment created time in 2 days

Pull request review commentrust-lang/rust

Add more context to E0599 errors

 error[E0599]: no method named `clone` found for struct `Bar<NotClone>` in the cu   --> $DIR/derive-assoc-type-not-impl.rs:18:30    | LL | struct Bar<T: Foo> {-   | ------------------ method `clone` not found for this+   | ------------------+   | |+   | method `clone` not found for this+   | doesn't satisfy `Bar<NotClone>: std::clone::Clone`+...+LL | struct NotClone;+   | ---------------- doesn't satisfy `NotClone: std::clone::Clone` ... LL |     Bar::<NotClone> { x: 1 }.clone();    |                              ^^^^^ method not found in `Bar<NotClone>`    |    = note: the method `clone` exists but the following trait bounds were not satisfied:-           `Bar<NotClone> : std::clone::Clone`+           `NotClone: std::clone::Clone` which is required by `Bar<NotClone>: std::clone::Clone`

\o/

estebank

comment created time in 2 days

Pull request review commentrust-lang/rust

Add more context to E0599 errors

-error[E0271]: type mismatch resolving `<std::iter::TakeWhile<&mut std::vec::IntoIter<u8>, [closure@$DIR/issue-31173.rs:6:39: 9:6 found_e:_]> as std::iter::Iterator>::Item == &_`-  --> $DIR/issue-31173.rs:10:10+error[E0271]: type mismatch resolving `<std::iter::TakeWhile<&mut std::vec::IntoIter<u8>, [closure@$DIR/issue-31173.rs:10:39: 13:6 found_e:_]> as std::iter::Iterator>::Item == &_`+  --> $DIR/issue-31173.rs:14:10    | LL |         .cloned()    |          ^^^^^^ expected `u8`, found reference    |    = note:   expected type `u8`            found reference `&_` -error[E0599]: no method named `collect` found for struct `std::iter::Cloned<std::iter::TakeWhile<&mut std::vec::IntoIter<u8>, [closure@$DIR/issue-31173.rs:6:39: 9:6 found_e:_]>>` in the current scope-  --> $DIR/issue-31173.rs:14:10+error[E0599]: no method named `collect` found for struct `std::iter::Cloned<std::iter::TakeWhile<&mut std::vec::IntoIter<u8>, [closure@$DIR/issue-31173.rs:10:39: 13:6 found_e:_]>>` in the current scope+  --> $DIR/issue-31173.rs:18:10    | LL |         .collect();-   |          ^^^^^^^ method not found in `std::iter::Cloned<std::iter::TakeWhile<&mut std::vec::IntoIter<u8>, [closure@$DIR/issue-31173.rs:6:39: 9:6 found_e:_]>>`+   |          ^^^^^^^ method not found in `std::iter::Cloned<std::iter::TakeWhile<&mut std::vec::IntoIter<u8>, [closure@$DIR/issue-31173.rs:10:39: 13:6 found_e:_]>>`+   | +  ::: $SRC_DIR/libcore/iter/adapters/mod.rs:LL:COL+   |+LL | pub struct Cloned<I> {+   | -------------------- doesn't satisfy `_: std::iter::Iterator`+...+LL | pub struct TakeWhile<I, P> {+   | -------------------------- doesn't satisfy `<_ as std::iter::Iterator>::Item = &_`    |    = note: the method `collect` exists but the following trait bounds were not satisfied:-           `&mut std::iter::Cloned<std::iter::TakeWhile<&mut std::vec::IntoIter<u8>, [closure@$DIR/issue-31173.rs:6:39: 9:6 found_e:_]>> : std::iter::Iterator`-           `std::iter::Cloned<std::iter::TakeWhile<&mut std::vec::IntoIter<u8>, [closure@$DIR/issue-31173.rs:6:39: 9:6 found_e:_]>> : std::iter::Iterator`+           `<std::iter::TakeWhile<&mut std::vec::IntoIter<u8>, [closure@$DIR/issue-31173.rs:10:39: 13:6 found_e:_]> as std::iter::Iterator>::Item = &_` which is required by `std::iter::Cloned<std::iter::TakeWhile<&mut std::vec::IntoIter<u8>, [closure@$DIR/issue-31173.rs:10:39: 13:6 found_e:_]>>: std::iter::Iterator`+           `std::iter::Cloned<std::iter::TakeWhile<&mut std::vec::IntoIter<u8>, [closure@$DIR/issue-31173.rs:10:39: 13:6 found_e:_]>>: std::iter::Iterator` which is required by `&mut std::iter::Cloned<std::iter::TakeWhile<&mut std::vec::IntoIter<u8>, [closure@$DIR/issue-31173.rs:10:39: 13:6 found_e:_]>>: std::iter::Iterator`

This is getting unreadable I'm afraid. Maybe we can break up the "cause" and "effect" on separate lines?

On that note, maybe there's a whole chain of causes we could present, as a bulleted or nested list perhaps? (Not saying it we should, but maybe it's worth experimenting with..) You could also experiment with reversing the order (A which requires B), which might be more natural if a list is presented.

estebank

comment created time in 2 days

Pull request review commentrust-lang/rust

Add more context to E0599 errors

 error[E0599]: no method named `clone` found for struct `Bar<NotClone>` in the cu   --> $DIR/derive-assoc-type-not-impl.rs:18:30    | LL | struct Bar<T: Foo> {-   | ------------------ method `clone` not found for this+   | ------------------+   | |+   | method `clone` not found for this+   | doesn't satisfy `Bar<NotClone>: std::clone::Clone`+...+LL | struct NotClone;+   | ---------------- doesn't satisfy `NotClone: std::clone::Clone`

ditto

estebank

comment created time in 2 days

Pull request review commentrust-lang/rust

Use generator resume arguments in the async/await lowering

 symbols! {         target_has_atomic_load_store,         target_thread_local,         task,+        _task_context,

oh, I don't understand why the lint fires when you reference sym::_task_context elsewhere in the code. I was assuming you had it to suppress the lint at first, but didn't need it anymore.

jonas-schievink

comment created time in 3 days

pull request commentrust-lang/rust

Support static linking LLVM with ThinLTO

@bors retry

tmandry

comment created time in 3 days

Pull request review commentrust-lang/rust

Use generator resume arguments in the async/await lowering

  //! Asynchronous values. +#[cfg(not(bootstrap))]+use crate::{+    ops::{Generator, GeneratorState},+    pin::Pin,+    ptr::NonNull,+    task::{Context, Poll},+};+ mod future; #[stable(feature = "futures_api", since = "1.36.0")] pub use self::future::Future;++/// This type is needed because:+///+/// a) Generators cannot implement `for<'a, 'b> Generator<&'a mut Context<'b>>`, so we need to pass+///    a raw pointer.+/// b) Raw pointers and `NonNull` aren't `Send` or `Sync`, so that would make every single future+///    non-Send/Sync as well, and we don't want that.+///+/// It also simplifies the HIR lowering of `.await`.+#[doc(hidden)]+#[unstable(feature = "gen_future", issue = "50547")]+#[cfg(not(bootstrap))]+#[derive(Debug, Copy, Clone)]+pub struct ResumeTy(pub NonNull<Context<'static>>);++#[unstable(feature = "gen_future", issue = "50547")]+#[cfg(not(bootstrap))]+unsafe impl Send for ResumeTy {}++#[unstable(feature = "gen_future", issue = "50547")]+#[cfg(not(bootstrap))]+unsafe impl Sync for ResumeTy {}++/// Wrap a generator in a future.+///+/// This function returns a `GenFuture` underneath, but hides it in `impl Trait` to give+/// better error messages (`impl Future` rather than `GenFuture<[closure.....]>`).+#[doc(hidden)]+#[unstable(feature = "gen_future", issue = "50547")]+#[cfg(not(bootstrap))]+#[inline]+pub fn from_generator<T>(gen: T) -> impl Future<Output = T::Return>+where+    T: Generator<ResumeTy, Yield = ()>+{+    #[derive(Copy, Clone, Debug, Eq, PartialEq, Ord, PartialOrd, Hash)]+    struct GenFuture<T: Generator<ResumeTy, Yield = ()>>(T);++    // We rely on the fact that async/await futures are immovable in order to create+    // self-referential borrows in the underlying generator.+    impl<T: Generator<ResumeTy, Yield = ()>> !Unpin for GenFuture<T> {}++    impl<T: Generator<ResumeTy, Yield = ()>> Future for GenFuture<T> {+        type Output = T::Return;+        fn poll(self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<Self::Output> {+            // Safety: Safe because we're !Unpin + !Drop mapping to a ?Unpin value+            let gen = unsafe { Pin::map_unchecked_mut(self, |s| &mut s.0) };++            // Resume the generator, turning the `&mut Context` into a `NonNull` raw pointer. The+            // `.await` lowering will safely cast that back to a `&mut Context`.+            match gen.resume(ResumeTy(NonNull::from(cx).cast::<Context<'static>>())) {

When the lifetime is erased to 'static here, what prevents the code inside the async fn from using Context::waker() to create a &'static Waker when the Waker doesn't actually have a static lifetime?

e.g. could I do something like this?

async {
    let waker: &'static Waker = futures::future::poll_fn(|cx| cx.waker());
}

if not, how is the original lifetime preserved?

jonas-schievink

comment created time in 8 days

Pull request review commentrust-lang/rust

Use generator resume arguments in the async/await lowering

  //! Asynchronous values. +#[cfg(not(bootstrap))]+use crate::{+    ops::{Generator, GeneratorState},+    pin::Pin,+    ptr::NonNull,+    task::{Context, Poll},+};+ mod future; #[stable(feature = "futures_api", since = "1.36.0")] pub use self::future::Future;++/// This type is needed because:+///+/// a) Generators cannot implement `for<'a, 'b> Generator<&'a mut Context<'b>>`, so we need to pass

Why not? impl<'a, 'b> Generator<&'a mut Context<'b>> for ...

jonas-schievink

comment created time in 3 days

Pull request review commentrust-lang/rust

Use generator resume arguments in the async/await lowering

  //! Asynchronous values. +#[cfg(not(bootstrap))]+use crate::{+    ops::{Generator, GeneratorState},+    pin::Pin,+    ptr::NonNull,+    task::{Context, Poll},+};+ mod future; #[stable(feature = "futures_api", since = "1.36.0")] pub use self::future::Future;++/// This type is needed because:+///+/// a) Generators cannot implement `for<'a, 'b> Generator<&'a mut Context<'b>>`, so we need to pass+///    a raw pointer.+/// b) Raw pointers and `NonNull` aren't `Send` or `Sync`, so that would make every single future+///    non-Send/Sync as well, and we don't want that.+///+/// It also simplifies the HIR lowering of `.await`.+#[doc(hidden)]+#[unstable(feature = "gen_future", issue = "50547")]+#[cfg(not(bootstrap))]+#[derive(Debug, Copy, Clone)]+pub struct ResumeTy(pub NonNull<Context<'static>>);++#[unstable(feature = "gen_future", issue = "50547")]+#[cfg(not(bootstrap))]+unsafe impl Send for ResumeTy {}++#[unstable(feature = "gen_future", issue = "50547")]+#[cfg(not(bootstrap))]+unsafe impl Sync for ResumeTy {}++/// Wrap a generator in a future.+///+/// This function returns a `GenFuture` underneath, but hides it in `impl Trait` to give+/// better error messages (`impl Future` rather than `GenFuture<[closure.....]>`).+#[doc(hidden)]+#[unstable(feature = "gen_future", issue = "50547")]+#[cfg(not(bootstrap))]+#[inline]+pub fn from_generator<T>(gen: T) -> impl Future<Output = T::Return>+where+    T: Generator<ResumeTy, Yield = ()>+{+    #[derive(Copy, Clone, Debug, Eq, PartialEq, Ord, PartialOrd, Hash)]+    struct GenFuture<T: Generator<ResumeTy, Yield = ()>>(T);++    // We rely on the fact that async/await futures are immovable in order to create+    // self-referential borrows in the underlying generator.+    impl<T: Generator<ResumeTy, Yield = ()>> !Unpin for GenFuture<T> {}++    impl<T: Generator<ResumeTy, Yield = ()>> Future for GenFuture<T> {+        type Output = T::Return;+        fn poll(self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<Self::Output> {+            // Safety: Safe because we're !Unpin + !Drop mapping to a ?Unpin value

The mapping to a ?Unpin value tripped me up - it reads like a necessary condition instead of additional context. I think we're !Unpin + !Drop is sufficient.

jonas-schievink

comment created time in 4 days

Pull request review commentrust-lang/rust

Use generator resume arguments in the async/await lowering

 symbols! {         target_has_atomic_load_store,         target_thread_local,         task,+        _task_context,

nit: remove leading underscore

jonas-schievink

comment created time in 8 days

push eventtmandry/dotfiles

Tyler Mandry

commit sha 6607237f6ed72828c03e91cf3942c2ee9c96ff73

,; to go back

view details

push time in 4 days

issue commentrust-lang/rust

Inherent async fn returning `Self` treats type's lifetime parameters as `'static`

Opened #69276 to track the diagnostics improvement separately.

Arnavion

comment created time in 4 days

issue openedrust-lang/rust

Improve error message for "return type cannot contain a projection or `Self`..."

Example (playground):

error: `async fn` return type cannot contain a projection or `Self` that references lifetimes from a parent scope
 --> src/lib.rs:4:33
  |
4 |     async fn new(i: &'a i32) -> Self {
  |                                 ^^^^
  • Add a hint: try spelling out the type instead
  • Add an error code with an entry in the error index explaining that this is a limitation of the compiler, tracked by #61949

created time in 4 days

pull request commentrust-lang/rust

Record lifetime constraints inside generator interior

Ping from triage. @csmoe, what's the status of this PR?

csmoe

comment created time in 5 days

issue commentrust-lang/rust

Inherent async fn returning `Self` treats type's lifetime parameters as `'static`

Hello from triage.. downgrading from Focus since there is no forward-compat issue. We may keep this as OnDeck for now to track the diagnostics improvement.

Arnavion

comment created time in 5 days

PR opened zefei/vim-wintabs

Use custom variable to track session loading state

mkview creates a script which calls doautoall SessionLoadPost without setting g:SessionLoad. When run with loadview, this can cause problems because we are loading and saving to a session at the same time.

Specifically, when running with a NERDTree window, I saw buffers being copied to that window, and some buffers disappearing from other windows.

Fixes #59

+7 -2

0 comment

1 changed file

pr created time in 6 days

create barnchtmandry/vim-wintabs

branch : fix-loadview

created branch time in 6 days

fork tmandry/vim-wintabs

Modern buffer manager for Vim

fork in 6 days

Pull request review commentrust-lang/rust

Support static linking LLVM with ThinLTO

 impl<'a> Builder<'a> {             }         } +        // If we're statically linking in an LLVM compiled for ThinLTO,+        // configure the linker accordingly.+        if Mode::Rustc == mode && self.config.llvm_thin_lto && !self.config.llvm_link_shared {+            if target.contains("msvc") {+                // Here we assume the linker is lld-link.exe.+                rustflags.arg(&format!("-Clink-arg=/opt:lldtojobs={}", self.jobs()));+            } else {+                // Here we assume the linker is clang. If not, there'll be+                // linker errors.+                rustflags.arg("-Clink-arg=-fuse-ld=lld");+                rustflags.arg("-Clink-arg=-flto=thin");++                if self.config.llvm_optimize {+                    rustflags.arg("-Clink-arg=-O3");+                }++                // Make LLD respect the `-j` option.+                rustflags.arg(&format!("-Clink-arg=-Wl,--thinlto-jobs={}", self.jobs()));+            }+        }

@Mark-Simulacrum Do you think anything needs to change here, or is this PR ready to land?

tmandry

comment created time in 8 days

issue commentrust-lang/rust

Add support for splitting linker invocation to a second execution of `rustc`

What is even the benefit of performing codegen and linking on different machines by the way? It doesn't increase parallelism, as the linking has to wait on codegen anyway.

Linking, in theory, depends on a lot more artifacts than codegen does. Codegen should only require source code and the rmeta files from any crates you depend on. Linking requires all of code. In our sccache-like environment, this would mean uploading many rlib files and possibly system libraries to the worker. Network bandwidth becomes a bottleneck. So it's much better to send compile steps to the workers, hitting cache when possible, and do linking locally.

That would require making the linker arguments stable, as changes could break such thing.

Link args don't need to be stable, just the file format which contains them. I don't think the fact that the file contains references to implementation details like compiler-builtins is a problem, actually. As long as those details can change without changing the schema, a well-written tool should be able to consume them without breakage.

That said, stabilizing rlink seems more ambitious than having a rustc option which spits out the final linker line, allowing you to run it yourself.

alexcrichton

comment created time in 8 days

issue commentrust-lang/rust

Add support for splitting linker invocation to a second execution of `rustc`

I don't think we want to stabilize the rlink format anytime soon. It's basically a JSON representation of an internal Rust data structure.

Thin archives or json directives seem like a better bet. Or a distributed cache can scan the output directory for any new files and send them to the client, rsync-style.

alexcrichton

comment created time in 9 days

delete branch tmandry/rust

delete branch : probestack-hidden-2

delete time in 9 days

issue commentrust-lang/rust

Add support for splitting linker invocation to a second execution of `rustc`

@0dvictor and I were discussing how to collect the input files. We decided the easiest way was in fact to archive them, and that we would profile the performance impact in Fuchsia to see if it was a problem.

This approach has the nice property that you know exactly how many output files there will be and what their names are, which makes integrating into existing systems easier. Given that this unblocks using Rust in our distributed build system, it should still be a win for performance.

That said, it sounds from @luser's comment like the overhead might be more than I had originally thought, and we might want support for N output files at some point. We may end up with a solution that supports both archived and non-archived outputs.

Emitting the names in artifact notifications was another possibility that came up. It seems correct to me that they would be emitted, but I haven't thought about it too carefully. We don't use these in our build system today, though we could probably teach it to use them with a bit of effort. Still, it will require more work to handle in our distributed build system, which is why we didn't jump for that option first.

alexcrichton

comment created time in 9 days

pull request commentrust-lang/rust

When expecting `BoxFuture` and using `async {}`, suggest `Box::pin`

@bors r+

estebank

comment created time in 10 days

pull request commentrust-lang/rust

Update compiler-builtins to 0.1.25

Adding beta nomination, see also https://github.com/rust-lang/compiler-builtins/pull/340#issuecomment-584987613

tmandry

comment created time in 10 days

Pull request review commentrust-lang/rust

Support static linking LLVM with ThinLTO

 impl<'a> Builder<'a> {             }         } +        // If we're statically linking in an LLVM compiled for ThinLTO,+        // configure the linker accordingly.+        if Mode::Rustc == mode && self.config.llvm_thin_lto && !self.config.llvm_link_shared {+            if target.contains("msvc") {+                // Here we assume the linker is lld-link.exe.+                rustflags.arg(&format!("-Clink-arg=/opt:lldtojobs={}", self.jobs()));+            } else {+                // Here we assume the linker is clang. If not, there'll be+                // linker errors.+                rustflags.arg("-Clink-arg=-fuse-ld=lld");+                rustflags.arg("-Clink-arg=-flto=thin");++                if self.config.llvm_optimize {+                    rustflags.arg("-Clink-arg=-O3");+                }++                // Make LLD respect the `-j` option.+                rustflags.arg(&format!("-Clink-arg=-Wl,--thinlto-jobs={}", self.jobs()));+            }+        }

Hmm, I didn't realize RUSTFLAGS would apply to those. In that case, the assumptions about which linker is being used will have to hold for both host and target.

I don't think applying ThinLTO to the proc macro builds will break anything, but it might slow things down. lld is pretty agnostic to whether you are giving it bitcode or object files, and tries to do the right thing.

tmandry

comment created time in 10 days

Pull request review commentrust-lang/rust

When expecting `BoxFuture` and using `async {}`, suggest `Box::pin`

 unsafe impl<T: ?Sized> Freeze for &mut T {} /// [`Pin<P>`]: ../pin/struct.Pin.html /// [`pin module`]: ../../std/pin/index.html #[stable(feature = "pin", since = "1.33.0")]+#[rustc_on_unimplemented(+    on(+        _Self = "dyn std::future::Future<Output = i32> + std::marker::Send",

That's fine with me, but I don't really understand why we have to wait for beta.

estebank

comment created time in 10 days

Pull request review commentrust-lang/rust

When expecting `BoxFuture` and using `async {}`, suggest `Box::pin`

+error[E0308]: mismatched types+  --> $DIR/expected-boxed-future-isnt-pinned.rs:11:5+   |+LL | fn foo<F: Future<Output=i32> + Send + 'static>(x: F) -> BoxFuture<'static, i32> {+   |        - this type parameter                            ----------------------- expected `std::pin::Pin<std::boxed::Box<(dyn std::future::Future<Output = i32> + std::marker::Send + 'static)>>` because of return type+LL |     // We could instead use an `async` block, but this way we have no std spans.+LL |     x+   |     ^+   |     |+   |     expected struct `std::pin::Pin`, found type parameter `F`+   |     help: you need to pin and box this expression: `Box::pin(x)`+   |+   = note:      expected struct `std::pin::Pin<std::boxed::Box<(dyn std::future::Future<Output = i32> + std::marker::Send + 'static)>>`+           found type parameter `F`+   = help: type parameters must be constrained to match other types+   = note: for more information, visit https://doc.rust-lang.org/book/ch10-02-traits.html#traits-as-parameters++error[E0308]: mismatched types+  --> $DIR/expected-boxed-future-isnt-pinned.rs:15:5+   |+LL | fn bar<F: Future<Output=i32> + Send + 'static>(x: F) -> BoxFuture<'static, i32> {+   |                                                         ----------------------- expected `std::pin::Pin<std::boxed::Box<(dyn std::future::Future<Output = i32> + std::marker::Send + 'static)>>` because of return type+LL |     Box::new(x)+   |     ^^^^^^^^^^^ expected struct `std::pin::Pin`, found struct `std::boxed::Box`+   |+   = note: expected struct `std::pin::Pin<std::boxed::Box<(dyn std::future::Future<Output = i32> + std::marker::Send + 'static)>>`+              found struct `std::boxed::Box<F>`+   = help: use `Box::pin`++error[E0308]: mismatched types+  --> $DIR/expected-boxed-future-isnt-pinned.rs:19:14+   |+LL | fn baz<F: Future<Output=i32> + Send + 'static>(x: F) -> BoxFuture<'static, i32> {+   |        - this type parameter+LL |     Pin::new(x)+   |              ^+   |              |+   |              expected struct `std::boxed::Box`, found type parameter `F`+   |              help: store this in the heap by calling `Box::new`: `Box::new(x)`

Overall it seems okay for now, it seems less likely that they will start with Pin::new. And if they apply the suggestion they'll eventually be presented with a correct one.

estebank

comment created time in 11 days

Pull request review commentrust-lang/rust

When expecting `BoxFuture` and using `async {}`, suggest `Box::pin`

 impl<'a, 'tcx> FnCtxt<'a, 'tcx> {                 Applicability::MachineApplicable,             );             err.note(-                "for more on the distinction between the stack and the \-                        heap, read https://doc.rust-lang.org/book/ch15-01-box.html, \-                        https://doc.rust-lang.org/rust-by-example/std/box.html, and \-                        https://doc.rust-lang.org/std/boxed/index.html",+                "for more on the distinction between the stack and the heap, read \+                 https://doc.rust-lang.org/book/ch15-01-box.html, \+                 https://doc.rust-lang.org/rust-by-example/std/box.html, and \+                 https://doc.rust-lang.org/std/boxed/index.html",+            );+        }+    }++    /// When encountering an `impl Future` where `BoxFuture` is expected, suggest `Box::pin`.+    fn suggest_calling_boxed_future_when_appropriate(+        &self,+        err: &mut DiagnosticBuilder<'_>,+        expr: &hir::Expr<'_>,+        expected: Ty<'tcx>,+        found: Ty<'tcx>,+    ) {+        // Handle #68197.++        if self.tcx.hir().is_const_context(expr.hir_id) {+            // Do not suggest `Box::new` in const context.+            return;+        }+        let pin_did = self.tcx.lang_items().pin_type();+        match expected.kind {+            ty::Adt(def, _) if Some(def.did) != pin_did => return,+            // This guards the `unwrap` and `mk_box` below.+            _ if pin_did.is_none() || self.tcx.lang_items().owned_box().is_none() => return,+            _ => {}+        }+        let boxed_found = self.tcx.mk_box(found);+        let new_found = self.tcx.mk_lang_item(boxed_found, lang_items::PinTypeLangItem).unwrap();+        if let (true, Ok(snippet)) = (+            self.can_coerce(new_found, expected),+            self.sess().source_map().span_to_snippet(expr.span),+        ) {+            err.span_suggestion(+                expr.span,+                "you need to pin and box this expression",+                format!("Box::pin({})", snippet),

Looks good to me :)

estebank

comment created time in 11 days

Pull request review commentrust-lang/rust

When expecting `BoxFuture` and using `async {}`, suggest `Box::pin`

 unsafe impl<T: ?Sized> Freeze for &mut T {} /// [`Pin<P>`]: ../pin/struct.Pin.html /// [`pin module`]: ../../std/pin/index.html #[stable(feature = "pin", since = "1.33.0")]+#[rustc_on_unimplemented(+    on(+        _Self = "dyn std::future::Future<Output = i32> + std::marker::Send",

I don't think you specifically want i32 here?

estebank

comment created time in 11 days

delete branch tmandry/compiler-builtins

delete branch : probestack-hidden

delete time in 11 days

delete branch tmandry/rust

delete branch : probestack-hidden

delete time in 11 days

PR closed rust-lang/rust

[DO NOT MERGE] Try setting __rust_probestack visibility back to hidden

This is to fix https://github.com/rust-lang/rust/issues/68794, but it may break some platforms. Uploading this change to test in CI.

r? @ghost

+64 -7

8 comments

4 changed files

tmandry

pr closed time in 11 days

pull request commentrust-lang/rust

[DO NOT MERGE] Try setting __rust_probestack visibility back to hidden

Tests were successful, closing this in favor of the "real" change, https://github.com/rust-lang/rust/pull/69086.

tmandry

comment created time in 11 days

PR opened rust-lang/rust

Update compiler-builtins to 0.1.25
  • https://github.com/rust-lang/compiler-builtins/pull/340 Set probestack visibility to hidden on ELF targets

Fixes https://github.com/rust-lang/rust/issues/68794.

Tested in CI: https://github.com/rust-lang/rust/pull/69045.

r? @Mark-Simulacrum

+2 -2

0 comment

1 changed file

pr created time in 11 days

create barnchtmandry/rust

branch : probestack-hidden-2

created branch time in 11 days

issue commentrust-lang/rust

`rls` no longer builds after rust-lang/rust#68907

@Xanewok friendly ping!

rust-highfive

comment created time in 11 days

Pull request review commentrust-lang/rust

When expecting `BoxFuture` and using `async {}`, suggest `Box::pin`

 impl<'a, 'tcx> FnCtxt<'a, 'tcx> {                 Applicability::MachineApplicable,             );             err.note(-                "for more on the distinction between the stack and the \-                        heap, read https://doc.rust-lang.org/book/ch15-01-box.html, \-                        https://doc.rust-lang.org/rust-by-example/std/box.html, and \-                        https://doc.rust-lang.org/std/boxed/index.html",+                "for more on the distinction between the stack and the heap, read \+                 https://doc.rust-lang.org/book/ch15-01-box.html, \+                 https://doc.rust-lang.org/rust-by-example/std/box.html, and \+                 https://doc.rust-lang.org/std/boxed/index.html",+            );+        }+    }++    /// When encountering an `impl Future` where `BoxFuture` is expected, suggest `Box::pin`.+    fn suggest_calling_boxed_future_when_appropriate(+        &self,+        err: &mut DiagnosticBuilder<'_>,+        expr: &hir::Expr<'_>,+        expected: Ty<'tcx>,+        found: Ty<'tcx>,+    ) {+        // Handle #68197.++        if self.tcx.hir().is_const_context(expr.hir_id) {+            // Do not suggest `Box::new` in const context.+            return;+        }+        let pin_did = self.tcx.lang_items().pin_type();+        match expected.kind {+            ty::Adt(def, _) if Some(def.did) != pin_did => return,+            // This guards the `unwrap` and `mk_box` below.+            _ if pin_did.is_none() || self.tcx.lang_items().owned_box().is_none() => return,+            _ => {}+        }+        let boxed_found = self.tcx.mk_box(found);+        let new_found = self.tcx.mk_lang_item(boxed_found, lang_items::PinTypeLangItem).unwrap();+        if let (true, Ok(snippet)) = (+            self.can_coerce(new_found, expected),+            self.sess().source_map().span_to_snippet(expr.span),+        ) {+            err.span_suggestion(+                expr.span,+                "you need to pin and box this expression",+                format!("Box::pin({})", snippet),

I think a significant number of people will proactively write Box::new(..).

I understand that seeing Pin<Box<_>> is an existing problem, but it's not incorrect, and it's not the compiler actively telling you what to do.

With this change, we would be giving advice that is incorrect in a significant (albeit small) number of cases. I'd rather be slightly less helpful, on average, if it means never being wrong. Bad advice from the compiler can lead people to disregard diagnostic hints altogether.

So my suggestion is to point the user to Box::pin with consider using Box::pin, but not actually show them how to use it (unless we know the code sample is correct when we do). The user is free to guess how to use it, and if that fails, look it up the docs. But this avoids the exasperation / despair of "I did exactly what the compiler said and it still doesn't work."

estebank

comment created time in 11 days

issue commentrust-lang/rust

Inherent async fn returning `Self` treats type's lifetime parameters as `'static`

I did some investigating, leaving notes here.

The reason the example above does not emit the new error message is because the compile fails during type collection and never makes it to type checking. This is a bug fixed by https://github.com/rust-lang/rust/pull/68884.

With the above patch applied, we now get the new error message that was introduced by https://github.com/rust-lang/rust/pull/62849. We also get the more confusing error message about inferring appropriate lifetimes (this happens while checking the function body), but I'm not sure if we can avoid that without a lot of effort.

Agreed that the error message could be better. I think we should give this error a hint ("try spelling out the type instead of using Self"), along with an error code / longer description saying that this is a limitation of the compiler.

Arnavion

comment created time in 11 days

PR opened rust-lang/compiler-builtins

Set probestack visibility to hidden on ELF targets

Fix for https://github.com/rust-lang/rust/issues/68794. Tested across a few different platforms in https://github.com/rust-lang/rust/pull/69045, and it looks like it hasn't broken anything.

cc @Mark-Simulacrum

+1 -0

0 comment

1 changed file

pr created time in 11 days

Pull request review commentrust-lang/rust

Support static linking LLVM with ThinLTO

 impl<'a> Builder<'a> {             }         } +        // If we're statically linking in an LLVM compiled for ThinLTO,+        // configure the linker accordingly.+        if Mode::Rustc == mode && self.config.llvm_thin_lto && !self.config.llvm_link_shared {+            if target.contains("msvc") {+                // Here we assume the linker is lld-link.exe.+                rustflags.arg(&format!("-Clink-arg=/opt:lldtojobs={}", self.jobs()));+            } else {+                // Here we assume the linker is clang. If not, there'll be+                // linker errors.+                rustflags.arg("-Clink-arg=-fuse-ld=lld");

done

tmandry

comment created time in 11 days

push eventtmandry/rust

Tyler Mandry

commit sha 7222038f97e0fee9aadbd57dc95a92a39ac67414

Support static linking LLVM with ThinLTO

view details

push time in 11 days

Pull request review commentrust-lang/rust

Support static linking LLVM with ThinLTO

 impl<'a> Builder<'a> {             }         } +        // If we're statically linking in an LLVM compiled for ThinLTO,+        // configure the linker accordingly.+        if Mode::Rustc == mode && self.config.llvm_thin_lto && !self.config.llvm_link_shared {+            if target.contains("msvc") {+                // Here we assume the linker is lld-link.exe.+                rustflags.arg(&format!("-Clink-arg=/opt:lldtojobs={}", self.jobs()));+            } else {+                // Here we assume the linker is clang. If not, there'll be+                // linker errors.+                rustflags.arg("-Clink-arg=-fuse-ld=lld");+                rustflags.arg("-Clink-arg=-flto=thin");++                if self.config.llvm_optimize {+                    rustflags.arg("-Clink-arg=-O3");+                }++                // Make LLD respect the `-j` option.+                rustflags.arg(&format!("-Clink-arg=-Wl,--thinlto-jobs={}", self.jobs()));+            }+        }

Do we have some reference for where these options came from (e.g., are we copying what LLVM does internally today or something like that?)? If so, would be good to note that here (or explicitly say 'these were ad-hoc created').

Most of these options came from the code that was there before #57286, and they didn't have comments beyond what was here.

I'll add a note on the -O3 flag (and apparently LLVM uses -O2 for release-with-debuginfo builds, so I'll replicate that behavior.)

I presume it's fine to pass these to all rustc's as link-args and this won't interfere with incremental compilation and ThinLTO across rust code? It seems a bit odd that would just all work itself out to be honest :)

Yeah, I had to map it out all in my head to get here but it seems to work.

  • We should only be linking one target (librustc) in that cargo invocation.
  • Since (cross-crate) ThinLTO isn't supported in dylibs, it can't interact with that.
  • Crate-only ThinLTO (which is enabled by default for rlibs) shouldn't be affected by linker flags.

Do we set similar options wrt to the jobserver (jobs) from rustc today?

It doesn't look like we do. But these flags were here before #57286, and they seem like a good idea, at least.

Does lld support the jobserver protocol (in that case this is a bit off, and we should instead tell it to hook up to the jobserver, though that's rather hard).

Doesn't look like it.

tmandry

comment created time in 11 days

Pull request review commentrust-lang/rust

When expecting `BoxFuture` and using `async {}`, suggest `Box::pin`

 impl<'a, 'tcx> FnCtxt<'a, 'tcx> {                 Applicability::MachineApplicable,             );             err.note(-                "for more on the distinction between the stack and the \-                        heap, read https://doc.rust-lang.org/book/ch15-01-box.html, \-                        https://doc.rust-lang.org/rust-by-example/std/box.html, and \-                        https://doc.rust-lang.org/std/boxed/index.html",+                "for more on the distinction between the stack and the heap, read \+                 https://doc.rust-lang.org/book/ch15-01-box.html, \+                 https://doc.rust-lang.org/rust-by-example/std/box.html, and \+                 https://doc.rust-lang.org/std/boxed/index.html",+            );+        }+    }++    /// When encountering an `impl Future` where `BoxFuture` is expected, suggest `Box::pin`.+    fn suggest_calling_boxed_future_when_appropriate(+        &self,+        err: &mut DiagnosticBuilder<'_>,+        expr: &hir::Expr<'_>,+        expected: Ty<'tcx>,+        found: Ty<'tcx>,+    ) {+        // Handle #68197.++        if self.tcx.hir().is_const_context(expr.hir_id) {+            // Do not suggest `Box::new` in const context.+            return;+        }+        let pin_did = self.tcx.lang_items().pin_type();+        match expected.kind {+            ty::Adt(def, _) if Some(def.did) != pin_did => return,+            // This guards the `unwrap` and `mk_box` below.+            _ if pin_did.is_none() || self.tcx.lang_items().owned_box().is_none() => return,+            _ => {}+        }+        let boxed_found = self.tcx.mk_box(found);+        let new_found = self.tcx.mk_lang_item(boxed_found, lang_items::PinTypeLangItem).unwrap();+        if let (true, Ok(snippet)) = (+            self.can_coerce(new_found, expected),+            self.sess().source_map().span_to_snippet(expr.span),+        ) {+            err.span_suggestion(+                expr.span,+                "you need to pin and box this expression",+                format!("Box::pin({})", snippet),

Instead of giving a suggestion that can mislead the user, can we only say try using Box::pin()?

context: https://github.com/rust-lang/rust/issues/68197#issuecomment-584964406

estebank

comment created time in 11 days

pull request commentrust-lang/rust

Support static linking LLVM with ThinLTO

Yes, I would prefer that we update the CI builders instead of having a conditional here.

Done.

This PR does not intend to change our CI configuration, right? Just make it possible to have statically linked ThinLTOd LLVM?

Right.

(And our default on CI is shared linked ThinLTO?)

Well, it looks like it's only on dist-x86_64-linux.

tmandry

comment created time in 11 days

push eventtmandry/rust

Tyler Mandry

commit sha 36024f6d3df39b68273417df2e56d33115aca103

Support static linking LLVM with ThinLTO

view details

push time in 11 days

pull request commentrust-lang/rust

Support static linking LLVM with ThinLTO

Instead of the conditional-default behavior, we could just update every builder which sets llvm.thinlto=true to also set llvm.link-shared=true. @Mark-Simulacrum any preference?

tmandry

comment created time in 11 days

PR opened rust-lang/rust

Support static linking LLVM with ThinLTO

As discussed here, we'd like to support static linking LLVM with ThinLTO, even if that isn't what happens on our CI bots. This changes the llvm.link-shared config flag to default to true if llvm.thinlto is enabled, but allows the user to override that default instead of forcing shared linking.

r? @Mark-Simulacrum cc @alexcrichton @petrhosek

+32 -3

0 comment

5 changed files

pr created time in 11 days

push eventtmandry/rust

Tyler Mandry

commit sha fe152009cbf33bc6e2ac59b743478bfbd4fdbe2c

Support static linking LLVM with ThinLTO

view details

push time in 11 days

pull request commentrust-lang/rust

[experiment] Support linking from a .rlink file

@bors r+

0dvictor

comment created time in 11 days

pull request commentrust-lang/rust

[DO NOT MERGE] Try setting __rust_probestack visibility back to hidden

@bors try

tmandry

comment created time in 11 days

push eventtmandry/rust

Tyler Mandry

commit sha ddf7cb82ce0b95c371dda3b44a301555462b44da

pick a few random builders

view details

push time in 11 days

issue openedrust-lang/wg-async-foundations

2020 roadmap

Set priorities and decide how to rank them for 2020, then publish this somewhere.

Relevant links:

created time in 11 days

issue commentrust-lang/wg-async-foundations

New landing page for the group

I'm tempted to keep this simple, and make the repo itself the landing page. A simple pull request to the README is all that's required to update, and we don't have to set up or maintain a different URL.

tmandry

comment created time in 11 days

issue commentrust-lang/wg-async-foundations

Get organized

For now I'm going to experiment with using the two Github projects linked above.

The "triage" project is really only intended for use during meetings, and so we can see what gone done in the last week's meeting.

The "work" project is to track ongoing work, and it gives a better bird's eye view of what's going on than the individual searches, IMO.

tmandry

comment created time in 11 days

push eventrust-lang/wg-async-foundations

Tyler Mandry

commit sha ce87bcde5dc88a0d495afb01d157221b4c045d39

Expand "Getting involved" a bit

view details

push time in 11 days

push eventrust-lang/wg-async-foundations

Tyler Mandry

commit sha b0e04efe62eba5f2c1b4ffa407e240091c7f151c

Triage is hard to spell

view details

push time in 11 days

create barnchrust-lang/wg-async-foundations

branch : master

created branch time in 11 days

issue openedrust-lang/wg-async-foundations

Set up permissions for members

Grant access to this repo and associated projects to the right set of people.

created time in 12 days

issue openedrust-lang/wg-async-foundations

New landing page for the group

Old pages:

  • https://rust-lang.github.io/compiler-team/working-groups/async-await/
  • https://rustasync.github.io/team/async-foundations/

Decide where we are going to host the new page, update it, and point to it from this repo.

created time in 12 days

issue commentrust-lang/cargo

Should build-plans be deleted?

cargo-raze is an interesting tool that works at what I'd consider to be the correct level of abstraction (it is literally built for integrating into another build system).

On Fuchsia we were discussing adapting cargo-raze for our build system (GN) and using that as a template for build plans v2, but we haven't had time to push that forward yet.

alexcrichton

comment created time in 12 days

issue openedrust-lang/wg-async-foundations

Get organized

created time in 12 days

issue commentrust-lang/rust

Dropped variables still included in generator type

The way I read the issue, it is about tracking drops more precisely. (What issues duplicate this?)

We should open a separate issue to track improving the error message.

Nemo157

comment created time in 12 days

issue commentrust-lang/rust

Confusing error message when expecting BoxFuture

marking as OnDeck, since BoxFuture gets used quite often

tmandry

comment created time in 12 days

issue commentrust-lang/rust

E0700 does not point to where the captured lifetime is

Marking as triaged. This issue would benefit from a more minimized example.

Nokel81

comment created time in 12 days

pull request commentrust-lang/rust

[DO NOT MERGE] Try setting __rust_probestack visibility back to hidden

@bors try

tmandry

comment created time in 12 days

PR opened rust-lang/rust

[DO NOT MERGE] Try setting __rust_probestack visibility back to hidden

This is to fix https://github.com/rust-lang/rust/issues/68794, but it may break some platforms. Uploading this change to test in CI.

r? @ghost

+5 -4

0 comment

3 changed files

pr created time in 12 days

create barnchtmandry/rust

branch : probestack-hidden

created branch time in 12 days

create barnchtmandry/compiler-builtins

branch : probestack-hidden

created branch time in 12 days

issue commentrust-lang/rust

TEXTREL in i686 since 1.41.0

As @tmandry suggested, adding .hidden __rust_probestack should fix the problem since the linker will then resolve references to the symbol within the shared library itself.

That's probably the correct fix then, I'm just not 100% sure it will work on all targets . If it fails we should see it in CI, though.

Cogitri

comment created time in 12 days

push eventtmandry/rust

Tyler Mandry

commit sha 7200ae5073976e5ec45e6a45b62683e60fe08cf4

Support static linking LLVM with ThinLTO

view details

push time in 12 days

create barnchtmandry/rust

branch : llvm-static-with-lto

created branch time in 12 days

pull request commentrust-lang/rust

[experiment] Support linking from a .rlink file

Trying again

@bors delegate=@0dvictor

0dvictor

comment created time in 13 days

pull request commentrust-lang/rust

[experiment] Support linking from a .rlink file

@bors delegate=0dvictor r=tmandry after adding the FIXME

0dvictor

comment created time in 13 days

Pull request review commentrust-lang/rust

[experiment] Support linking from a .rlink file

 fn show_content_with_pager(content: &String) { }  impl RustcDefaultCalls {+    fn process_rlink(sess: &Session, compiler: &interface::Compiler) -> Result<(), ErrorReported> {+        if let Input::File(file) = compiler.input() {+            let attrs = vec![];+            sess.crate_types.set(collect_crate_types(sess, &attrs));

@0dvictor can you add a FIXME here to address this in the future?

0dvictor

comment created time in 13 days

Pull request review commentrust-lang/rust

[experiment] Support linking from a .rlink file

 fn show_content_with_pager(content: &String) { }  impl RustcDefaultCalls {+    fn process_rlink(sess: &Session, compiler: &interface::Compiler) -> Result<(), ErrorReported> {+        if let Input::File(file) = compiler.input() {+            let attrs = vec![];+            sess.crate_types.set(collect_crate_types(sess, &attrs));+            let outputs = compiler.build_output_filenames(&sess, &attrs);

ditto

0dvictor

comment created time in 13 days

delete branch tmandry/rust

delete branch : panic-abort-nocapture

delete time in 13 days

issue commentrust-lang/rust

Tests in panic=abort can hang if test spawns a subprocess

IMO, the ideal semantics in this case would be for a test's subprocesses to automatically die when the test exits, but that's different from the semantics of std::process::Child. Changing semantics only in test mode is generally a bad idea.

Failing that, we should avoid hanging and/or give a more helpful error message when this situation arises.

Not hanging can be a pain to implement on unix: we'd have to continue reading from all stdio handles, to avoid deadlock, but also watching for the process to exit without the handles being closed. That means installing a signal handler for SIGCHLD. On Fuchsia it is easier, but we couldn't share the implementation with unix. For Windows, I'm not sure.

Finally, it isn't clear whether this is the "correct" behavior for wait_with_output, or whether that can be changed. We might need to introduce a new method, perhaps in libstd behind a feature flag.

tmandry

comment created time in 16 days

issue openedrust-lang/rust

Tests in panic=abort can hang if test spawns a subprocess

If a test (running in a subprocess, because panic=abort) spawns a sub-subprocess which inherits its stdout or stderr handles, and the sub-subprocess does not exit when the test does, the test framework will hang. This is because wait_with_output waits for all stdio handles to be closed.

Some tests spawn subprocesses, and it can be hard (particularly with panic=abort) to ensure that they are all cleaned up when the test succeeds or fails. In these cases, it would be best not to hang. Hanging is unexpected, and hard to debug.

created time in 16 days

issue commentrust-lang/rust

TEXTREL in i686 since 1.41.0

It could be. Likely the difference is in the attributes of the probestack function (before that change it was a #[naked] rust function, afterward it was defined in raw assembly).

@brianlock could you try adding the line .hidden __rust_probestack around here?

If that fixes it, it may break it in other environments (e.g. when generating code for a shared vs static library). We'd probably need to thread some new cfg flags through, but I'm not sure if that's actually possible.

The other way is going back to defining the assembly in a naked function, but a bug, probably in rustc, prevented me from doing this the first time.

cc @alexcrichton

Cogitri

comment created time in 16 days

PR opened rust-lang/rust

Respect --nocapture in panic=abort test mode

r? @alexcrichton

+88 -9

0 comment

4 changed files

pr created time in 16 days

create barnchtmandry/rust

branch : panic-abort-nocapture

created branch time in 16 days

create barnchtmandry/rust

branch : generator-captures

created branch time in 17 days

issue commentdtolnay/async-trait

Macro expansion error inside #[async_trait] item points to wrong span

Thanks for fixing this so quickly!

tmandry

comment created time in 17 days

pull request commentrust-lang/rust

Re-land "add IntoFuture trait and support for await"

@Arnavion Thanks for pointing to that, I'd indeed forgotten about the type length limit problem. I'm not quite sure what to do about it. We discussed this during the original PR (around here) and thought we had a fix for it in https://github.com/rust-lang/rust/pull/65743, but that seems to have only been a partial fix. cc @eddyb

The perf run seems to be done; results are not great for async benchmarks, but not a total disaster either. (This is far better than the original regression which led us to revert the change.) While it might be possible to land the change with this regression, I'd prefer to dig into it some more first.

So, in summary, I think we need a fix to #67757, and to dig into the remaining performance regression. If anyone wants to take on either of these (or both), please feel free!

tmandry

comment created time in 18 days

issue commentrust-lang/rust

Confusing/incorrect error message with incoherent implementations and async blocks

We hit an instance of this in Fuchsia. Minimal example: (playground)

mod queue {
    pub trait TryMerge {}
    
    impl TryMerge for () {}
    
    pub fn work_queue<W, C, WF>(work_fn: W)
    where
        W: Fn(C) -> WF,
        C: TryMerge,
    {}
}

impl queue::TryMerge for () {}

fn main() {
    queue::work_queue(move |_: ()| {
        async {}
    })
}

Gives

error[E0283]: type annotations needed for `()`

instead of the expected error, which is what you get if you remove the async block:

error[E0119]: conflicting implementations of trait `queue::TryMerge` for type `()`
syntacticsugarglider

comment created time in 19 days

pull request commentrust-lang/rust

Split `join_codegen_and_link()` into two steps

@bors r+

0dvictor

comment created time in 19 days

issue openeddtolnay/async-trait

Macro expansion error inside #[async_trait] item points to wrong span

The following code:

use async_trait::async_trait;

macro_rules! picky {
    { stuff: { $contents:expr } } => { println!("stuff: {}", $contents); }
}

#[async_trait]
trait Foo {
    async fn foo() -> i32;
}

struct Bar;

#[async_trait]
impl Foo for Bar {
    async fn foo() -> i32 {
        picky!({ 123 });
        42
    }
}

emits the following error:

error: no rules expected the token `{`
  --> src/main.rs:16:1
   |
5  | macro_rules! picky {
   | ------------------ when calling this macro
...
16 | #[async_trait]
   | ^^^^^^^^^^^^^^ no rules expected this token in macro call

Can you spot the problem? We forgot stuff: inside picky!(). However, the "no rules expected this token" note points to #[async_trait] instead of the unexpected { token.

When I make the async fn's non-async (leaving #[async_trait]), the error message looks correct. I also can't reproduce using normal macros, so I suspect the issue is with async-trait.

created time in 19 days

pull request commentrust-lang/rust

Split `join_codegen_and_link()` into two steps

@bors r+

0dvictor

comment created time in 19 days

pull request commentrust-lang/rust

Re-land "add IntoFuture trait and support for await"

@bors try @rust-timer queue

tmandry

comment created time in 20 days

PR opened rust-lang/rust

Re-land "add IntoFuture trait and support for await"

Testing the code from #65244 to see if the performance regressions are still there. #68606 and #68672 made perf optimizations that might interact with this change.

If this lands, fixes #67982.

cc @seanmonstar @jonas-schievink r? @cramertj

+123 -13

0 comment

12 changed files

pr created time in 20 days

create barnchtmandry/rust

branch : back-to-intofuture

created branch time in 20 days

issue openedzefei/vim-wintabs

:mkview followed by :loadview makes a buffer tab disappear

If I have multiple buffer tabs open, sometimes :mkview followed by :loadview makes one (not the current one) disappear.

created time in 20 days

Pull request review commentrust-lang/rust

Split `join_codegen_and_link()` into two steps

 impl<'tcx> Queries<'tcx> {     }      pub fn linker(&'tcx self) -> Result<Linker> {-        let dep_graph = self.dep_graph()?;-        let prepare_outputs = self.prepare_outputs()?;-        let ongoing_codegen = self.ongoing_codegen()?;+        let dep_graph = self.dep_graph()?.peek().clone();+        let ongoing_codegen = self.ongoing_codegen()?.take();+        let prepare_outputs = self.prepare_outputs()?.take();          let sess = self.session().clone();         let codegen_backend = self.codegen_backend().clone(); -        Ok(Linker {-            sess,-            dep_graph: dep_graph.peek().clone(),-            prepare_outputs: prepare_outputs.take(),-            ongoing_codegen: ongoing_codegen.take(),-            codegen_backend,-        })+        let codegen_results = codegen_backend.join_codegen(ongoing_codegen, &sess, &dep_graph)?;

This is introducing a stall inside what looks kind of like an accessor, when there wasn't one before. I think there should be a comment on the function, at least. Also, double check that this doesn't seem like a problem at any call sites.

0dvictor

comment created time in a month

issue commentrust-lang/rust

Unsized locals and async ICE

Visiting from async/await triage. Not making this a priority at the moment because it depends on an unstable feature.

DutchGhost

comment created time in a month

delete branch tmandry/rust

delete branch : rollup-7d4y3nk

delete time in a month

Pull request review commentrust-lang/rust

Generator Resume Arguments

 where                     }                 } +                // Move the resume argument to the destination place of the `Yield` terminator+                let resume_arg = Local::new(2); // 0 = return, 1 = self+                statements.push(Statement {+                    source_info,+                    kind: StatementKind::Assign(box (+                        point.resume_arg,+                        Rvalue::Use(Operand::Move(resume_arg.into())),+                    )),+                });

This shouldn't happen for drop cases.

jonas-schievink

comment created time in a month

more