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

async/await #51580

Merged
merged 19 commits into from Jun 23, 2018

Conversation

Projects
None yet
@cramertj
Member

cramertj commented Jun 15, 2018

This PR implements async/await syntax for async fn in Rust 2015 and async closures and async blocks in Rust 2018 (tracking issue: #50547). Limitations: non-move async closures with arguments are currently not supported, nor are async fn with multiple different input lifetimes. These limitations are not fundamental and will be removed in the future, however I'd like to go ahead and get this PR merged so we can start experimenting with this in combination with futures 0.3.

Based on #51414.
cc @petrochenkov for parsing changes.
r? @eddyb

@withoutboats

This comment has been minimized.

Contributor

withoutboats commented Jun 16, 2018

Why are async_await and await_macro separate features?

My inclination would be to try to make the feature gating as pleasant as possible for users; I'd prefer merging both compiler features into async_await and renaming futures_api to just futures, so an end user hopefully just has to add:

#![feature(async_await, futures)]

(assuming they're using a library that handles pinning for them as a part of its execution API).

@petrochenkov petrochenkov self-assigned this Jun 17, 2018

| |
| first lifetime here
|
= help: `async fn` can only accept borrowed values identical lifetimes

This comment has been minimized.

@MajorBreakfast

MajorBreakfast Jun 17, 2018

Contributor

async fn can only accept borrowed values with identical lifetimes (<-- added "with")

@@ -6755,6 +6807,28 @@ impl<'a> Parser<'a> {
maybe_append(attrs, extra_attrs));
return Ok(Some(item));
}
if self.check_keyword(keywords::Async) &&
(self.look_ahead(1, |t| t.is_keyword(keywords::Fn)) ||
self.look_ahead(1, |t| t.is_keyword(keywords::Unsafe)))

This comment has been minimized.

@MajorBreakfast

MajorBreakfast Jun 17, 2018

Contributor

The order a lot of people seemed to agree on in the RFC discussion was different. rust-lang/rfcs#2394 (comment)

"const unsafe async move": unsafe was in front of async back then (of course move doesn't apply here) To me unsafe in front of async seems more "natural" because unsafety should be featured more prominently.

@Nemo157

This comment has been minimized.

Contributor

Nemo157 commented Jun 18, 2018

I notice this is still using TLS for passing the context in to the generated futures. Has resurrecting generator arguments for this been considered? (big reason I want this is to easily support no_std)

@withoutboats

This comment has been minimized.

Contributor

withoutboats commented Jun 18, 2018

@Nemo157 as far as I know, we definitely want to stop using TLS in the long run (before we stabilize anything), and the current use in this PR is a hack to get the next iteration of async/await up and running.

@cramertj

This comment has been minimized.

Member

cramertj commented Jun 18, 2018

@Nemo157 @withoutboats is absolutely correct-- we definitely want to support no-TLS and no-std async/await, but doing that requires more invasive changes to generators. I'd like to first land this version so that we can begin experimenting with 0.3 ASAP.

@cramertj

This comment has been minimized.

Member

cramertj commented Jun 18, 2018

One thing that occurred to me: async move isn't a legal pair of sequential identifiers in edition 2015. We could use this to support async move blocks and closures in 2015, but not their non-move counterparts. This seems potentially useful for experimenting with async/await in 2015 edition code. WDYT? Is this too weird of an edge case?

@withoutboats

This comment has been minimized.

Contributor

withoutboats commented Jun 18, 2018

@cramertj why would we want to experiment on the 2015 edition over the 2018 edition (since both are available on nightly)?

In the final stable version I think I'd like to make things consistent by not support any async and await features on 2015 (so that the story is very simple, instead of having to remember which half of the features are available on 2015). But if its expedient to support some things on 2015 in this iteration, that seems fine.

@cramertj

This comment has been minimized.

Member

cramertj commented Jun 18, 2018

@withoutboats

why would we want to experiment on the 2015 edition over the 2018 edition (since both are available on nightly)?

Because it would allow for specifically testing out async/await without having to change the rest of the project over to the 2018 edition.

@cramertj

This comment has been minimized.

Member

cramertj commented Jun 18, 2018

@withoutboats

Why are async_await and await_macro separate features?

Currently standard library features must be gated separately from language features. This is also why generator_trait and generators are separate. Attempting to join them causes the library feature to be shadowed by the language feature.

@withoutboats

This comment has been minimized.

Contributor

withoutboats commented Jun 18, 2018

@cramertj I didn't see it was literally implemented as a macro. We don't intend to stabilize it with the current syntax anyway, do you object to using the futures_api feature to avoid users having to enumerate so many features to use this?

@cramertj

This comment has been minimized.

Member

cramertj commented Jun 19, 2018

@withoutboats

We don't intend to stabilize it with the current syntax anyway, do you object to using the futures_api feature to avoid users having to enumerate so many features to use this?

Hm... it seems sort of surprising to me that futures_api would be tied to async/await and I could see that potentially causing confusion or problems when it comes time to stabilize, but I agree that it's an unfortunately large number of features. I think my preference would be to leave as-is, but if you strongly disagree I'm happy to change it.

@rust-lang rust-lang deleted a comment from rust-highfive Jun 19, 2018

@rust-highfive

This comment was marked as resolved.

Collaborator

rust-highfive commented Jun 19, 2018

The job x86_64-gnu-llvm-3.9 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.
Check compiletest suite=ui mode=ui (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
[00:42:41] 
[00:42:41] running 1507 tests
[00:42:46] .............................................................................................i......
[00:42:51] .......................................................i............................F...............
[00:42:59] ....................................................................................................
[00:43:02] ....................................................................................................
[00:43:05] ....................................................................................................
[00:43:10] ....................................................................................................
[00:43:10] ....................................................................................................
[00:43:15] ....................................................................................................
[00:43:20] ....................................................................................................
[00:43:26] ....................................................................................................
[00:43:31] ........i...............................................................................i...........
[00:43:36] ....................................................................................................
[00:43:42] ....................................................................................................
[00:43:48] ....................................................................................................
, `type`, `unsafe`, or `}`, found `;`
[00:43:54] + error: expected one of `async`, `const`, `extern`, `fn`, `type`, `unsafe`, or `}`, found `;`
[00:43:54] 42   --> $DIR/issue-40006.rs:23:18
[00:43:54] 43    |
[00:43:54] 44 LL |     Z = { 2 + 3 }; //~ ERROR expected one of
[00:43:54] 
[00:43:54] -    |                  ^ expected one of `const`, `extern`, `fn`, `type`, `unsafe`, or `}` here
[00:43:54] +    |                  ^ expected one of 7 possible tokens here
[00:43:54] 46 
[00:43:54] 47 error: expected one of `!` or `::`, found `(`
[00:43:54] 48   --> $DIR/issue-40006.rs:24:9
[00:43:54] 
[00:43:54] The actual stderr differed from the expected stderr.
[00:43:54] Actual stderr saved to /checkout/obj/build/x86_64-unknown-linux-gnu/test/ui/did_you_mean/issue-40006/issue-40006.stderr
[00:43:54] Actual stderr saved to /checkout/obj/build/x86_64-unknown-linux-gnu/test/ui/did_you_mean/issue-40006/issue-40006.stderr
[00:43:54] To update references, rerun the tests and pass the `--bless` flag
[00:43:54] To only update this specific test, also pass `--test-args did_you_mean/issue-40006.rs`
[00:43:54] error: 1 errors occurred comparing output.
[00:43:54] status: exit code: 101
[00:43:54] status: exit code: 101
[00:43:54] command: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/bin/rustc" "/checkout/src/test/ui/did_you_mean/issue-40006.rs" "--target=x86_64-unknown-linux-gnu" "--error-format" "json" "-Zui-testing" "-C" "prefer-dynamic" "-o" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/ui/did_you_mean/issue-40006/a" "-Crpath" "-O" "-Zunstable-options" "-Lnative=/checkout/obj/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "-L" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/ui/did_you_mean/issue-40006/auxiliary" "-A" "unused"
[00:43:54] ------------------------------------------
[00:43:54] 
[00:43:54] ------------------------------------------
[00:43:54] stderr:
[00:43:54] stderr:
[00:43:54] ------------------------------------------
[00:43:54] {"message":"missing `fn`, `type`, or `const` for impl-item declaration","code":null,"level":"error","spans":[{"file_name":"/checkout/src/test/ui/did_you_mean/issue-40006.rs","byte_start":475,"byte_end":539,"line_start":11,"line_end":13,"column_start":9,"column_end":5,"is_primary":true,"text":[{"text":"impl X { //~ ERROR cannot be made into an object","highlight_start":9,"highlight_end":49},{"text":"//~^ ERROR missing","highlight_start":1,"highlight_end":19},{"text":"    Y","highlight_start":1,"highlight_end":5}],"label":"missing `fn`, `type`, or `const`","suggested_replacement":null,"suggestion_applicability":null,"expansion":null}],"children":[],"rendered":"error: missing `fn`, `type`, or `const` for impl-item declaration\n  --> /checkout/src/test/ui/did_you_mean/issue-40006.rs:11:9\n   |\nLL |   impl X { //~ ERROR cannot be made into an object\n   |  _________^\nLL | | //~^ ERROR missing\nLL | |     Y\n   | |____^ missing `fn`, `type`, or `const`\n\n"}
[00:43:54] {"message":"missing `fn`, `type`, or `const` for trait-item declaration","code":null,"level":"error","spans":[{"file_name":"/checkout/src/test/ui/did_you_mean/issue-40006.rs","byte_start":564,"byte_end":587,"line_start":18,"line_end":19,"column_start":10,"column_end":5,"is_primary":true,"text":[{"text":"trait X { //~ ERROR missing","highlight_start":10,"highlight_end":28},{"text":"    X() {}","highlight_start":1,"highlight_end":5}],"label":"missing `fn`, `type`, or `const`","suggested_replacement":null,"suggestion_applicability":null,"expansion":null}],"children":[],"rendered":"error: missing `fn`, `type`, or `const` for trait-item declaration\n  --> /checkout/src/test/ui/did_you_mean/issue-40006.rs:18:10\n   |\nLL |   trait X { //~ ERROR missing\n   |  __________^\nLL | |     X() {}\n   | |____^ missing `fn`, `type`, or `const`\n\n"}
[00:43:54] {"message":"expected `[`, found `#`","code":null,"level":"error","spans":[{"file_name":"/checkout/src/test/ui/did_you_mean/issue-40006.rs","byte_start":610,"byte_end":611,"line_start":20,"line_end":20,"column_start":17,"column_end":18,"is_primary":true,"text":[{"text":"    fn xxx() { ### } //~ ERROR missing","highlight_start":17,"highlight_end":18}],"label":"expected `[`","suggested_replacement":null,"suggestion_applicability":null,"expansion":null}],"children":[],"rendered":"error: expected `[`, found `#`\n  --> /checkout/src/test/ui/did_you_mean/issue-40006.rs:20:17\n   |\nLL |     fn xxx() { ### } //~ ERROR missing\n   |                 ^ expected `[`\n\n"}
[00:43:54] {"message":"missing `fn`, `type`, or `const` for trait-item declaration","code":null,"level":"error","spans":[{"file_name":"/checkout/src/test/ui/did_you_mean/issue-40006.rs","byte_start":614,"byte_end":661,"line_start":20,"line_end":22,"column_start":21,"column_end":5,"is_primary":true,"text":[{"text":"    fn xxx() { ### } //~ ERROR missing","highlight_start":21,"highlight_end":39},{"text":"    //~^ ERROR expected","highlight_start":1,"highlight_end":24},{"text":"    L = M; //~ ERROR missing","highlight_start":1,"highlight_end":5}],"label":"missing `fn[{"text":"    pub hello_method(&self) { //~ ERROR missing","highlight_start":8,"highlight_end":9}],"label":"missing `fn`, `type`, or `const`","suggested_replacement":null,"suggestion_applicability":null,"expansion":null}],"children":[],"rendered":"error: missing `fn`, `type`, or `const` for impl-item declaration\n  --> /checkout/src/test/ui/did_you_mean/issue-40006.rs:28:8\n   |\nLL |     pub hello_method(&self) { //~ ERROR missing\n   |        ^ missing `fn`, `type`, or `const`\n\n"}
[00:43:54] {"message":"the trait `X` cannot be made into an object","code":{"code":"E0038","explanation":"\nTrait objects like `Box<Trait>` can only be constructed when certain\nrequirements are satisfied by the trait in question.\n\nTrait objects are a form of dynamic dispatch and use a dynamically sized type\nfor the inner type. So, for a given trait `Trait`, when `Trait` is treated as a\ntype, as in `Box<Trait>`, the inner type is 'unsized'. In such cases the boxed\npointer is a 'fat pointer' that contains an extra pointer to a table of methods\n(among other things) for dynamic dispatch. This design mandates some\nrestrictions on the types of traits that are allowed to be used in trait\nobjects, which are collectively termed as 'object safety' rules.\n\nAttempting to create a trait object for a non object-safe trait will trigger\nthis error.\n\nThere are various rules:\n\n### The trait cannot require `Self: Sized`\n\nWhen `Trait` is treated as a type, the type does not implement the special\n`Sized` trait, because the type does not have a known size at compile time and\ncan only be accessed behind a pointer. Thus, if we have a trait like theods. With such a bound, one can still call `foo()` on types implementing\nthat trait that aren't behind trait objects.\n\n### Method has generic type parameters\n\nAs mentioned before, trait objects contain pointers to method tables. So, if we\nhave:\n\n```\ntrait Trait {\n    fn foo(&self);\n}\n\nimpl Trait for String {\n    fn foo(&self) {\n        // implementation 1\n    }\n}\n\nimpl Trait for u8 {\n    fn foo(&self) {\n        // implementation 2\n    }\n}\n// ...\n```\n\nAt compile time each implementation of `Trait` will produce a table containing\nthe various methods (and other items) related to the implementation.\n\nThis works fine, but when the method gains generic parameters, we can have a\nproblem.\n\nUsually, generic parameters get _monomorphized_. For example, if I have\n\n```\nfn foo<T>(x: T) {\n    // ...\n}\n```\n\nThe machine code for `foo::<u8>()`, `foo::<bool>()`, `foo::<String>()`, or any\nother type substitution is different. Hence the compiler generates the\nimplementation on-demand. If you call `foo()` with a `bool` parameter, the\ncompiler will only generate code for `foo::<bool>()`. When we have additional\ntype parameters, the number of monomorphized implementations the compiler\ngenerates does not grow drastically, since the compiler will only generate an\nimplementation if the function is called with unparametrized substitutions\n(i.e., substitutions where none of the substituted types are themselves\nparametrized).\n\nHowever, with trait objects we have to make a table containing _every_ object\nthat implements the trait. Now, if it has type parameters, we need to add\nimplementations for every type that implements the trait, and there could\ntheoretically be an infinite number of types.\n\nFor example, with:\n\n```\ntrait Trait {\n    fn foo<T>(&self, on: T);\n    // more methods\n}\n\nimpl Trait for String {\n    fn foo<T>(&self, on: T) {\n        // implementation 1\n    }\n}\n\nimpl Trait for u8 {\n    fn foo<T>(&self, on: T) {\n        // implementation 2\n    }\n}\n\n// 8 more implementations\n```\n\nNow, if we have the following code:\n\n```compile_fail,E0038\n# trait Trait { fn foo<T>(&self, on: T); }\n# impl Trait for String { fn foo<T>(&self, on: T) {} }\n# impl Trait for u8 { fn foo<T>(&self, on: T) {} }\n# impl Trait for bool { fn foo<T>(&self, on: T) {} }\n# // etc.\nfn call_foo(thing: Box<Trait>) {\n    thing.foo(true); // this could be any one of the 8 types above\n    thing.foo(1);\n    thing.foo(\"hello\");\n}\n```\n\nWe don't just need to create a table of all implementations of all methods of\n`Trait`, we need to create such a table, for each different type fed to\n`foo()`. In this case this turns out to be (10 types implementing `Trait`)*(3\ntypes being fed to `foo()`) = 30 implementations!\n\nWith real world traits these numbers can grow drastically.\n\nTo fix this, it is suggested to use a `where Self: Sized` bound similar to the\nfix for the sub-error above if you do not intend to call the method with type\nparameters:\n\n```\ntrait Trait {\n    fn foo<T>(&self, on: T) where Self: Sized;\n    // more methods\n}\n```\n\nIf this is not an option, consider replacing the type parameter with another\ntrait object (e.g. if `T: OtherTrait`, use `on: Box<OtherTrait>`). If the number\nof types you intend to feed to this method is limited, consider manually listing\nout the methods of different types.\n\n### Method has no receiver\n\nMethods that do not take a `self` parameter can't be called since there won't be\na way to get a pointer to the method table for them.\n\n```\ntrait Foo {\n    fn foo() -> u8;\n}\n```\n\nThis could be called as `<Foo as Foo>::foo()`, which would not be able to pick\nan implementation.\n\nAdding a `Self: Sized` bound to these methods will generally make this compile.\n\n```\ntrait Foo {\n    fn foo() -> u8 where Self: Sized;\n}\n```\n\n### The trait cannot contain associated constants\n\nJust like static functions, associated constants aren't stored on the method\ntable. If the trait or any subtrait contain an associated constant, they cannot\nbe made into an object.\n\n```compile_fail,E0038\ntrait Foo {\n    const X: i32;\n}\n\nimpl Foo {}\n```\n\nA simple workaround is to use a helper method instead:\n\n```\ntrait Foo {\n    fn x(&self) -> i32;\n}\n```\n\n### The trait cannot use `Self` as a type parameter in the supertrait listing\n\nThis is similar to the second sub-error, but subtler. It happens in situations\nlike the following:\n\n```compile_fail\ntrait Super<A> {}\n\ntrait Trait: Super<Self> {\n}\n\nstruct Foo;\n\nimpl Super<Foo> for Foo{}\n\nimpl Trait for Foo {}\n```\n\nHere, the supertrait might have methods as follows:\n\n```\ntrait Super<A> {\n    fn get_a(&self) -> A; // note that this is object safe!\n}\n```\n\nIf the trait `Foo` was deriving from something like `Super<String>` or\n`Super<T>` (where `Foo` itself is `Foo<T>`), this is okay, because given a type\n`get_a()` will defirendered":"For more information about this error, try `rustc --explain E0038`.\n"}
[00:43:54] ------------------------------------------
[00:43:54] 
[00:43:54] thread '[ui] ui/did_you_mean/issue-40006.rs' panicked at 'explicit panic', tools/compiletest/src/runtest.rs:3139:9
[00:43:54] thread 'main' panicked at 'Some tests failed', tools/compiletest/src/main.rs:498:22
[00:43:54] thread 'main' panicked at 'Some tests failed', tools/compiletest/src/main.rs:498:22
[00:43:54] note: Run with `RUST_BACKTRACE=1` for a backtrace.
[00:43:54] 
[00:43:54] ---- [ui] ui/token/issue-41155.rs stdout ----
[00:43:54] diff of stderr:
[00:43:54] 
[00:43:54] - error: expected one of `(`, `const`, `default`, `extern`, `fn`, `type`, or `unsafe`, found `}`
[00:43:54] + error: expected one of `(`, `async`, `const`, `default`, `extern`, `fn`, `type`, or `unsafe`, found `}`
[00:43:54] 2   --> $DIR/issue-41155.rs:13:1
[00:43:54] 3    |
[00:43:54] 4 LL |     pub
[00:43:54] 
[00:43:54] -    |        - expected one of 7 possible tokens here
[00:43:54] +    |        - expected one of 8 possible tokens here
[00:43:54] 6 LL | } //~ ERROR expected one of
[00:43:54] 7    | ^ unexpected token
[00:43:54] 
[00:43:54] 
[00:43:54] The actual stderr differed from the expected stderr.
[00:43:54] Actual stderr saved to /checkout/obj/build/x86_64-unknown-linux-gnu/test/ui/token/issue-41155/issue-41155.stderr
[00:43:54] Actual stderr saved to /checkout/obj/build/x86_64-unknown-linux-gnu/test/ui/token/issue-41155/issue-41155.stderr
[00:43:54] To update references, rerun the tests and pass the `--bless` flag
[00:43:54] To only update this specific test, also pass `--test-args token/issue-41155.rs`
[00:43:54] error: 1 errors occurred comparing output.
[00:43:54] status: exit code: 101
[00:43:54] status: exit code: 101
[00:43:54] command: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/bin/rustc" "/checkout/src/test/ui/token/issue-41155.rs" "--target=x86_64-unknown-linux-gnu" "--error-format" "json" "-Zui-testing" "-C" "prefer-dynamic" "-o" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/ui/token/issue-41155/a" "-Crpath" "-O" "-Zunstable-options" "-Lnative=/checkout/obj/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "-L" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/ui/token/issue-41155/auxiliary" "-A" "unused"
[00:43:54] ------------------------------------------
[00:43:54] 
[00:43:54] ------------------------------------------
[00:43:54] stderr:
[00:43:54] stderr:
[00:43:54] ------------------------------------------
[00:43:54] {"message":"expected one of `(`, `async`, `const`, `default`, `extern`, `fn`, `type`, or `unsafe`, found `}`","code":null,"level":"error","spans":[{"file_name":"/checkout/src/test/ui/token/issue-41155.rs","byte_start":510,"byte_end":510,"line_start":12,"line_end":12,"column_start":8,"column_end":8,"is_primary":false,"text":[{"text":"    pub","highlight_start":8,"highlight_end":8}],"label":"expected one of 8 possible tokens here","suggested_replacement":null,"suggestion_applicability":null,"expansion":null},{"file_name":"/checkout/src/test/ui/token/issue-41155.rs","byte_start":511,"byte_end":512,"line_start":13,"line_end":13,"column_start":1,"column_end":2,"is_primary":true,"text":[{"text":"} //~ ERROR expected one of","highlight_start":1,"highlight_end":2}],"label":"unexpected token","suggested_replacement":null,"suggestion_applicability":null,"expansion":null}],"children":[],"rendered":"error: expected one of `(`, `async`, `const`, `default`, `extern`, `fn`, `type`, or `unsafe`, found `}`\n  --> /checkout/src/test/ui/token/issue-41155.rs:13:1\n   |\nLL |     pub\n   |        - expected one of 8 possible tokens here\nLL | } //~ ERROR expected one of\n   | ^ unexpected token\n\n"}
[00:43:54] {"message":"cannot find type `S` in this scope","code":{"code":"E0412","explanation":"\nThe type name used is not in scope.\n\nErroneous code examples:\n\n```compile_fail,E0412\nimpl Something {} // error: type name `Something` is not in scope\n\n// or:\n\ntrait Foo {\n    fn bar(N); // error: type name `N` is not in scope\n}\n\n// or:\n\nfn foo(x: T) {} // type name `T` is not in scope\n```\n\nTo fix this error, please verify you didn't misspell the type name, you did\ndeclare it or imported it into the scope. Examples:\n\n```\nstruct Something;\n\nimpl Something {} // ok!\n\n// or:\n\ntrait Foo {\n    type N;\n\n    fn bar(_: Self::N); // ok!\n}\n\n// or:\n\nfn foo<T>(x: T) {} // ok!\n```\n\nAnother case that causes this error is when a type is imported into a parent\nmodule. To fix this, you can follow the suggestion and use File directly or\n`use super::File;` which will import the types from the parent namespace. An\nexample that causes this error is below:\n\n```compile_fail,E0412\nuse std::fs::File;\n\nmod foo {\n    fn some_function(f: File) {}\n}\n```\n\n```\nuse std::fs::File;\n\nmod foo {\n    // either\n    use super::File;\n    // or\n    // use std::fs::File;\n    fn foo(f: File) {}\n}\n# fn main() {} // don't insert it for us; that'll break imports\n```\n"},"level":"error","spans":[{"file_name":"/checkout/src/test/ui/token/issue-41155.rs",

The command "stamp sh -x -c "$RUN_SCRIPT"" exited with 2.
travis_time:start:2a369fb2
$ date && (curl -fs --head https://google.com | grep ^Date: | sed 's/Date: //g' || true)

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

@@ -213,6 +213,26 @@ macro_rules! eprintln {
($fmt:expr, $($arg:tt)*) => (eprint!(concat!($fmt, "\n"), $($arg)*));
}
#[macro_export]
#[unstable(feature = "await_macro", issue = "50547")]
#[allow_internal_unstable]

This comment has been minimized.

@petrochenkov

petrochenkov Jun 19, 2018

Contributor

This should probably use #[allow_internal_unsafe] as well.

This comment has been minimized.

@cramertj
@@ -95,6 +95,16 @@ impl<T: 'static> P<T> {
}
}
impl<T: 'static> P<[T]> {
pub fn map_slice<F>(self, f: F) -> P<[T]> where
F: FnOnce(Vec<T>) -> Vec<T>

This comment has been minimized.

@petrochenkov

petrochenkov Jun 19, 2018

Contributor

This looks similar to existing move_map/move_flat_map.

This comment has been minimized.

@cramertj

cramertj Jun 19, 2018

Member

It is similar, but move_map and move_flat_map expect to receive one element at a time, whereas this takes the whole list at once, allowing it to do things like modifying the last element.

This comment has been minimized.

@eddyb

eddyb Jun 22, 2018

Member

Should be able to remove this now.

@@ -2246,6 +2258,15 @@ impl<'a> Parser<'a> {
hi = path.span;
return Ok(self.mk_expr(lo.to(hi), ExprKind::Path(Some(qself), path), attrs));
}
if syntax_pos::hygiene::default_edition() >= Edition::Edition2018 &&

This comment has been minimized.

@petrochenkov

petrochenkov Jun 19, 2018

Contributor

You probably want self.token.span.edition() >= Edition::Edition2018 here instead of default edition in case async comes from a macro defined with other edition.

This comment has been minimized.

@cramertj

cramertj Jun 19, 2018

Member

Do you mean self.span.edition()? Token doesn't have a span field.

This comment has been minimized.

@petrochenkov

petrochenkov Jun 19, 2018

Contributor

Yes, sorry (self.span is the span of self.token).

@@ -3240,6 +3261,13 @@ impl<'a> Parser<'a> {
} else {
Movability::Movable
};
let asyncness = if syntax_pos::hygiene::default_edition() >= Edition::Edition2018

This comment has been minimized.

IsAsync::Async(ast::DUMMY_NODE_ID)
} else {
IsAsync::NotAsync
};

This comment has been minimized.

@petrochenkov

petrochenkov Jun 19, 2018

Contributor

So it's fixed-order static async move |args...| body now.
The number of modifiers becomes closer to the point where nobody can remember the correct order :)

@@ -4274,6 +4320,18 @@ impl<'a> Parser<'a> {
})
}
fn is_async_block(&mut self) -> bool {
self.token.is_keyword(keywords::Async) &&

This comment has been minimized.

@petrochenkov

petrochenkov Jun 19, 2018

Contributor

Nit: This is kind of fragile due to assumption that edition check was already performed and the function is used only once, so it may be better to just inline it.

// `unsafe async fn` or `async fn`
if (
self.check_keyword(keywords::Unsafe) &&
self.look_ahead(1, |t| t.is_keyword(keywords::Async))

This comment has been minimized.

@petrochenkov

petrochenkov Jun 19, 2018

Contributor

Looks like edition checks are missing here and below.

This comment has been minimized.

@cramertj

cramertj Jun 19, 2018

Member

That's intentional-- async fn is supposed to work on edition 2015. It's just closures and blocks that don't.

let is_const_fn = self.eat_keyword(keywords::Const);
let const_span = self.prev_span;
let unsafety = self.parse_unsafety();
let asyncness = self.parse_asyncness();

This comment has been minimized.

@petrochenkov

petrochenkov Jun 19, 2018

Contributor

So the syntax is fixed-order default const unsafe async extern "C" fn foo() {} now.

Fascinating.

There are two groups of things here - stuff inherent to the fn type (unsafe, extern "ABI" and fn itself) and possibly context-dependent "modifiers" (default, const, async).
So far the logic was that modifiers were grouped together on the left, and type-things were grouped together with fn on the right - default const | unsafe extern "C" fn so the modifiers can't get "inside the fn type" type F = unsafe extern "C" fn();.

I think we should turn the syntax into (default const async in arbitrary order) | (unsafe extern "C" in arbitrary order) fn eventually, but for now let's keep it fixed-order while keeping the grouping rule - default const async | unsafe extern "C" fn.

@petrochenkov

This comment has been minimized.

Contributor

petrochenkov commented Jun 19, 2018

Reviewed.
(I skipped the the main desugaring part though.)

@cramertj

This comment has been minimized.

Member

cramertj commented Jun 19, 2018

Thanks @petrochenkov!

@rust-highfive

This comment has been minimized.

Collaborator

rust-highfive commented Jun 19, 2018

The job x86_64-gnu-llvm-3.9 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.
travis_time:start:test_parse-fail
Check compiletest suite=parse-fail mode=parse-fail (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
[00:56:34] 
[00:56:34] running 271 tests
[00:56:36] ...........................i.....................................................FF.................
[00:56:37] ....................................................................i...............................
[00:56:38] ...............i...............F.................F....F.FF.............
[00:56:38] thread 'main' panicked at 'Some tests failed', tools/compiletest/src/main.rs:498:22
[00:56:38] 
[00:56:38] ---- [parse-fail] parse-fail/issue-20711-2.rs stdout ----
[00:56:38] 
[00:56:38] 
[00:56:38] error: /checkout/src/test/parse-fail/issue-20711-2.rs:19: unexpected error: '19:1: 19:2: expected one of `async`, `const`, `crate`, `default`, `extern`, `fn`, `pub`, `type`, or `unsafe`, found `}`'
[00:56:38] 
[00:56:38] error: /checkout/src/test/parse-fail/issue-20711-2.rs:19: expected error not found: expected one of `const`, `crate`, `default`, `extern`, `fn`, `pub`, `type`, or `unsafe`
[00:56:38] 
[00:56:38] error: 1 unexpected errors found, 1 expected errors not found
[00:56:38] status: exit code: 101
[00:56:38] command: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/bin/rustc" "/checkout/src/test/parse-fail/issue-20711-2.rs" "--target=x86_64-unknown-linux-gnu" "--error-format" "json" "-Zui-testing" "-C" "prefer-dynamic" "-o" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/parse-fail/issue-20711-2/a" "-Crpath" "-O" "-Zunstable-options" "-Lnative=/checkout/obj/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "-Z" "parse-only" "-L" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/parse-fail/issue-20711-2/auxiliary"
[00:56:38] unexpected errors (from JSON output): [
[00:56:38]     Error {
[00:56:38]         line_num: 19,
[00:56:38]         kind: Some(
[00:56:38]         ),
[00:56:38]         ),
[00:56:38]         msg: "19:1: 19:2: expected one of `async`, `const`, `crate`, `default`, `extern`, `fn`, `pub`, `type`, or `unsafe`, found `}`"
[00:56:38] ]
[00:56:38] 
[00:56:38] not found errors (from test file): [
[00:56:38]     Error {
[00:56:38]     Error {
[00:56:38]         line_num: 19,
[00:56:38]         kind: Some(
[00:56:38]             Error
[00:56:38]         ),
[00:56:38]         msg: "expected one of `const`, `crate`, `default`, `extern`, `fn`, `pub`, `type`, or `unsafe`"
[00:56:38] ]
[00:56:38] 
[00:56:38] thread '[parse-fail] parse-fail/issue-20711-2.rs' panicked at 'explicit panic', tools/compiletest/src/runtest.rs:1284:13
[00:56:38] note: Run with `RUST_BACKTRACE=1` for a backtrace.
[00:56:38] note: Run with `RUST_BACKTRACE=1` for a backtrace.
[00:56:38] 
[00:56:38] ---- [parse-fail] parse-fail/issue-20711.rs stdout ----
[00:56:38] 
[00:56:38] error: /checkout/src/test/parse-fail/issue-20711.rs:17: unexpected error: '17:1: 17:2: expected one of `async`, `const`, `crate`, `default`, `extern`, `fn`, `pub`, `type`, or `unsafe`, found `}`'
[00:56:38] 
[00:56:38] error: /checkout/src/test/parse-fail/issue-20711.rs:17: expected error not found: expected one of `const`, `crate`, `default`, `extern`, `fn`, `pub`, `type`, or `unsafe`
[00:56:38] 
[00:56:38] error: 1 unexpected errors found, 1 expected errors not found
[00:56:38] status: exit code: 101
[00:56:38] command: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/bin/rustc" "/checkout/src/test/parse-fail/issue-20711.rs" "--target=x86_64-unknown-linux-gnu" "--error-format" "json" "-Zui-testing" "-C" "prefer-dynamic" "-o" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/parse-fail/issue-20711/a" "-Crpath" "-O" "-Zunstable-options" "-Lnative=/checkout/obj/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "-Z" "parse-only" "-L" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/parse-fail/issue-20711/auxiliary"
[00:56:38] unexpected errors (from JSON output): [
[00:56:38]     Error {
[00:56:38]         line_num: 17,
[00:56:38]         kind: Some(
[00:56:38]         ),
[00:56:38]         ),
[00:56:38]         msg: "17:1: 17:2: expected one of `async`, `const`, `crate`, `default`, `extern`, `fn`, `pub`, `type`, or `unsafe`, found `}`"
[00:56:38] ]
[00:56:38] 
[00:56:38] not found errors (from test file): [
[00:56:38]     Error {
[00:56:38]     Error {
[00:56:38]         line_num: 17,
[00:56:38]         kind: Some(
[00:56:38]             Error
[00:56:38]         ),
[00:56:38]         msg: "expected one of `const`, `crate`, `default`, `extern`, `fn`, `pub`, `type`, or `unsafe`"
[00:56:38] ]
[00:56:38] 
[00:56:38] thread '[parse-fail] parse-fail/issue-20711.rs' panicked at 'explicit panic', tools/compiletest/src/runtest.rs:1284:13
[00:56:38] 
[00:56:38] 
[00:56:38] ---- [parse-fail] parse-fail/removed-syntax-static-fn.rs stdout ----
[00:56:38] 
[00:56:38] error: /checkout/src/test/parse-fail/removed-syntax-static-fn.rs:16: unexpected error: '16:5: 16:11: expected one of `async`, `const`, `crate`, `default`, `extern`, `fn`, `pub`, `type`, `unsafe`, or `}`, found `static`'
[00:56:38] 
[00:56:38] error: /checkout/src/test/parse-fail/removed-syntax-static-fn.rs:16: expected error not found: expected one of `const`, `crate`, `default`, `extern`, `fn`, `pub`, `type`, `unsafe`
[00:56:38] 
[00:56:38] error: 1 unexpected errors found, 1 expected errors not found
[00:56:38] status: exit code: 101
[00:56:38] command: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/bin/rustc" "/checkout/src/test/parse-fail/removed-syntax-static-fn.rs" "--target=x86_64-unknown-linux-gnu" "--error-format" "json" "-Zui-testing" "-C" "prefer-dynamic" "-o" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/parse-fail/removed-syntax-static-fn/a" "-Crpath" "-O" "-Zunstable-options" "-Lnative=/checkout/obj/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "-Z" "parse-only" "-L" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/parse-fail/removed-syntax-static-fn/auxiliary"
[00:56:38] unexpected errors (from JSON output): [
[00:56:38]     Error {
[00:56:38]         line_num: 16,
[00:56:38]         kind: Some(
[00:56:38]         ),
[00:56:38]         ),
[00:56:38]         msg: "16:5: 16:11: expected one of `async`, `const`, `crate`, `default`, `extern`, `fn`, `pub`, `type`, `unsafe`, or `}`, found `static`"
[00:56:38] ]
[00:56:38] 
[00:56:38] not found errors (from test file): [
[00:56:38]     Error {
[00:56:38]     Error {
[00:56:38]         line_num: 16,
[00:56:38]         kind: Some(
[00:56:38]             Error
[00:56:38]         ),
[00:56:38]         msg: "expected one of `const`, `crate`, `default`, `extern`, `fn`, `pub`, `type`, `unsafe`"
[00:56:38] ]
[00:56:38] 
[00:56:38] thread '[parse-fail] parse-fail/removed-syntax-static-fn.rs' panicked at 'explicit panic', tools/compiletest/src/runtest.rs:1284:13
[00:56:38] 
[00:56:38] 
[00:56:38] ---- [parse-fail] parse-fail/trait-non-item-macros.rs stdout ----
[00:56:38] 
[00:56:38] error: /checkout/src/test/parse-fail/trait-non-item-macros.rs:12: unexpected error: '12:19: 12:21: expected one of `async`, `const`, `extern`, `fn`, `type`, or `unsafe`, found `2`'
[00:56:38] 
[00:56:38] error: /checkout/src/test/parse-fail/trait-non-item-macros.rs:12: expected error not found: expected one of `const`, `extern`, `fn`, `type`, or `unsafe`, found `2`
[00:56:38] 
[00:56:38] error: 1 unexpected errors found, 1 expected errors not found
[00:56:38] status: exit code: 101
[00:56:38] command: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/bin/rustc" "/checkout/src/test/parse-fail/trait-non-item-macros.rs" "--target=x86_64-unknown-linux-gnu" "--error-format" "json" "-Zui-testing" "-C" "prefer-dynamic" "-o" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/parse-fail/trait-non-item-macros/a" "-Crpath" "-O" "-Zunstable-options" "-Lnative=/checkout/obj/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "-L" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/parse-fail/trait-non-item-macros/auxiliary"
[00:56:38] unexpected errors (from JSON output): [
[00:56:38]     Error {
[00:56:38]         line_num: 12,
[00:56:38]         kind: Some(
[00:56:38]         ),
[00:56:38]         ),
[00:56:38]         msg: "12:19: 12:21: expected one of `async`, `const`, `extern`, `fn`, `type`, or `unsafe`, found `2`"
[00:56:38] ]
[00:56:38] 
[00:56:38] not found errors (from test file): [
[00:56:38]     Error {
[00:56:38]     Error {
[00:56:38]         line_num: 12,
[00:56:38]         kind: Some(
[00:56:38]             Error
[00:56:38]         ),
[00:56:38]         msg: "expected one of `const`, `extern`, `fn`, `type`, or `unsafe`, found `2`"
[00:56:38] ]
[00:56:38] 
[00:56:38] thread '[parse-fail] parse-fail/trait-non-item-macros.rs' panicked at 'explicit panic', tools/compiletest/src/runtest.rs:1284:13
[00:56:38] 
[00:56:38] 
[00:56:38] ---- [parse-fail] parse-fail/trait-pub-assoc-const.rs stdout ----
[00:56:38] 
[00:56:38] error: /checkout/src/test/parse-fail/trait-pub-assoc-const.rs:12: unexpected error: '12:5: 12:8: expected one of `async`, `const`, `extern`, `fn`, `type`, `unsafe`, or `}`, found `pub`'
[00:56:38] 
[00:56:38] error: /checkout/src/test/parse-fail/trait-pub-assoc-const.rs:12: expected error not found: expected one of `const`, `extern`, `fn`, `type`, `unsafe`, or `}`, found `pub`
[00:56:38] 
[00:56:38] error: 1 unexpected errors found, 1 expected errors not found
[00:56:38] status: exit code: 101
[00:56:38] command: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/bin/rustc" "/checkout/src/test/parse-fail/trait-pub-assoc-const.rs" "--target=x86_64-unknown-linux-gnu" "--error-format" "json" "-Zui-testing" "-C" "prefer-dynamic" "-o" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/parse-fail/trait-pub-assoc-const/a" "-Crpath" "-O" "-Zunstable-options" "-Lnative=/checkout/obj/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "-L" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/parse-fail/trait-pub-assoc-const/auxiliary"
[00:56:38] unexpected errors (from JSON output): [
[00:56:38]     Error {
[00:56:38]         line_num: 12,
[00:56:38]         kind: Some(
[00:56:38]         ),
[00:56:38]         ),
[00:56:38]         msg: "12:5: 12:8: expected one of `async`, `const`, `extern`, `fn`, `type`, `unsafe`, or `}`, found `pub`"
[00:56:38] ]
[00:56:38] 
[00:56:38] not found errors (from test file): [
[00:56:38]     Error {
[00:56:38]     Error {
[00:56:38]         line_num: 12,
[00:56:38]         kind: Some(
[00:56:38]             Error
[00:56:38]         ),
[00:56:38]         msg: "expected one of `const`, `extern`, `fn`, `type`, `unsafe`, or `}`, found `pub`"
[00:56:38] ]
[00:56:38] 
[00:56:38] thread '[parse-fail] parse-fail/trait-pub-assoc-const.rs' panicked at 'explicit panic', tools/compiletest/src/runtest.rs:1284:13
[00:56:38] 
[00:56:38] 
[00:56:38] ---- [parse-fail] parse-fail/trait-pub-assoc-ty.rs stdout ----
[00:56:38] 
[00:56:38] error: /checkout/src/test/parse-fail/trait-pub-assoc-ty.rs:12: unexpected error: '12:5: 12:8: expected one of `async`, `const`, `extern`, `fn`, `type`, `unsafe`, or `}`, found `pub`'
[00:56:38] 
[00:56:38] error: /checkout/src/test/parse-fail/trait-pub-assoc-ty.rs:12: expected error not found: expected one of `const`, `extern`, `fn`, `type`, `unsafe`, or `}`, found `pub`
[00:56:38] 
[00:56:38] error: 1 unexpected errors found, 1 expected errors not found
[00:56:38] status: exit code: 101
[00:56:38] command: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/bin/rustc" "/checkout/src/test/parse-fail/trait-pub-assoc-ty.rs" "--target=x86_64-unknown-linux-gnu" "--error-format" "json" "-Zui-testing" "-C" "prefer-dynamic" "-o" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/parse-fail/trait-pub-assoc-ty/a" "-Crpath" "-O" "-Zunstable-options" "-Lnative=/checkout/obj/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "-L" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/parse-fail/trait-pub-assoc-ty/auxiliary"
[00:56:38] unexpected errors (from JSON output): [
[00:56:38]     Error {
[00:56:38]         line_num: 12,
[00:56:38]         kind: Some(
[00:56:38]         ),
[00:56:38]         ),
[00:56:38]         msg: "12:5: 12:8: expected one of `async`, `const`, `extern`, `fn`, `type`, `unsafe`, or `}`, found `pub`"
[00:56:38] ]
[00:56:38] 
[00:56:38] not found errors (from test file): [
[00:56:38]     Error {
[00:56:38]     Error {
[00:56:38]         line_num: 12,
[00:56:38]         kind: Some(
[00:56:38]             Error
[00:56:38]         ),
[00:56:38]         msg: "expected one of `const`, `extern`, `fn`, `type`, `unsafe`, or `}`, found `pub`"
[00:56:38] ]
[00:56:38] 
[00:56:38] thread '[parse-fail] parse-fail/trait-pub-assoc-ty.rs' panicked at 'explicit panic', tools/compiletest/src/runtest.rs:1284:13
[00:56:38] 
[00:56:38] 
[00:56:38] ---- [parse-fail] parse-fail/trait-pub-method.rs stdout ----
[00:56:38] 
[00:56:38] error: /checkout/src/test/parse-fail/trait-pub-method.rs:12: unexpected error: '12:5: 12:8: expected one of `async`, `const`, `extern`, `fn`, `type`, `unsafe`, or `}`, found `pub`'
[00:56:38] 
[00:56:38] error: /checkout/src/test/parse-fail/trait-pub-method.rs:12: expected error not found: expected one of `const`, `extern`, `fn`, `type`, `unsafe`, or `}`, found `pub`
[00:56:38] 
[00:56:38] error: 1 unexpected errors found, 1 expected errors not found
[00:56:38] status: exit code: 101
[00:56:38] command: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/bin/rustc" "/checkout/src/test/parse-fail/trait-pub-method.rs" "--target=x86_64-unknown-linux-gnu" "--error-format" "json" "-Zui-testing" "-C" "prefer-dynamic" "-o" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/parse-fail/trait-pub-method/a" "-Crpath" "-O" "-Zunstable-options" "-Lnative=/checkout/obj/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "-L" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/parse-fail/trait-pub-method/auxiliary"
[00:56:38] unexpected errors (from JSON output): [
[00:56:38]     Error {
[00:56:38]         line_num: 12,
[00:56:38]         kind: Some(
[00:56:38]         ),
[00:56:38]         ),
[00:56:38]         msg: "12:5: 12:8: expected one of `async`, `const`, `extern`, `fn`, `type`, `unsafe`, or `}`, found `pub`"
[00:56:38] ]
[00:56:38] 
[00:56:38] not found errors (from test file): [
[00:56:38]     Error {
[00:56:38]     Error {
[00:56:38]         line_num: 12,
[00:56:38]         kind: Some(
[00:56:38]             Error
[00:56:38]         ),
[00:56:38]         msg: "expected one of `const`, `extern`, `fn`, `type`, `unsafe`, or `}`, found `pub`"
[00:56:38] ]
[00:56:38] 
[00:56:38] thread '[parse-fail] parse-fail/trait-pub-method.rs' panicked at 'explicit panic', tools/compiletest/src/runtest.rs:1284:13
[00:56:38] 
---
[00:56:38] test result: FAILED. 261 passed; 7 failed; 3 ignored; 0 measured; 0 filtered out
[00:56:38] 
[00:56:38] 
[00:56:38] 
[00:56:38] command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-tools-bin/compiletest" "--compile-lib-path" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib" "--run-lib-path" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib" "--rustc-path" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/bin/rustc" "--src-base" "/checkout/src/test/parse-fail" "--build-base" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/parse-fail" "--stage-id" "stage2-x86_64-unknown-linux-gnu" "--mode" "parse-fail" "--target" "x86_64-unknown-linux-gnu" "--host" "x86_64-unknown-linux-gnu" "--llvm-filecheck" "/usr/lib/llvm-3.9/bin/FileCheck" "--host-rustcflags" "-Crpath -O -Zunstable-options " "--target-rustcflags" "-Crpath -O -Zunstable-options  -Lnative=/checkout/obj/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "--docck-python" "/usr/bin/python2.7" "--lldb-python" "/usr/bin/python2.7" "--gdb" "/usr/bin/gdb" "--quiet" "--llvm-version" "3.9.1\n" "--system-llvm" "--cc" "" "--cxx" "" "--cflags" "" "--llvm-components" "" "--llvm-cxxflags" "" "--adb-path" "adb" "--adb-test-dir" "/data/tmp/work" "--android-cross-path" "" "--color" "always"
[00:56:38] 
[00:56:38] 
[00:56:38] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test
[00:56:38] Build completed unsuccessfully in 0:14:27
[00:56:38] Build completed unsuccessfully in 0:14:27
[00:56:38] make: *** [check] Error 1
[00:56:38] Makefile:58: recipe for target 'check' failed

The command "stamp sh -x -c "$RUN_SCRIPT"" exited with 2.
travis_time:start:330a7612
$ date && (curl -fs --head https://google.com | grep ^Date: | sed 's/Date: //g' || true)

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

@rust-highfive

This comment has been minimized.

Collaborator

rust-highfive commented Jun 19, 2018

The job x86_64-gnu-llvm-3.9 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.
    100% |████████████████████████████████| 61kB 6.3MB/s 
Collecting botocore==1.10.41 (from awscli)
/usr/local/lib/python2.7/dist-packages/pip/_vendor/requests/packages/urllib3/util/ssl_.py:122: InsecurePlatformWarning: A true SSLContext object is not available. This prevents urllib3 from configuring SSL appropriately and may cause certain SSL connections to fail. You can upgrade to a newer version of Python to solve this. For more information, see https://urllib3.readthedocs.io/en/latest/security.html#insecureplatformwarning.
  InsecurePlatformWarning
  Downloading https://files.pythonhosted.org/packages/38/37/80162be9e5a50c293ab1646d35d0a4886752df96dbc5a14843733bcaecd0/botocore-1.10.41-py2.py3-none-any.whl (4.3MB)
    0% |                                | 10kB 33.0MB/s eta 0:00:01
    0% |▏                               | 20kB 16.4MB/s eta 0:00:01
    0% |▎                               | 30kB 19.8MB/s eta 0:00:01
    0% |▎                               | 40kB 9.5MB/s eta 0:00:01
---

[00:05:13] travis_fold:start:tidy
travis_time:start:tidy
tidy check
[00:05:13] tidy error: /checkout/src/test/parse-fail/issue-20711-2.rs:19: line longer than 100 chars
[00:05:13] tidy error: /checkout/src/test/parse-fail/issue-20711.rs:17: line longer than 100 chars
[00:05:13] tidy error: /checkout/src/test/parse-fail/trait-pub-assoc-ty.rs:13: line longer than 100 chars
[00:05:13] tidy error: /checkout/src/test/parse-fail/trait-pub-assoc-const.rs:13: line longer than 100 chars
[00:05:13] tidy error: /checkout/src/test/parse-fail/trait-pub-method.rs:13: line longer than 100 chars
[00:05:13] tidy error: /checkout/src/test/parse-fail/removed-syntax-static-fn.rs:18: line longer than 100 chars
[00:05:15] some tidy checks failed
[00:05:15] 
[00:05:15] 
[00:05:15] command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-tools-bin/tidy" "/checkout/src" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "--no-vendor" "--quiet"
[00:05:15] 
[00:05:15] 
[00:05:15] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test src/tools/tidy
[00:05:15] Build completed unsuccessfully in 0:01:55
[00:05:15] Build completed unsuccessfully in 0:01:55
[00:05:15] make: *** [tidy] Error 1
[00:05:15] Makefile:79: recipe for target 'tidy' failed

The command "stamp sh -x -c "$RUN_SCRIPT"" exited with 2.
travis_time:start:0ae32a9c
$ date && (curl -fs --head https://google.com | grep ^Date: | sed 's/Date: //g' || true)
---
travis_time:end:33a0db14:start=1529446569192764490,finish=1529446569199525400,duration=6760910
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:0070dc41
$ head -30 ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers || true
head: cannot open ‘./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers’ for reading: No such file or directory
travis_fold:end:after_failure.4
travis_fold:start:after_failure.5
travis_time:start:0650a45f
$ dmesg | grep -i kill

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

@rust-highfive

This comment has been minimized.

Collaborator

rust-highfive commented Jun 20, 2018

The job x86_64-gnu-llvm-3.9 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.
travis_time:start:test_run-pass-fulldeps
Check compiletest suite=run-pass-fulldeps mode=run-pass (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
[00:57:56] 
[00:57:56] running 94 tests
[00:59:42] ...............................................F................................test [run-pass] run-pass-fulldeps/myriad-closures.rs has been running for over 60 seconds
[01:02:10] failures:
[01:02:10] 
[01:02:10] ---- [run-pass] run-pass-fulldeps/pprust-expr-roundtrip.rs stdout ----
[01:02:10] 
[01:02:10] 
[01:02:10] error: compilation failed!
[01:02:10] status: exit code: 101
[01:02:10] command: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/bin/rustc" "/checkout/src/test/run-pass-fulldeps/pprust-expr-roundtrip.rs" "--target=x86_64-unknown-linux-gnu" "-C" "prefer-dynamic" "-o" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/run-pass-fulldeps/pprust-expr-roundtrip/a" "-Crpath" "-O" "-Zunstable-options" "-Lnative=/checkout/obj/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "-L" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/run-pass-fulldeps/pprust-expr-roundtrip/auxiliary"
[01:02:10] ------------------------------------------
[01:02:10] 
[01:02:10] ------------------------------------------
[01:02:10] stderr:
[01:02:10] stderr:
[01:02:10] ------------------------------------------
[01:02:10] error[E0061]: this function takes 6 parameters but 5 parameters were supplied
[01:02:10]    --> /checkout/src/test/run-pass-fulldeps/pprust-expr-roundtrip.rs:126:25
[01:02:10]     |
[01:02:10] 126 | /                         ExprKind::Closure(CaptureBy::Value,
[01:02:10] 127 | |                                           Movability::Movable,
[01:02:10] 128 | |                                           decl.clone(),
[01:02:10] thread 'main' panicked at 'Some tests failed', tools/compiletest/src/main.rs:498:22
[01:02:10] 129 | |                                           e,
[01:02:10] 130 | |                                           DUMMY_SP)));
[01:02:10] 
[01:02:10] error: aborting due to previous error
[01:02:10] 
[01:02:10] For more information about this error, try `rustc --explain E0061`.
---
[01:02:10] test result: FAILED. 93 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out
[01:02:10] 
[01:02:10] 
[01:02:10] 
[01:02:10] command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-tools-bin/compiletest" "--compile-lib-path" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib" "--run-lib-path" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib" "--rustc-path" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/bin/rustc" "--src-base" "/checkout/src/test/run-pass-fulldeps" "--build-base" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/run-pass-fulldeps" "--stage-id" "stage2-x86_64-unknown-linux-gnu" "--mode" "run-pass" "--target" "x86_64-unknown-linux-gnu" "--host" "x86_64-unknown-linux-gnu" "--llvm-filecheck" "/usr/lib/llvm-3.9/bin/FileCheck" "--host-rustcflags" "-Crpath -O -Zunstable-options " "--target-rustcflags" "-Crpath -O -Zunstable-options  -Lnative=/checkout/obj/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "--docck-python" "/usr/bin/python2.7" "--lldb-python" "/usr/bin/python2.7" "--gdb" "/usr/bin/gdb" "--quiet" "--llvm-version" "3.9.1\n" "--system-llvm" "--cc" "" "--cxx" "" "--cflags" "" "--llvm-components" "" "--llvm-cxxflags" "" "--adb-path" "adb" "--adb-test-dir" "/data/tmp/work" "--android-cross-path" "" "--color" "always"
[01:02:10] 
[01:02:10] 
[01:02:10] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test
[01:02:10] Build completed unsuccessfully in 0:20:11
[01:02:10] Build completed unsuccessfully in 0:20:11
[01:02:10] Makefile:58: recipe for target 'check' failed
[01:02:10] make: *** [check] Error 1

The command "stamp sh -x -c "$RUN_SCRIPT"" exited with 2.
travis_time:start:11975f09
$ date && (curl -fs --head https://google.com | grep ^Date: | sed 's/Date: //g' || true)

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

@GuillaumeGomez

This comment has been minimized.

Member

GuillaumeGomez commented Jun 23, 2018

Is there a reason that the error codes number order got broken once again?

@cramertj

This comment has been minimized.

Member

cramertj commented Jun 23, 2018

@petrochenkov sorry, I misunderstood what you were requesting when I bought read that comment the first time. When I opened the PR it was "async unsafe" but then @MajorBreakfast pointed out that the opposite decision was made on the rfc: #51580 (comment)

I don't have a strong preference here-- I'm happy to change it around again if you think it makes more sense.

@cramertj

This comment has been minimized.

Member

cramertj commented Jun 23, 2018

@GuillaumeGomez I'm not sure what you're asking-- is there a specific policy over the order in which error codes are added now?

@GuillaumeGomez

This comment has been minimized.

Member

GuillaumeGomez commented Jun 23, 2018

There always has been one: you take the current biggest and you add one. Otherwise it's nearly impossible to keep track of what's going on. Anyway, I'll open a PR to fix it...

@cramertj

This comment has been minimized.

Member

cramertj commented Jun 23, 2018

@guillaumegomes I've never done that because it means you have to constantly edit your PR when someone else merges something using the same error codes.

@GuillaumeGomez

This comment has been minimized.

Member

GuillaumeGomez commented Jun 23, 2018

It doesn't happen very often, and in addition to that, it's a very small change. Going from 700 to 900+ is kind of a big step.

@petrochenkov

This comment has been minimized.

Contributor

petrochenkov commented Jun 23, 2018

I've never done that because it means you have to constantly edit your PR when someone else merges something using the same error codes.

+1, that's the reason I don't add errors with codes at all and leave that for separate error-code-assigning PRs

@GuillaumeGomez

This comment has been minimized.

Member

GuillaumeGomez commented Jun 23, 2018

@petrochenkov: That's pretty bad but whatever. If no one cares I'll just stop doing it at some point...

bors added a commit that referenced this pull request Jun 24, 2018

Auto merge of #51740 - GuillaumeGomez:fix-error-code-numbers, r=cramertj
Fix error code numbers

Fixes issue created by #51580.

r? @cramertj

bors added a commit that referenced this pull request Jun 24, 2018

Auto merge of #51740 - GuillaumeGomez:fix-error-code-numbers, r=cramertj
Fix error code numbers

Fixes issue created by #51580.

r? @cramertj
@eddyb

This comment has been minimized.

Member

eddyb commented Jun 24, 2018

@GuillaumeGomez Error codes are a complete disaster IMO and I'd argue we should just remove them and figure out another indexing mechanism. Every single time someone mentions an error by code, I have to ask them to replace the code with something readable.

bors added a commit that referenced this pull request Jun 24, 2018

Auto merge of #51740 - GuillaumeGomez:fix-error-code-numbers, r=cramertj
Fix error code numbers

Fixes issue created by #51580.

r? @cramertj
@blaenk

This comment has been minimized.

Contributor

blaenk commented Jun 24, 2018

Sorry for being off-topic (on the digression into error codes), and I admit that I have no idea about any of this, but has anyone suggested or brought up using some kind of short, descriptive error identifiers (I'll call them "shortcodes") instead of opaque numeric error codes? Something like eslint rules.

Yes, an error code isn't meant to be a self-contained exhaustive explanation of an error, but I find "shortcodes" to be qualitatively better than basic numeric codes. Whenever I see them emitted by eslint, they're much more helpful to me than numeric error codes (emitted by TypeScript for example), they're usually enough for me to remember what the error/mistake pertains to so that I can quickly fix it without having to spend time (even if mere seconds) deciphering the compiler/linter output, but in the unlikely event that that's not the case, then of course I could still look it up since the shortcode is uniquely identifying (for example no-dupe-args).

For example, the error codes from this PR:

E0906, // closures cannot be static
E0725, // multiple different lifetimes used in arguments of `async fn`
E0726, // multiple elided lifetimes used in arguments of `async fn`
E0727, // `async` non-`move` closures with arguments are not currently supported

Might become (first draft, see below):

static-closures,             // closures cannot be static 
async-multi-args,            // multiple different lifetimes used in arguments of `async fn`
async-multi-lifetime-elides, // multiple elided lifetimes used in arguments of `async fn`
async-move-arg-closures,     // `async` non-`move` closures with arguments are not currently supported

Some others might be straightforward:

- E0300,            // unexpanded macro
+ unexpanded-macro, // unexpanded macro

Others maybe trickier:

- E0315,                       // cannot invoke closure outside of its lifetime
+ outlived-closure-invocation, // cannot invoke closure outside of its lifetime

Obviously as a first draft that may not look great. I admit that I don't have a deep enough understanding of the errors in order to name them both precisely and concisely, and I'm sure people can pile on with bikeshedding those particular codes, but the idea is that some convention/standard would evolve around how to abbreviate/shorten certain words, what prefixes/suffixes to use, what words to use to connote/convey different types of errors/mistakes, and so on, such that each code would be somewhat uniform/consistent

There would preferably be no hard limit on the length as that may eventually lead to overly terse error codes due to unforeseen future Rust terminology or overly niche/specific error situations, defeating the point of them in the first place, but obviously there would be a very strong preference toward short and concise while balancing for descriptive, and definitely unique.

Yes, it's unlikely that any one scheme would be perfect, but "shortcodes" may serve more useful and readable than clearly opaque (to end users) numeric error codes, and would at least as one consequence remedy this PR contribution/conflict situation.

I'm not sure how error codes relate to backwards compatibility, or whether this can ever be done going forward, even at the edition level. Maybe the ship has long since sailed on this and it's not feasible to introduce something like this at this point.

bors added a commit that referenced this pull request Jun 24, 2018

Auto merge of #51740 - GuillaumeGomez:fix-error-code-numbers, r=cramertj
Fix error code numbers

Fixes issue created by #51580.

r? @cramertj
@GuillaumeGomez

This comment has been minimized.

Member

GuillaumeGomez commented Jun 24, 2018

@eddyb: I agree on your points but as long as a new (better?) system is put in place, let's just keep to stop destroying the current one, as bad as it might seems. It'll make the migration simpler.

@SimonSapin

This comment has been minimized.

Contributor

SimonSapin commented Jun 24, 2018

This appears to have uncovered a miscompilation bug on old macOS: servo/servo#21089 (comment). I haven’t managed to run lldb so far, but both affected build scripts use Command::new("rustc").

bors added a commit that referenced this pull request Jun 24, 2018

Auto merge of #51740 - GuillaumeGomez:fix-error-code-numbers, r=cramertj
Fix error code numbers

Fixes issue created by #51580.

r? @cramertj

bors added a commit that referenced this pull request Jun 24, 2018

Auto merge of #51740 - GuillaumeGomez:fix-error-code-numbers, r=cramertj
Fix error code numbers

Fixes issue created by #51580.

r? @cramertj
@SimonSapin

This comment has been minimized.

Contributor

SimonSapin commented Jun 24, 2018

I suspect this PR broke println! on macOS 10.10: #51758

@eddyb

This comment has been minimized.

Member

eddyb commented Jun 24, 2018

Something like eslint rules.

FWIW, the direct equivalent is our lint names. I'm not sure we need identifiers at all, although ones that could be name types would be better, since we could use them for structural errors.

flip1995 added a commit to flip1995/rust-clippy that referenced this pull request Jun 25, 2018

Resolve field, struct and function renaming
Addresses the errors produced by (re)moving, merging or renaming
structs, fields and methods by rust-lang/rust#48149 and rust-lang/rust#51580
@chris-morgan

This comment has been minimized.

Member

chris-morgan commented Jun 27, 2018

@blaenk That is indeed very off-topic for this. You should create a new issue if you want further discussion of it. One remark I will make: some tooling is designed around using numbers. Vim’s 'errorformat' looks for error numbers and treats them specially. Very mild damage would be done there if that were changed.

@cramertj cramertj deleted the cramertj:async-await branch Jun 27, 2018

@steveklabnik steveklabnik referenced this pull request Jul 10, 2018

Open

Tracking issue for async/await (RFC 2394) #50547

1 of 10 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment