Move Generics from MethodSig to TraitItem and ImplItem #44766

sunjay · Sep 22, 2017

As part of rust-impl-period/WG-compiler-traits, we want to "lift" Generics from MethodSig into TraitItem and ImplItem. This is in preparation for adding associated type generics. (#44265 (comment))

Currently this change is only made in the AST. In the future, it may also impact the HIR. (Still discussing)

To understand this PR, it's probably best to start from the changes to ast.rs and then work your way to the other files to understand the far reaching effects of this change.

r? @nikomatsakis

rust-highfive · Sep 22, 2017

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @nikomatsakis (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

sunjay · Sep 22, 2017

sunjay reviewed Sep 22, 2017

View changes

sunjay · Sep 22, 2017

src/librustc/hir/lowering.rs

@@ -1544,15 +1544,15 @@ impl<'a> LoweringContext<'a> {
                    }
                    TraitItemKind::Method(ref sig, None) => {
                        let names = this.lower_fn_args_to_names(&sig.decl);
-                        hir::TraitItemKind::Method(this.lower_method_sig(sig),
+                        hir::TraitItemKind::Method(this.lower_method_sig(&i.generics, sig),


We should consider updating the HIR to match AST if that is desireable. I have made everything fit for now, but there is now an incongruencey between the structure of the HIR and AST. That's what forced me to add this extra paramater for generics all throughout the code.

I think we will want to update the HIR. I had originally thought we might do that in a separate PR, but I'm not opposed to doing it in the same PR either. It should though be possible to get this code to work without doing it, might be easier for testing and things to start that way (then maybe do the HIR change in a follow-up commit).

I think it'll be easier to the the HIR in a follow-up PR. I'll get started on that as soon as this is ready to be merged.

sunjay · Sep 22, 2017

sunjay reviewed Sep 22, 2017

View changes

sunjay · Sep 22, 2017

src/librustc_resolve/lib.rs

@@ -708,7 +708,6 @@ impl<'a, 'tcx> Visitor<'tcx> for Resolver<'a> {
                ItemRibKind
            }
            FnKind::Method(_, sig, _, _) => {
-                self.visit_generics(&sig.generics);


I'm worried about whether this change has any side-effects we don't want. I don't think I found a place to add this back in after I deleted it.

Indeed, we will need to add this back somewhere =) I think the problem is that the FnKind enum has to change. Methods should operate more analogously with ItemFn -- so we should add a &'a Generics to the Method variant, and then when we construct FnKind::Method (here and here) we can add the data from the trait or impl item respectively. Then we can restore the call to visit_generics that occurs here, I suppose.

This was wrong.

Well, let me read a bit more into this actually. I think what I said is not wrong but a few more tweaks are likely needed.

Yeah, so I think it's fine to remove the call here -- it is being moved into the walk_trait_item and walk_impl_item code, effectively.

Is this change really okay? If ItemFn visits generics, shouldn't Method visit them too?

Nope. It happens as part of visit_trait_item or visit_impl_item, I think.

sunjay · Sep 22, 2017

sunjay reviewed Sep 22, 2017

View changes

sunjay · Sep 22, 2017

src/librustc_resolve/lib.rs

@@ -2056,6 +2056,7 @@ impl<'a> Resolver<'a> {
                        this.with_current_self_type(self_type, |this| {
                            for impl_item in impl_items {
                                this.check_proc_macro_attrs(&impl_item.attrs);
+                                this.visit_generics(&impl_item.generics);


Does this change have any unintended side-effects?

@sunjay
You have to visit generics inside of with_type_parameter_rib here and for trait items.
This was done previously for methods in this piece of code below:

this.with_type_parameter_rib(type_parameters, |this| { visit::walk_impl_item(this, impl_item); // We visited method signature, `FnKind::Method` and its generics here previously });

Yes, this change is not quite right. =)

The way that resolve works, it has these "ribs" that are in scope, those are the sets of names that can be used. When you visit the generics, you are then resolving the names that appear within. So when you visit the generics here, we are visiting without any names in scope.

What we want to do then is to move up the code that is specific to methods below, and execute it for all impl-items:

let type_parameters = HasTypeParameters(&impl_item.generics, MethodRibKind(!sig.decl.has_self())); this.with_type_parameter_rib(type_parameters, |this| {...}

in that case, we can visit_generics here, and you can .. probably forget what I said about modifying FnKind::Method above.

Actually, I don't think we want to call visit_generics here. It will happen as part of the walk_impl_item that we see below.

@nikomatsakis I don't think I can actually move the HasTypeParameters code above because it uses sig which is only in scope for methods. After this refactoring, I may have to come back and add HasTypeParameters for TraitItemKind::Type in this match statement.

sunjay · Sep 22, 2017

sunjay reviewed Sep 22, 2017

View changes

sunjay · Sep 22, 2017

src/libsyntax/parse/parser.rs

            let TyParam {ident, bounds, default, ..} = self.parse_ty_param(vec![])?;
            self.expect(&token::Semi)?;
-            (ident, TraitItemKind::Type(bounds, default))
+            (ident, TraitItemKind::Type(bounds, default), ast::Generics::default())


Is using ::default() the right thing to do here?

uh... I'm not sure. =) I wasn't aware that it implemented default. But it's probably right.

sunjay · Sep 22, 2017

sunjay reviewed Sep 22, 2017

View changes

sunjay · Sep 22, 2017

src/libsyntax/parse/parser.rs

@@ -4919,7 +4920,8 @@ impl<'a> Parser<'a> {

    /// Parse a method or a macro invocation in a trait impl.
    fn parse_impl_method(&mut self, vis: &Visibility, at_end: &mut bool)
-                         -> PResult<'a, (Ident, Vec<ast::Attribute>, ast::ImplItemKind)> {
+                         -> PResult<'a, (Ident, Vec<ast::Attribute>, ast::Generics,
+                             ast::ImplItemKind)> {


I had to make this return type even larger since Generics is outside MethodSig now. There was a lot of code relying on that structure.

yep that is expected

sunjay · Sep 22, 2017

sunjay reviewed Sep 22, 2017

View changes

sunjay · Sep 22, 2017

src/libsyntax/visit.rs

@@ -558,13 +557,13 @@ pub fn walk_fn<'a, V>(visitor: &mut V, kind: FnKind<'a>, declaration: &'a FnDecl
 pub fn walk_trait_item<'a, V: Visitor<'a>>(visitor: &mut V, trait_item: &'a TraitItem) {
    visitor.visit_ident(trait_item.span, trait_item.ident);
    walk_list!(visitor, visit_attribute, &trait_item.attrs);
+    visitor.visit_generics(&trait_item.generics);


I had to guess here and some other places that this was the right place to add this code. Would be great if you could check.

this seems correct, yes.

sunjay · Sep 22, 2017

@nikomatsakis I am currently experiencing a compiler panic when I try to compile this. Given that I am only compiling the compiler and not actually running it, I don't understand where I could have introduced the bug. I would love to know what's going on and would appreciate it if you could give me an idea of how to troubleshoot. The error message I'm receiving is below. Once this is fixed I would like to run the tests and fix any other errors that are found before this gets merged.

$ RUST_BACKTRACE=1 ./x.py build
Updating submodules
    Finished dev [unoptimized] target(s) in 0.0 secs
Building stage0 std artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
    Finished release [optimized] target(s) in 0.0 secs
Copying stage0 std from stage0 (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu / x86_64-unknown-linux-gnu)
Building stage0 test artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
    Finished release [optimized] target(s) in 0.0 secs
Copying stage0 test from stage0 (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu / x86_64-unknown-linux-gnu)
Building stage0 compiler artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
   Compiling syntax v0.0.0 (file:///home/sunjay/Documents/projects/rust/src/libsyntax)
   Compiling rustc_const_math v0.0.0 (file:///home/sunjay/Documents/projects/rust/src/librustc_const_math)
   Compiling proc_macro v0.0.0 (file:///home/sunjay/Documents/projects/rust/src/libproc_macro)
   Compiling rustc_back v0.0.0 (file:///home/sunjay/Documents/projects/rust/src/librustc_back)
   Compiling syntax_ext v0.0.0 (file:///home/sunjay/Documents/projects/rust/src/libsyntax_ext)
   Compiling rustc v0.0.0 (file:///home/sunjay/Documents/projects/rust/src/librustc)
   Compiling rustc_allocator v0.0.0 (file:///home/sunjay/Documents/projects/rust/src/librustc_allocator)
   Compiling rustc_incremental v0.0.0 (file:///home/sunjay/Documents/projects/rust/src/librustc_incremental)
   Compiling rustc_const_eval v0.0.0 (file:///home/sunjay/Documents/projects/rust/src/librustc_const_eval)
   Compiling rustc_resolve v0.0.0 (file:///home/sunjay/Documents/projects/rust/src/librustc_resolve)
   Compiling rustc_metadata v0.0.0 (file:///home/sunjay/Documents/projects/rust/src/librustc_metadata)
   Compiling rustc_trans_utils v0.0.0 (file:///home/sunjay/Documents/projects/rust/src/librustc_trans_utils)
   Compiling rustc_typeck v0.0.0 (file:///home/sunjay/Documents/projects/rust/src/librustc_typeck)
   Compiling rustc_privacy v0.0.0 (file:///home/sunjay/Documents/projects/rust/src/librustc_privacy)
   Compiling rustc_passes v0.0.0 (file:///home/sunjay/Documents/projects/rust/src/librustc_passes)
   Compiling rustc_mir v0.0.0 (file:///home/sunjay/Documents/projects/rust/src/librustc_mir)
   Compiling rustc_lint v0.0.0 (file:///home/sunjay/Documents/projects/rust/src/librustc_lint)
   Compiling rustc_trans v0.0.0 (file:///home/sunjay/Documents/projects/rust/src/librustc_trans)
   Compiling rustc_save_analysis v0.0.0 (file:///home/sunjay/Documents/projects/rust/src/librustc_save_analysis)
   Compiling rustc_borrowck v0.0.0 (file:///home/sunjay/Documents/projects/rust/src/librustc_borrowck)
   Compiling rustc_plugin v0.0.0 (file:///home/sunjay/Documents/projects/rust/src/librustc_plugin)
   Compiling rustc_driver v0.0.0 (file:///home/sunjay/Documents/projects/rust/src/librustc_driver)
   Compiling rustc-main v0.0.0 (file:///home/sunjay/Documents/projects/rust/src/rustc)
    Finished release [optimized] target(s) in 718.57 secs
Copying stage0 rustc from stage0 (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu / x86_64-unknown-linux-gnu)
Assembling stage1 compiler (x86_64-unknown-linux-gnu)
Building stage1 std artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
   Compiling core v0.0.0 (file:///home/sunjay/Documents/projects/rust/src/libcore)
   Compiling unwind v0.0.0 (file:///home/sunjay/Documents/projects/rust/src/libunwind)
   Compiling libc v0.0.0 (file:///home/sunjay/Documents/projects/rust/src/rustc/libc_shim)
   Compiling compiler_builtins v0.0.0 (file:///home/sunjay/Documents/projects/rust/src/rustc/compiler_builtins_shim)
   Compiling rustc_tsan v0.0.0 (file:///home/sunjay/Documents/projects/rust/src/librustc_tsan)
   Compiling rustc_lsan v0.0.0 (file:///home/sunjay/Documents/projects/rust/src/librustc_lsan)
   Compiling rustc_asan v0.0.0 (file:///home/sunjay/Documents/projects/rust/src/librustc_asan)
   Compiling rustc_msan v0.0.0 (file:///home/sunjay/Documents/projects/rust/src/librustc_msan)
   Compiling alloc_jemalloc v0.0.0 (file:///home/sunjay/Documents/projects/rust/src/liballoc_jemalloc)
   Compiling std v0.0.0 (file:///home/sunjay/Documents/projects/rust/src/libstd)
error: internal compiler error: unexpected panic

note: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports

note: rustc 1.22.0-dev running on x86_64-unknown-linux-gnu

note: run with `RUST_BACKTRACE=1` for a backtrace

thread 'rustc' panicked at 'path resolved multiple times (PathResolution { base_def: Trait(DefId { krate: CrateNum(0), node: DefIndex(0:3185) }), unresolved_segments: 0 } before, PathResolution { base_def: Trait(DefId { krate: CrateNum(0), node: DefIndex(0:3185) }), unresolved_segments: 0 } now)', src/librustc_resolve/lib.rs:3460:12
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
stack backtrace:
   0: std::sys::imp::backtrace::tracing::imp::unwind_backtrace
   1: std::sys_common::backtrace::_print
   2: std::panicking::default_hook::{{closure}}
   3: std::panicking::default_hook
   4: std::panicking::rust_panic_with_hook
   5: std::panicking::begin_panic
   6: std::panicking::begin_panic_fmt
   7: rustc_resolve::Resolver::record_def
   8: rustc_resolve::Resolver::smart_resolve_path_fragment
   9: rustc_resolve::Resolver::smart_resolve_path
  10: <rustc_resolve::Resolver<'a> as syntax::visit::Visitor<'tcx>>::visit_generics
  11: syntax::visit::walk_impl_item
  12: rustc_resolve::Resolver::with_type_parameter_rib
  13: rustc_resolve::Resolver::with_current_self_type
  14: rustc_resolve::Resolver::with_self_rib
  15: rustc_resolve::Resolver::with_optional_trait_ref
  16: rustc_resolve::Resolver::with_self_rib
  17: rustc_resolve::Resolver::resolve_item
  18: syntax::visit::walk_item
  19: rustc_resolve::Resolver::resolve_item
  20: rustc_resolve::Resolver::resolve_crate
  21: rustc_driver::driver::phase_2_configure_and_expand
  22: rustc_driver::driver::compile_input
  23: rustc_driver::run_compiler

error: Could not compile `core`.

Caused by:
  process didn't exit successfully: `/home/sunjay/Documents/projects/rust/build/bootstrap/debug/rustc --crate-name core src/libcore/lib.rs --error-format json --crate-type lib --emit=dep-info,link -C opt-level=2 -C metadata=3181dd9e46400ebd -C extra-filename=-3181dd9e46400ebd --out-dir /home/sunjay/Documents/projects/rust/build/x86_64-unknown-linux-gnu/stage1-std/x86_64-unknown-linux-gnu/release/deps --target x86_64-unknown-linux-gnu -L dependency=/home/sunjay/Documents/projects/rust/build/x86_64-unknown-linux-gnu/stage1-std/x86_64-unknown-linux-gnu/release/deps -L dependency=/home/sunjay/Documents/projects/rust/build/x86_64-unknown-linux-gnu/stage1-std/release/deps` (exit code: 101)
warning: build failed, waiting for other jobs to finish...
error: build failed
thread 'main' panicked at 'command did not execute successfully: "/home/sunjay/Documents/projects/rust/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "build" "--target" "x86_64-unknown-linux-gnu" "-j" "4" "--release" "--features" "panic-unwind jemalloc backtrace" "--manifest-path" "/home/sunjay/Documents/projects/rust/src/libstd/Cargo.toml" "--message-format" "json"
expected success, got: exit code: 101', src/bootstrap/compile.rs:883:8
stack backtrace:
   0: std::sys::imp::backtrace::tracing::imp::unwind_backtrace
             at /checkout/src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::_print
             at /checkout/src/libstd/sys_common/backtrace.rs:71
   2: std::panicking::default_hook::{{closure}}
             at /checkout/src/libstd/sys_common/backtrace.rs:60
             at /checkout/src/libstd/panicking.rs:381
   3: std::panicking::default_hook
             at /checkout/src/libstd/panicking.rs:397
   4: std::panicking::rust_panic_with_hook
             at /checkout/src/libstd/panicking.rs:611
   5: std::panicking::begin_panic
             at /checkout/src/libstd/panicking.rs:572
   6: std::panicking::begin_panic_fmt
             at /checkout/src/libstd/panicking.rs:522
   7: bootstrap::compile::run_cargo
   8: <bootstrap::compile::Std as bootstrap::builder::Step>::run
   9: bootstrap::builder::Builder::ensure
  10: <bootstrap::compile::Test as bootstrap::builder::Step>::run
  11: bootstrap::builder::Builder::ensure
  12: <bootstrap::compile::Rustc as bootstrap::builder::Step>::run
  13: bootstrap::builder::Builder::ensure
  14: <bootstrap::compile::Assemble as bootstrap::builder::Step>::run
  15: bootstrap::builder::Builder::ensure
  16: bootstrap::builder::Builder::compiler
  17: <bootstrap::compile::Std as bootstrap::builder::Step>::make_run
  18: bootstrap::builder::StepDescription::maybe_run
  19: bootstrap::builder::StepDescription::run
  20: bootstrap::builder::Builder::run
  21: bootstrap::Build::build
  22: bootstrap::main
  23: __rust_maybe_catch_panic
             at /checkout/src/libpanic_unwind/lib.rs:99
  24: std::rt::lang_start
             at /checkout/src/libstd/panicking.rs:459
             at /checkout/src/libstd/panic.rs:361
             at /checkout/src/libstd/rt.rs:61
  25: main
  26: __libc_start_main
  27: _start
failed to run: /home/sunjay/Documents/projects/rust/build/bootstrap/debug/bootstrap build
Build completed unsuccessfully in 0:12:04

nikomatsakis · Sep 22, 2017

nikomatsakis reviewed Sep 22, 2017

View changes

nikomatsakis · Sep 22, 2017

src/libsyntax/visit.rs

@@ -585,6 +584,7 @@ pub fn walk_impl_item<'a, V: Visitor<'a>>(visitor: &mut V, impl_item: &'a ImplIt
    visitor.visit_vis(&impl_item.vis);
    visitor.visit_ident(impl_item.span, impl_item.ident);
    walk_list!(visitor, visit_attribute, &impl_item.attrs);
+    visitor.visit_generics(&impl_item.generics);


...i.e., here, when resolve invokes walk_impl_item, it will walk the generics here

nikomatsakis · Sep 22, 2017

nikomatsakis reviewed Sep 22, 2017

View changes

nikomatsakis · Sep 22, 2017

src/librustc_resolve/lib.rs

@@ -1845,6 +1844,7 @@ impl<'a> Resolver<'a> {

                        for trait_item in trait_items {
                            this.check_proc_macro_attrs(&trait_item.attrs);
+                            this.visit_generics(&trait_item.generics);


we should not be invoking visit_generics here. IT will happen when we invoke walk_trait_item below. Instead, we should be inserting the type-parameters rib:

let type_parameters = HasTypeParameters(&trait_item.generics, MethodRibKind(!sig.decl.has_self())); this.with_type_parameter_rib(type_parameters, |this| { /* old code goes here */ })

sunjay · Sep 25, 2017

sunjay reviewed Sep 25, 2017

View changes

sunjay · Sep 25, 2017

src/librustc_resolve/lib.rs

@@ -1861,7 +1860,7 @@ impl<'a> Resolver<'a> {
                                }
                                TraitItemKind::Method(ref sig, _) => {
                                    let type_parameters =
-                                        HasTypeParameters(&sig.generics,
+                                        HasTypeParameters(&trait_item.generics,


I think we'll need to add this type parameter rib to each variant in this match statement because each HasTypeParamters will need a different rib kind. Since nothing other than methods has generics right now, would it work to save that change until we are actually implementing associated type generics?

(this applies to both trait items and impl items)

Well, it depends. I would think we just want to rename MethodRibKind to something else like TraitOrImplItemRibKind, but it might be important to distinguish those cases for error messages? I kinda' doubt it, but have to look around.

nikomatsakis · Sep 25, 2017

nikomatsakis approved these changes Sep 25, 2017

View changes

At first glance, this is looking good!

sunjay · Sep 25, 2017

@nikomatsakis The build passed! 🎉 🎉 🎉 🎉 🎉

nikomatsakis · Sep 25, 2017

nikomatsakis approved these changes Sep 25, 2017

View changes

nikomatsakis · Sep 25, 2017

@bors r+

bors · Sep 25, 2017

📌 Commit ea6b18e has been approved by nikomatsakis

nikomatsakis · Sep 26, 2017

@bors r+

bors · Sep 26, 2017

📌 Commit 037aa16 has been approved by nikomatsakis

bors · Sep 27, 2017

⌛️ Testing commit 037aa16 with merge d2d5d34...

bors · Sep 27, 2017

💔 Test failed - status-appveyor

nikomatsakis · Sep 27, 2017

OK, so this failed building rustfmt, which is being built because of the RLS. I'm not really sure what needs to happen here. Can we set toolstate to "broken" for the RLS? Do we have to (a) open a PR fixing rustfmt, (b) redirect RLS in its cargo.toml to use that PR, then (c) land this patch, then (d) land that PR, then (e) redirect RLS back?

cc @nrc @rust-lang/dev-tools @rust-lang/compiler -- sorry for the broad cc here but I'm actually unclear on who precisely I ought to cc!

alexcrichton · Sep 27, 2017

Sure yeah I can write out how this works, sorry we don't have some great instructions for this yet! If it works out here, though, maybe we can write them down in CONTRIBUTING.md :)

First, create a config.toml if it doesn't already exists, set submodules = false
Run ./x.py test src/tools/rustfmt, fix any errors in the submodule itself until it works
Run ./x.py test src/tools/rls, fix any errors in the submodule itself until it works
Make a commit for rustfmt, if necessary, and send a PR to the master branch of rust-lang-nursery/rustfmt
Do the same, if necessary for the RLS
A maintainer of rls/rustfmt (currently @nrc has done this but others can too!) will not merge the PR. The PR can't be merged because CI will be broken. Instead a new branch will be created, and the PR will be pushed to the branch (the PR is left open)
On your branch, update the rls/rustfmt submodules to these branches
Commit the changes, update your PR to rust-lang/rust
Wait for the branch to merge
Wait for a nightly
A maintainer of rls/rustfmt will merge the original PRs to rls/rustfmt
Eventually the rls/rustfmt submodules will get re-updated back to the master branch

Eventually we'll be able to set the tools to "broken" temporarily to skip a lot of these steps, but unfortunately we're not there yet for the rls/rustfmt. :(

Lemme know if there's any questions though!

sunjay · Oct 18, 2017

Now that we've got support for it, want to just flag clippy/rustfmt/rls to broken and we can land this?

It looks like the clippy submodule is failing to update as a remote ref has gone away? (I don't know the state of all the various PRs related to this one)

Sounds good! That's much easier. 😄 As for the PRs, only rustfmt and clippy are broken as far as I know. (RLS is broken because of rustfmt.) The rustfmt PR is already done and is just waiting for review. It can be merged once this lands and the CI passes. The clippy PR will be done by the time this gets merged.

Now that I've cleared this PR and marked the tools as broken, it should be ready for final review and approval from @nikomatsakis. :)

sunjay · Oct 18, 2017

@alexcrichton Any idea why the build is failing?

nikomatsakis · Oct 18, 2017

Looks like an incremental test is failing.

nikomatsakis · Oct 23, 2017

@bors r+

bors · Oct 23, 2017

📌 Commit 4b0f004 has been approved by nikomatsakis

bors · Oct 23, 2017

⌛️ Testing commit 4b0f004 with merge d86e250...

bors · Oct 23, 2017

💔 Test failed - status-travis

kennytm · Oct 24, 2017

@bors retry #44159

cross job errored, failed to upload to S3 due to outdated aws-sdk-resources gem.

ERROR: Could not find a valid gem 'aws-sdk-resources' (= 2.10.70) in any repository
ERROR: Possible alternatives: aws-sdk-resources
/home/travis/.rvm/rubies/ruby-2.2.7/lib/ruby/site_ruby/2.2.0/rubygems/core_ext/kernel_require.rb:55:in `require': cannot load such file -- aws-sdk (LoadError)
	from /home/travis/.rvm/rubies/ruby-2.2.7/lib/ruby/site_ruby/2.2.0/rubygems/core_ext/kernel_require.rb:55:in `require'
	from /home/travis/.rvm/gems/ruby-2.2.7/gems/dpl-1.8.43/lib/dpl/provider.rb:85:in `requires'
	from /home/travis/.rvm/gems/ruby-2.2.7/gems/dpl-1.8.43/lib/dpl/provider/s3.rb:6:in `<class:S3>'
	from /home/travis/.rvm/gems/ruby-2.2.7/gems/dpl-1.8.43/lib/dpl/provider/s3.rb:5:in `<class:Provider>'
	from /home/travis/.rvm/gems/ruby-2.2.7/gems/dpl-1.8.43/lib/dpl/provider/s3.rb:4:in `<module:DPL>'
	from /home/travis/.rvm/gems/ruby-2.2.7/gems/dpl-1.8.43/lib/dpl/provider/s3.rb:3:in `<top (required)>'
	from /home/travis/.rvm/gems/ruby-2.2.7/gems/dpl-1.8.43/lib/dpl/provider.rb:59:in `const_get'
	from /home/travis/.rvm/gems/ruby-2.2.7/gems/dpl-1.8.43/lib/dpl/provider.rb:59:in `block in new'
	from /home/travis/.rvm/gems/ruby-2.2.7/gems/dpl-1.8.43/lib/dpl/cli.rb:41:in `fold'
	from /home/travis/.rvm/gems/ruby-2.2.7/gems/dpl-1.8.43/lib/dpl/provider.rb:56:in `new'
	from /home/travis/.rvm/gems/ruby-2.2.7/gems/dpl-1.8.43/lib/dpl/cli.rb:31:in `run'
	from /home/travis/.rvm/gems/ruby-2.2.7/gems/dpl-1.8.43/lib/dpl/cli.rb:7:in `run'
	from /home/travis/.rvm/gems/ruby-2.2.7/gems/dpl-1.8.43/bin/dpl:5:in `<top (required)>'
	from /home/travis/.rvm/gems/ruby-2.2.7/bin/dpl:23:in `load'
	from /home/travis/.rvm/gems/ruby-2.2.7/bin/dpl:23:in `<main>'

bors · Oct 24, 2017

⌛️ Testing commit 4b0f004 with merge 3366247...

bors · Oct 24, 2017

☀️ Test successful - status-appveyor, status-travis
Approved by: nikomatsakis
Pushing 3366247 to master...

rust-highfive assigned nikomatsakis Sep 22, 2017

shepmaster added the S-waiting-on-author label Sep 22, 2017

sunjay referenced this pull request Sep 25, 2017
Closed
HIR - Move Generics from MethodSig to TraitItem and ImplItem #44852

arielb1 added S-waiting-on-bors and removed S-waiting-on-author labels Sep 26, 2017

shepmaster added S-waiting-on-author and removed S-waiting-on-bors labels Sep 29, 2017

kennytm added S-waiting-on-author and removed S-waiting-on-review labels Oct 18, 2017

bors merged commit 4b0f004 into rust-lang:master Oct 24, 2017
2 checks passed

2 checks passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details

homu Test successful
Details

bors referenced this pull request Oct 24, 2017
Merged
Update rls-data for save analysis #45096

sunjay deleted the sunjay:lift_generics branch Oct 24, 2017

hcpl referenced this pull request Oct 28, 2017
Closed
Clippy is broken with nightly #2184

Manishearth referenced this pull request Oct 29, 2017
Merged
Add generics to LateContext #45611

rust-lang/rust

Join GitHub today

Move Generics from MethodSig to TraitItem and ImplItem #44766

Conversation

sunjay commented Sep 22, 2017 • edited

rust-highfive assigned nikomatsakis Sep 22, 2017

This comment has been minimized.

rust-highfive commented Sep 22, 2017

sunjay reviewed Sep 22, 2017 View changes

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

sunjay reviewed Sep 22, 2017 View changes

This comment has been minimized.

This comment has been minimized.

nikomatsakis Sep 22, 2017 • edited

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

sunjay reviewed Sep 22, 2017 View changes

This comment has been minimized.

sunjay Sep 22, 2017 • edited

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

sunjay reviewed Sep 22, 2017 View changes

This comment has been minimized.

This comment has been minimized.

sunjay reviewed Sep 22, 2017 View changes

This comment has been minimized.

This comment has been minimized.

sunjay reviewed Sep 22, 2017 View changes

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

sunjay commented Sep 22, 2017

nikomatsakis reviewed Sep 22, 2017 View changes

This comment has been minimized.

nikomatsakis reviewed Sep 22, 2017 View changes

This comment has been minimized.

shepmaster added the S-waiting-on-author label Sep 22, 2017

sunjay reviewed Sep 25, 2017 View changes

This comment has been minimized.

This comment has been minimized.

nikomatsakis approved these changes Sep 25, 2017 View changes

nikomatsakis left a comment

This comment has been minimized.

sunjay commented Sep 25, 2017

nikomatsakis approved these changes Sep 25, 2017 View changes

This comment has been minimized.

nikomatsakis commented Sep 25, 2017

This comment has been minimized.

bors commented Sep 25, 2017

sunjay referenced this pull request Sep 25, 2017

This comment has been minimized.

nikomatsakis commented Sep 26, 2017

This comment has been minimized.

bors commented Sep 26, 2017

arielb1 added S-waiting-on-bors and removed S-waiting-on-author labels Sep 26, 2017

This comment has been minimized.

bors commented Sep 27, 2017

bors added a commit that referenced this pull request Sep 27, 2017

This comment has been minimized.

bors commented Sep 27, 2017

This comment has been minimized.

nikomatsakis commented Sep 27, 2017 • edited

This comment has been minimized.

alexcrichton commented Sep 27, 2017

shepmaster added S-waiting-on-author and removed S-waiting-on-bors labels Sep 29, 2017

sunjay added some commits Sep 25, 2017

This comment has been minimized.

sunjay commented Oct 18, 2017

This comment has been minimized.

sunjay commented Oct 18, 2017

This comment has been minimized.

nikomatsakis commented Oct 18, 2017

kennytm added S-waiting-on-author and removed S-waiting-on-review labels Oct 18, 2017

kennytm added a commit to kennytm/rust that referenced this pull request Oct 18, 2017

sunjay commented Sep 22, 2017 •

edited

sunjay reviewed Sep 22, 2017

View changes

sunjay reviewed Sep 22, 2017

View changes

nikomatsakis Sep 22, 2017 •

edited

sunjay reviewed Sep 22, 2017

View changes

sunjay Sep 22, 2017 •

edited

sunjay reviewed Sep 22, 2017

View changes

sunjay reviewed Sep 22, 2017

View changes

sunjay reviewed Sep 22, 2017

View changes

nikomatsakis reviewed Sep 22, 2017

View changes

nikomatsakis reviewed Sep 22, 2017

View changes

sunjay reviewed Sep 25, 2017

View changes

nikomatsakis approved these changes Sep 25, 2017

View changes

nikomatsakis approved these changes Sep 25, 2017

View changes

nikomatsakis commented Sep 27, 2017 •

edited

kennytm commented Oct 24, 2017 •

edited

bors merged commit `4b0f004` into rust-lang:master Oct 24, 2017
2 checks passed