jiebi/CodeConvo huggingface dataset:
Change:
The Switch terminator, which is used in pattern matching, is currently unimplemented in MIR. This terminator should load the discriminant from an lvalue and branch to the appropriate basic block target based on what is found there. It has to integrate with the code.

Discussion:
use llvm::BasicBlockRef; use rustc::mir::repr as mir; <ins> use trans::adt; </ins> use trans::base; use trans::build; use trans::common::Block;

build::CondBr(bcx, cond.immediate(), lltrue, llfalse, DebugLoc::None); } <del> mir::Terminator::Switch { .. } => { unimplemented!() </del> <ins> mir::Terminator::Switch { ref discr, ref adt_def, ref targets } => { let adt_ty = bcx.tcx().lookup_item_type(adt_def.did).ty; let represented_ty = adt::represent_type(bcx.ccx(), adt_ty); let discr_lvalue = self.trans_lvalue(bcx, discr); let discr = adt::trans_get_discr(bcx, &represented_ty, discr_lvalue.llval, None); // The else branch of the Switch can't be hit, so branch to an unreachable // instruction so LLVM knows that // FIXME it might be nice to have just one such block (created lazilly), we could // store it in the "MIR trans" state. let unreachable_blk = bcx.fcx.new_temp_block("enum-variant-unreachable"); build::Unreachable(unreachable_blk); let switch = build::Switch(bcx, discr, unreachable_blk.llbb, targets.len()); assert_eq!(adt_def.variants.len(), targets.len()); for (adt_variant, target) in adt_def.variants.iter().zip(targets) { let llval = adt::trans_case(bcx, &*represented_ty, adt_variant.disr_val); let llbb = self.llblock(*target); build::AddCase(switch, llval, llbb) } </ins> } mir::Terminator::SwitchInt { ref discr, switch_ty, ref values, ref targets } => {

<ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. #![feature(rustc_attrs)] enum Abc { A(u8), B(i8), C, D, } #[rustc_mir] fn foo(x: Abc) -> i32 { match x { Abc::C => 3, Abc::D => 4, Abc::B(_) => 2, Abc::A(_) => 1, } } #[rustc_mir] fn foo2(x: Abc) -> bool { match x { Abc::D => true, _ => false } } fn main() { assert_eq!(1, foo(Abc::A(42))); assert_eq!(2, foo(Abc::B(-100))); assert_eq!(3, foo(Abc::C)); assert_eq!(4, foo(Abc::D)); assert_eq!(false, foo2(Abc::A(1))); assert_eq!(false, foo2(Abc::B(2))); assert_eq!(false, foo2(Abc::C)); assert_eq!(true, foo2(Abc::D)); } </ins>
Change:
There are no Windows nightlies currently being published: They appear to have been broken since at least Nov. 1. This prevents Servo from updating Rust. CC:
was looking into this earlier.

Discussion:
# $(3) is host # $(4) tag define DEF_PREPARE_HOST_TOOL <ins> prepare-host-tool-$(1)-$(2)-$(3)-$(4):  PREPARE_SOURCE_BIN_DIR=$$(HBIN$(2)_H_$(3)) </ins> prepare-host-tool-$(1)-$(2)-$(3)-$(4): prepare-maybe-clean-$(4)  $$(foreach dep,$$(TOOL_DEPS_$(1)),prepare-host-lib-$$(dep)-$(2)-$(3)-$(4))  $$(HBIN$(2)_H_$(3))/$(1)$$(X_$(3)) 

# $(3) is host # $(4) tag define DEF_PREPARE_HOST_LIB <del> prepare-host-lib-$(1)-$(2)-$(3)-$(4): PREPARE_WORKING_SOURCE_LIB_DIR=$$(PREPARE_SOURCE_LIB_DIR) prepare-host-lib-$(1)-$(2)-$(3)-$(4): PREPARE_WORKING_DEST_LIB_DIR=$$(PREPARE_DEST_LIB_DIR) </del> <ins> prepare-host-lib-$(1)-$(2)-$(3)-$(4):  PREPARE_WORKING_SOURCE_LIB_DIR=$$(HLIB$(2)_H_$(3)) prepare-host-lib-$(1)-$(2)-$(3)-$(4):  PREPARE_WORKING_DEST_LIB_DIR=$$(PREPARE_DEST_DIR)/$$(notdir $$(HLIB$(2)_H_$(3))) </ins> prepare-host-lib-$(1)-$(2)-$(3)-$(4): prepare-maybe-clean-$(4)  $$(foreach dep,$$(RUST_DEPS_$(1)),prepare-host-lib-$$(dep)-$(2)-$(3)-$(4))  $$(HLIB$(2)_H_$(3))/stamp.$(1) 

# $(4) tag define DEF_PREPARE_TARGET_N # Rebind PREPARE_*_LIB_DIR to point to rustlib, then install the libs for the targets <del> prepare-target-$(2)-host-$(3)-$(1)-$(4): PREPARE_WORKING_SOURCE_LIB_DIR=$$(PREPARE_SOURCE_LIB_DIR)/rustlib/$(2)/lib prepare-target-$(2)-host-$(3)-$(1)-$(4): PREPARE_WORKING_DEST_LIB_DIR=$$(PREPARE_DEST_LIB_DIR)/rustlib/$(2)/lib prepare-target-$(2)-host-$(3)-$(1)-$(4): PREPARE_SOURCE_BIN_DIR=$$(PREPARE_SOURCE_LIB_DIR)/rustlib/$(3)/bin prepare-target-$(2)-host-$(3)-$(1)-$(4): PREPARE_DEST_BIN_DIR=$$(PREPARE_DEST_LIB_DIR)/rustlib/$(3)/bin </del> <ins> prepare-target-$(2)-host-$(3)-$(1)-$(4):  PREPARE_WORKING_SOURCE_LIB_DIR=$$(TLIB$(1)_T_$(2)_H_$(3)) prepare-target-$(2)-host-$(3)-$(1)-$(4):  PREPARE_WORKING_DEST_LIB_DIR=$$(PREPARE_DEST_LIB_DIR)/rustlib/$(2)/lib prepare-target-$(2)-host-$(3)-$(1)-$(4):  PREPARE_SOURCE_BIN_DIR=$$(TBIN$(1)_T_$(2)_H_$(3)) prepare-target-$(2)-host-$(3)-$(1)-$(4):  PREPARE_DEST_BIN_DIR=$$(PREPARE_DEST_LIB_DIR)/rustlib/$(3)/bin </ins> prepare-target-$(2)-host-$(3)-$(1)-$(4): prepare-maybe-clean-$(4)  $$(foreach crate,$$(TARGET_CRATES),  $$(TLIB$(1)_T_$(2)_H_$(3))/stamp.$$(crate)) 

define DEF_PREPARE <del> prepare-base-$(1)-%: PREPARE_SOURCE_DIR=$$(PREPARE_HOST)/stage$$(PREPARE_STAGE) prepare-base-$(1)-%: PREPARE_SOURCE_BIN_DIR=$$(PREPARE_SOURCE_DIR)/bin prepare-base-$(1)-%: PREPARE_SOURCE_LIB_DIR=$$(PREPARE_SOURCE_DIR)/$$(CFG_LIBDIR_RELATIVE) </del> prepare-base-$(1)-%: PREPARE_SOURCE_MAN_DIR=$$(S)/man prepare-base-$(1)-%: PREPARE_DEST_BIN_DIR=$$(PREPARE_DEST_DIR)/bin prepare-base-$(1)-%: PREPARE_DEST_LIB_DIR=$$(PREPARE_DEST_DIR)/$$(CFG_LIBDIR_RELATIVE)
Change:
Attempting to compile  with results in:
This also affects 
Seems that is just a dupe of , too.
Closing as dupe of .

Discussion:
pub use core::slice::{SplitMut, ChunksMut, Split}; #[stable(feature = "rust1", since = "1.0.0")] pub use core::slice::{SplitN, RSplitN, SplitNMut, RSplitNMut}; <ins> #[unstable(feature = "slice_bytes", issue = "27740")] #[allow(deprecated)] pub use core::slice::bytes; </ins> #[stable(feature = "rust1", since = "1.0.0")] pub use core::slice::{from_raw_parts, from_raw_parts_mut};

} #[test] <ins> fn test_bytes_set_memory() { use std::slice::bytes::MutableByteVector; let mut values = [1,2,3,4,5]; values[0..5].set_memory(0xAB); assert!(values == [0xAB, 0xAB, 0xAB, 0xAB, 0xAB]); values[2..4].set_memory(0xFF); assert!(values == [0xAB, 0xAB, 0xFF, 0xFF, 0xAB]); } #[test] </ins> #[should_panic] fn test_overflow_does_not_cause_segfault() { let mut v = vec![];

use core::num::Float; #[test] <ins> fn from_str_issue7588() { let u : Option<u8> = u8::from_str_radix("1000", 10).ok(); assert_eq!(u, None); let s : Option<i16> = i16::from_str_radix("80000", 10).ok(); assert_eq!(s, None); } #[test] </ins> fn test_int_from_str_overflow() { let mut i8_val: i8 = 127; assert_eq!("127".parse::<i8>().ok(), Some(i8_val));

/// # Ok(()) /// # } /// ``` <ins> #[stable(feature = "rust1", since = "1.0.0")] </ins> #[rustc_deprecated(since = "1.1.0", reason = "replaced with std::os::unix::fs::symlink and  std::os::windows::fs::{symlink_file, symlink_dir}")] <del> #[stable(feature = "rust1", since = "1.0.0")] </del> pub fn soft_link<P: AsRef<Path>, Q: AsRef<Path>>(src: P, dst: Q) -> io::Result<()> { fs_imp::symlink(src.as_ref(), dst.as_ref()) }

} } <del> #[unstable(feature = "rustc_private", issue = "0")] #[rustc_deprecated(since = "1.0.0", reason = "Replaced with `expander().fold_expr()`")] pub fn expand_expr(&mut self, e: P<ast::Expr>) -> P<ast::Expr> { self.expander().fold_expr(e) } </del> /// Returns a `Folder` for deeply expanding all macros in an AST node. pub fn expander<'b>(&'b mut self) -> expand::MacroExpander<'b, 'a> { expand::MacroExpander::new(self)

} } <del> /// Deprecated: use `into_iter`. #[unstable(feature = "rustc_private", issue = "0")] #[rustc_deprecated(since = "1.0.0", reason = "use into_iter")] pub fn move_iter(self) -> IntoIter<T> { self.into_iter() } </del> pub fn len(&self) -> usize { match self.repr { Zero => 0,

<del> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. struct Foo(bool); const NEW_FALSE: bool = false; const STATIC_FOO: Foo = Foo(NEW_FALSE); pub fn main() { match (Foo(false)) { STATIC_FOO => 3, _ => 11 }; } </del>
Change:
Sections appearing on the sidebar seem to not have a deterministic order and can result in variations like the attached screenshot. The order probably should be deterministic and go either or . Reloading the page many times seems to successfully reproduce the issue here. ! !

Discussion:
<script src="{root_path}jquery.js"></script> <script src="{root_path}main.js"></script> {play_js} <del> <script async src="{root_path}search-index.js"></script> </del> <ins> <script defer src="{root_path}search-index.js"></script> </ins> </body> </html>"##, content   = *t,
Change:
The following code fails to build on nightly It generates this error:
The expansion is: The call to returns for chaining purposes, but the expansion obviously ignores it.
This was a result of .

Discussion:
// except according to those terms. use ast; <del> use ast::{MetaItem, Expr,}; use codemap::Span; </del> <ins> use ast::{MetaItem, Expr}; use codemap::{Span, respan}; </ins> use ext::base::{ExtCtxt, Annotatable}; use ext::build::AstBuilder; use ext::deriving::generic::*;

builder_expr.clone(), token::str_to_ident("field"), vec![field]); <del> stmts.push(cx.stmt_expr(expr)); </del> <ins> // Use `let _ = expr;` to avoid triggering the // unused_results lint. stmts.push(stmt_let_undescore(cx, span, expr)); </ins> } } else { // normal struct/struct variant

builder_expr.clone(), token::str_to_ident("field"), vec![name, field]); <del> stmts.push(cx.stmt_expr(expr)); </del> <ins> stmts.push(stmt_let_undescore(cx, span, expr)); </ins> } } stmts

let block = cx.block(span, stmts, Some(expr)); cx.expr_block(block) } <ins> fn stmt_let_undescore(cx: &mut ExtCtxt, sp: Span, expr: P<ast::Expr>) -> P<ast::Stmt> { let local = P(ast::Local { pat: cx.pat_wild(sp), ty: None, init: Some(expr), id: ast::DUMMY_NODE_ID, span: sp, }); let decl = respan(sp, ast::DeclLocal(local)); P(respan(sp, ast::StmtDecl(P(decl), ast::DUMMY_NODE_ID))) } </ins>

<ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. #![deny(unused_results)] #![allow(dead_code)] #[derive(Debug)] struct A(usize); #[derive(Debug)] struct B { a: usize } fn main() {} </ins>
Change:
from:
I agree that it's a bit odd, yeah. I'll try to figure out a better phrasing. It's trying to say that if you don't have two pointers to the same location in memory, you can't get a race, since a race inherently means two simultaneous load/stores.
What about "However, as we can only have one at a time (the only kind of reference that can write), it is impossible to have a data race." It works as a drop in replacement for that sentence. You could drop the stuff in parentheses as well for succinctness.
I like it.
Should I make a PR or is there an aggregate PR for minor changes like this?
We don't do aggregate PRs, feel free to send one in for just this, thanks! :) , Ashkan Kiani wrote:

Discussion:
> operations are not synchronized. With references, you may have as many as you’d like, since none of them are <del> writing. If you are writing, you need two or more pointers to the same memory, and you can only have one `&mut` at a time. This is how Rust prevents data races at compile time: we’ll get errors if we break the rules. </del> <ins> writing. However, as we can only have one `&mut` at a time, it is impossible to have a data race. This is how Rust prevents data races at compile time: we’ll get errors if we break the rules. </ins> With this in mind, let’s consider our example again.

In the above example, `y` is declared before `x`, meaning that `y` lives longer than `x`, which is not allowed.
Change:
from here: That seems to say that you always need explicit lifetimes when working with structs, but, that's not true, is it? A quick peek ahead at structs, and lifetimes seem to be implicit there: This also made me realize I'm misinterpreting the above sentence. EDIT: Ok but now I'm not sure again, there's that again:
I'm not sure, that entire chapter seems lacking. "structs can also have lifetimes" but they don't, they can have lifetime parameters, which are just like type parameters, except lifetimes instead of types. struct values have lifetimes (in the other sense, of "liveness"), which new users may confuse with the lifetime parameters of a struct.
I've just realized that lifetime specifier is required when using in the field there: I guess that sentence isn't completely false after all. So, this won't work: but this will: For completion:
Lifetime parameters for structs are never implicit. But some structs have no lifetime parameters.

Discussion:
# In `struct`s <del> You’ll also need explicit lifetimes when working with [`struct`][structs]s: </del> <ins> You’ll also need explicit lifetimes when working with [`struct`][structs]s that contain references: </ins> ```rust struct Foo<'a> {
Change:
I'm guessing this is a result of , though I'm not entirely sure why this changed; I have a patch for this, PR to follow.
We generally don't care about warnings coming out of stage 0; that's the old compiler.
Oh, wait, this is promoted to an error; nevermind, we have to do something.

Discussion:
use std::mem::size_of_val; use std::ptr::null_mut; <del> type rlim_t = libc::uint64_t; #[repr(C)] struct rlimit { rlim_cur: rlim_t, rlim_max: rlim_t } extern { // name probably doesn't need to be mut, but the C function doesn't // specify const fn sysctl(name: *mut libc::c_int, namelen: libc::c_uint, oldp: *mut libc::c_void, oldlenp: *mut libc::size_t, newp: *mut libc::c_void, newlen: libc::size_t) -> libc::c_int; fn getrlimit(resource: libc::c_int, rlp: *mut rlimit) -> libc::c_int; fn setrlimit(resource: libc::c_int, rlp: *const rlimit) -> libc::c_int; } </del> static CTL_KERN: libc::c_int = 1; static KERN_MAXFILESPERPROC: libc::c_int = 29; <del> static RLIMIT_NOFILE: libc::c_int = 8; </del> // The strategy here is to fetch the current resource limits, read the // kern.maxfilesperproc sysctl value, and bump the soft resource limit for

let mut mib: [libc::c_int; 2] = [CTL_KERN, KERN_MAXFILESPERPROC]; let mut maxfiles: libc::c_int = 0; let mut size: libc::size_t = size_of_val(&maxfiles) as libc::size_t; <del> if sysctl(&mut mib[0], 2, &mut maxfiles as *mut _ as *mut _, &mut size, </del> <ins> if libc::sysctl(&mut mib[0], 2, &mut maxfiles as *mut _ as *mut _, &mut size, </ins> null_mut(), 0) != 0 { let err = io::Error::last_os_error(); panic!("raise_fd_limit: error calling sysctl: {}", err); } // Fetch the current resource limits <del> let mut rlim = rlimit{rlim_cur: 0, rlim_max: 0}; if getrlimit(RLIMIT_NOFILE, &mut rlim) != 0 { </del> <ins> let mut rlim = libc::rlimit{rlim_cur: 0, rlim_max: 0}; if libc::getrlimit(libc::RLIMIT_NOFILE, &mut rlim) != 0 { </ins> let err = io::Error::last_os_error(); panic!("raise_fd_limit: error calling getrlimit: {}", err); } // Bump the soft limit to the smaller of kern.maxfilesperproc and the hard // limit <del> rlim.rlim_cur = cmp::min(maxfiles as rlim_t, rlim.rlim_max); </del> <ins> rlim.rlim_cur = cmp::min(maxfiles as libc::rlim_t, rlim.rlim_max); </ins> // Set our newly-increased resource limit <del> if setrlimit(RLIMIT_NOFILE, &rlim) != 0 { </del> <ins> if libc::setrlimit(libc::RLIMIT_NOFILE, &rlim) != 0 { </ins> let err = io::Error::last_os_error(); panic!("raise_fd_limit: error calling setrlimit: {}", err); }
Change:
mentions a fn called but there is no such fn (anymore?).
CC
Yeah this is what it was: text needs updating.

Discussion:
way to bound a lifetime is to return it from a function with a bound lifetime. However if this is unacceptable, the reference can be placed in a location with a specific lifetime. Unfortunately it's impossible to name all lifetimes involved <del> in a function. To get around this, you can in principle use `copy_lifetime`, though these are unstable due to their awkward nature and questionable utility. </del> <ins> in a function. </ins>
Change:
These two code snippets should functionally be doing the same thing, but the type checker seems to think one has a destructor. The difference seems to be in the reliance on an associated type. complains that cannot be declared a mutable static because it has a desctructor: While this, unsurprisingly, works: Here are links to non-compiling/compiling examples on non-working: working:
( expressed interest in working on this, I will mentor.)
Triage: still relevant.
I'm still interested in helping to fix this. you mentioned at one point that you had a hunch for where the problem was. Perhaps a pointer would be enough to get the ball rolling?
Hmm. So, the error is emitted by the "constant qualification" code, which walks the MIR for generating a constant value and looks for things that should be disallowed. One of those things is the creation of a struct which has a destructor. This code is in . I think where I would start is trying to insert some to track out exactly what is happening. My guess would be that we are walking down , but I'm actually not sure. cc author of the code in question
It might be the type contents, if we use them for "needs drop". Aren't they conservative wrt projections?
that was my first assumption, that it was something like that. When I was poking about in the code I didn't see the place where we branch into that, but maybe I just wasn't reading very carefully.
which references . cc This could at least try to normalize projections, which would fix the problem here. Btw we can now remove "type contents" and replace it with two cached flags ( & needs-drop).
This doesn't seem to be an issue anymore. Running the provided "non-working" code doesn't trigger a compiler error.
Indeed, this not longer seems to be an issue. Happy to close the issue :)
Should we add a regression test first?

Discussion:
<ins> // build-pass pub trait Foo { type FooAssoc; } pub struct Bar<F: Foo> { id: F::FooAssoc } pub struct Baz; impl Foo for Baz { type FooAssoc = usize; } static mut MY_FOO: Bar<Baz> = Bar { id: 0 }; fn main() {} </ins>
Change:
From "Strings" chapter: The problem is that a beginner who reads these lines can make a false conclusion that "string slice" and "string literal" mean the same thing, and string slices always has a static lifetime. Comment from newcomer:
To be clear: a string literal is just a string slice that lives forever (because it's a pointer into the binary's rodata or whatever).
yep, but looks like it is not obvious for newcomers. I think we should make these lines in the book more clear.
Yep, always a great thing to do! Just clarifying for whoever wants to fix this up.

Discussion:
strings are not null-terminated and can contain null bytes. Rust has two main types of strings: `&str` and `String`. Let’s talk about <del> `&str` first. These are called ‘string slices’. String literals are of the type `&'static str`: </del> <ins> `&str` first. These are called ‘string slices’. A string slice has a fixed size, and cannot be mutated. It is a reference to a sequence of UTF-8 bytes. </ins> ```rust let greeting = "Hello there."; // greeting: &'static str ``` <del> This string is statically allocated, meaning that it’s saved inside our compiled program, and exists for the entire duration it runs. The `greeting` binding is a reference to this statically allocated string. String slices have a fixed size, and cannot be mutated. </del> <ins> `"Hello there."` is a string literal and its type is `&'static str`. A string literal is a string slice that is statically allocated, meaning that it’s saved inside our compiled program, and exists for the entire duration it runs. The `greeting` binding is a reference to this statically allocated string. Any function expecting a string slice will also accept a string literal. </ins> String literals can span multiple lines. There are two forms. The first will include the newline and the leading spaces:

assert_eq!("foon        bar", s); ``` <del> The second, with a ``, does not trim the spaces: </del> <ins> The second, with a ``, trims the spaces and the newline: </ins> ```rust let s = "foo
Change:
In a typical long-running program that is performing allocations and deallocations as it goes, successive allocations are unlikely to be exactly adjacent in memory, but may imply that there's more predictability than there is. That said, a normal allocator won't be completely unpredictable. One suggestion was to use random numbers for heap allocs.

Discussion:
this chapter will be a refresher. If you’re not, you’ll learn about this more general concept, but with a Rust-y focus. <ins> As with most things, when learning about them, we’ll use a simplified model to start. This lets you get a handle on the basics, without getting bogged down with details which are, for now, irrelevant. The examples we’ll use aren’t 100% accurate, but are representative for the level we’re trying to learn at right now. Once you have the basics down, learning more about how allocators are implemented, virtual memory, and other advanced topics will reveal the leaks in this particular abstraction. </ins> # Memory management These two terms are about memory management. The stack and the heap are
Change:
In error messages, consider changing to as a subtle hint that you can have more than one bound. (cf , )
Not critical for 0.6; removing milestone
sure. easy fix. patch in the queue,

Discussion:
match ty::get(ty).sty { ty::ty_param(*) => { tcx.sess.span_err(sp, "value may contain borrowed  <del> pointers; use `'static` bound"); </del> <ins> pointers; add `'static` bound"); </ins> } _ => { tcx.sess.span_err(sp, "value may contain borrowed 

// Not OK---T may contain borrowed ptrs and it is going to escape // as part of the returned foo value struct F<T> { f: T } <del> @F {f:t} as @foo //~ ERROR value may contain borrowed pointers; use `'static` bound </del> <ins> @F {f:t} as @foo //~ ERROR value may contain borrowed pointers; add `'static` bound </ins> } fn to_foo_3<T:Copy + 'static>(t: T) -> @foo {

trait foo { fn foo(&self); } fn to_foo<T:Copy + foo>(t: T) -> @foo { <del> @t as @foo //~ ERROR value may contain borrowed pointers; use `'static` bound </del> <ins> @t as @foo //~ ERROR value may contain borrowed pointers; add `'static` bound </ins> } fn to_foo2<T:Copy + foo + 'static>(t: T) -> @foo {
Change:
Hello All, Used to build the nightly smoothly, but today it failed with the messages: running it manually: Don't you think adding to solve the problem? Thanks!
cc probably fallout from ?
Thanks a lot. I've read comments carefully and have got that the changes to in nursery that is an additional have already shipped. Unfortunately my rust sandbox stuck to the previous version of after script. Anyway editing manually the above file: solved the issue.
Closing as the problem has been resolved. Thanks!

Discussion:
<del> Subproject commit 8531cc11e196b7ae9072ae7b384a930ff7b00dfb </del> <ins> Subproject commit c27f4167a7706baba1ddbb0a9ab320ec18d097db </ins>