Question:
Test case: Compiles successfully on , causes an ICE on . Diff contains only , CC Found while trying to minimize , but filed separately since the error message is different and this one has a small test case.
Do you have a backtrace?
Yes of course. Sorry I forgot to include it: rust error: internal compiler error: attempted .defid() on invalid def: Err note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: note: run with for a backtrace thread 'rustc' panicked at 'Box<Any', stack backtrace: 1: 0x7fc35e73fdf3 - std::sys::imp::backtrace::tracing::imp::write::hdfa3e34b856f69a3 2: 0x7fc35e74e5dd - std::panicking::defaulthook::{{closure}}::h20f8c1082e0ce86e 3: 0x7fc35e74e17b - std::panicking::defaulthook::hd31552ac08c2a241 4: 0x7fc35e74ea68 - std::panicking::rustpanicwithhook::h73969d230a072c1a 5: 0x7fc357eda667 - std::panicking::beginpanic::hb89a2261f4776ce3 6: 0x7fc357eef99f - rustcerrors::Handler::bug::h13b3b29154320abd 7: 0x7fc35bab053a - rustc::session::optspanbugfmt::{{closure}}::hfea18dd68f59976d 8: 0x7fc35baafff7 - rustc::session::optspanbugfmt::h7d370a0810dbdbbd 9: 0x7fc35baafce2 - rustc::session::bugfmt::hcde5f50c54004a4f 10: 0x7fc35b984552 - rustc::hir::def::Def::defid::h728c22aafbe84efc 11: 0x7fc35c6ddb3a - rustcprivacy::ObsoleteVisiblePrivateTypesVisitor::pathisprivatetype::h24756a49a68d1da9 12: 0x7fc35c6d53db - rustc::hir::intravisit::walkty::h64b13c0c45b7a09a 13: 0x7fc35c6d49ba - rustc::hir::intravisit::Visitor::visitfn::ha8ad665c42b1d643 14: 0x7fc35c6de7cf - <rustcprivacy::ObsoleteVisiblePrivateTypesVisitor<'a, 'tcxas rustc::hir::intravisit::Visitor<'tcx::visititem::hae9f32c7942ccca1 15: 0x7fc35c6deab5 - <rustcprivacy::ObsoleteVisiblePrivateTypesVisitor<'a, 'tcxas rustc::hir::intravisit::Visitor<'tcx::visititem::hae9f32c7942ccca1 16: 0x7fc35c6e1b7a - rustcprivacy::checkcrate::h5ba75e3c4ebe0690 17: 0x7fc35eaef747 - rustcdriver::driver::phase3runanalysispasses::{{closure}}::h388b9236cf305089 18: 0x7fc35ead66d6 - rustcdriver::driver::phase3runanalysispasses::h080c1a734c4f2909 19: 0x7fc35eac5425 - rustcdriver::driver::compileinput::hab55539b85c4ceed 20: 0x7fc35eb0ea51 - rustcdriver::runcompiler::h128b89b79f649304 21: 0x7fc35ea236fb - std::panicking::try::docall::h15bca94dda232804 22: 0x7fc35e757b06 - rustmaybecatchpanic 23: 0x7fc35ea44d01 - <F as alloc::boxed::FnBox<A::callbox::h8832766c4bda585b 24: 0x7fc35e74d470 - std::sys::imp::thread::Thread::new::threadstart::h7d03d727f96da002 25: 0x7fc357684453 - startthread 26: 0x7fc35e4147de - GI__clone 27: 0x0 - <unknown
triage: P-high Seems bad. Assigning to based on bisection.
Fixed in .

view_path.map(|Spanned {node, span}| Spanned { node: match node { ViewPathSimple(ident, path) => { <del> ViewPathSimple(ident, fld.fold_path(path)) </del> <ins> ViewPathSimple(fld.fold_ident(ident), fld.fold_path(path)) </ins> } ViewPathGlob(path) => { ViewPathGlob(fld.fold_path(path)) } ViewPathList(path, path_list_idents) => { <del> ViewPathList(fld.fold_path(path), path_list_idents.move_map(|path_list_ident| { Spanned { node: PathListItem_ { id: fld.new_id(path_list_ident.node.id), rename: path_list_ident.node.rename, name: path_list_ident.node.name, }, span: fld.new_span(path_list_ident.span) } })) </del> <ins> let path = fld.fold_path(path); let path_list_idents = path_list_idents.move_map(|path_list_ident| Spanned { node: PathListItem_ { id: fld.new_id(path_list_ident.node.id), rename: path_list_ident.node.rename.map(|ident| fld.fold_ident(ident)), name: fld.fold_ident(path_list_ident.node.name), }, span: fld.new_span(path_list_ident.span) }); ViewPathList(path, path_list_idents) </ins> } }, span: fld.new_span(span)


Question:
Test case: Compiles successfully on , causes an ICE on . Diff contains only , CC Found while trying to minimize , but filed separately since the error message is different and this one has a small test case.
Do you have a backtrace?
Yes of course. Sorry I forgot to include it: rust error: internal compiler error: attempted .defid() on invalid def: Err note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: note: run with for a backtrace thread 'rustc' panicked at 'Box<Any', stack backtrace: 1: 0x7fc35e73fdf3 - std::sys::imp::backtrace::tracing::imp::write::hdfa3e34b856f69a3 2: 0x7fc35e74e5dd - std::panicking::defaulthook::{{closure}}::h20f8c1082e0ce86e 3: 0x7fc35e74e17b - std::panicking::defaulthook::hd31552ac08c2a241 4: 0x7fc35e74ea68 - std::panicking::rustpanicwithhook::h73969d230a072c1a 5: 0x7fc357eda667 - std::panicking::beginpanic::hb89a2261f4776ce3 6: 0x7fc357eef99f - rustcerrors::Handler::bug::h13b3b29154320abd 7: 0x7fc35bab053a - rustc::session::optspanbugfmt::{{closure}}::hfea18dd68f59976d 8: 0x7fc35baafff7 - rustc::session::optspanbugfmt::h7d370a0810dbdbbd 9: 0x7fc35baafce2 - rustc::session::bugfmt::hcde5f50c54004a4f 10: 0x7fc35b984552 - rustc::hir::def::Def::defid::h728c22aafbe84efc 11: 0x7fc35c6ddb3a - rustcprivacy::ObsoleteVisiblePrivateTypesVisitor::pathisprivatetype::h24756a49a68d1da9 12: 0x7fc35c6d53db - rustc::hir::intravisit::walkty::h64b13c0c45b7a09a 13: 0x7fc35c6d49ba - rustc::hir::intravisit::Visitor::visitfn::ha8ad665c42b1d643 14: 0x7fc35c6de7cf - <rustcprivacy::ObsoleteVisiblePrivateTypesVisitor<'a, 'tcxas rustc::hir::intravisit::Visitor<'tcx::visititem::hae9f32c7942ccca1 15: 0x7fc35c6deab5 - <rustcprivacy::ObsoleteVisiblePrivateTypesVisitor<'a, 'tcxas rustc::hir::intravisit::Visitor<'tcx::visititem::hae9f32c7942ccca1 16: 0x7fc35c6e1b7a - rustcprivacy::checkcrate::h5ba75e3c4ebe0690 17: 0x7fc35eaef747 - rustcdriver::driver::phase3runanalysispasses::{{closure}}::h388b9236cf305089 18: 0x7fc35ead66d6 - rustcdriver::driver::phase3runanalysispasses::h080c1a734c4f2909 19: 0x7fc35eac5425 - rustcdriver::driver::compileinput::hab55539b85c4ceed 20: 0x7fc35eb0ea51 - rustcdriver::runcompiler::h128b89b79f649304 21: 0x7fc35ea236fb - std::panicking::try::docall::h15bca94dda232804 22: 0x7fc35e757b06 - rustmaybecatchpanic 23: 0x7fc35ea44d01 - <F as alloc::boxed::FnBox<A::callbox::h8832766c4bda585b 24: 0x7fc35e74d470 - std::sys::imp::thread::Thread::new::threadstart::h7d03d727f96da002 25: 0x7fc357684453 - startthread 26: 0x7fc35e4147de - GI__clone 27: 0x0 - <unknown
triage: P-high Seems bad. Assigning to based on bisection.
Fixed in .

pub fn noop_fold_ty_binding<T: Folder>(b: TypeBinding, fld: &mut T) -> TypeBinding { TypeBinding { id: fld.new_id(b.id), <del> ident: b.ident, </del> <ins> ident: fld.fold_ident(b.ident), </ins> ty: fld.fold_ty(b.ty), span: fld.new_span(b.span), }


Question:
Test case: Compiles successfully on , causes an ICE on . Diff contains only , CC Found while trying to minimize , but filed separately since the error message is different and this one has a small test case.
Do you have a backtrace?
Yes of course. Sorry I forgot to include it: rust error: internal compiler error: attempted .defid() on invalid def: Err note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: note: run with for a backtrace thread 'rustc' panicked at 'Box<Any', stack backtrace: 1: 0x7fc35e73fdf3 - std::sys::imp::backtrace::tracing::imp::write::hdfa3e34b856f69a3 2: 0x7fc35e74e5dd - std::panicking::defaulthook::{{closure}}::h20f8c1082e0ce86e 3: 0x7fc35e74e17b - std::panicking::defaulthook::hd31552ac08c2a241 4: 0x7fc35e74ea68 - std::panicking::rustpanicwithhook::h73969d230a072c1a 5: 0x7fc357eda667 - std::panicking::beginpanic::hb89a2261f4776ce3 6: 0x7fc357eef99f - rustcerrors::Handler::bug::h13b3b29154320abd 7: 0x7fc35bab053a - rustc::session::optspanbugfmt::{{closure}}::hfea18dd68f59976d 8: 0x7fc35baafff7 - rustc::session::optspanbugfmt::h7d370a0810dbdbbd 9: 0x7fc35baafce2 - rustc::session::bugfmt::hcde5f50c54004a4f 10: 0x7fc35b984552 - rustc::hir::def::Def::defid::h728c22aafbe84efc 11: 0x7fc35c6ddb3a - rustcprivacy::ObsoleteVisiblePrivateTypesVisitor::pathisprivatetype::h24756a49a68d1da9 12: 0x7fc35c6d53db - rustc::hir::intravisit::walkty::h64b13c0c45b7a09a 13: 0x7fc35c6d49ba - rustc::hir::intravisit::Visitor::visitfn::ha8ad665c42b1d643 14: 0x7fc35c6de7cf - <rustcprivacy::ObsoleteVisiblePrivateTypesVisitor<'a, 'tcxas rustc::hir::intravisit::Visitor<'tcx::visititem::hae9f32c7942ccca1 15: 0x7fc35c6deab5 - <rustcprivacy::ObsoleteVisiblePrivateTypesVisitor<'a, 'tcxas rustc::hir::intravisit::Visitor<'tcx::visititem::hae9f32c7942ccca1 16: 0x7fc35c6e1b7a - rustcprivacy::checkcrate::h5ba75e3c4ebe0690 17: 0x7fc35eaef747 - rustcdriver::driver::phase3runanalysispasses::{{closure}}::h388b9236cf305089 18: 0x7fc35ead66d6 - rustcdriver::driver::phase3runanalysispasses::h080c1a734c4f2909 19: 0x7fc35eac5425 - rustcdriver::driver::compileinput::hab55539b85c4ceed 20: 0x7fc35eb0ea51 - rustcdriver::runcompiler::h128b89b79f649304 21: 0x7fc35ea236fb - std::panicking::try::docall::h15bca94dda232804 22: 0x7fc35e757b06 - rustmaybecatchpanic 23: 0x7fc35ea44d01 - <F as alloc::boxed::FnBox<A::callbox::h8832766c4bda585b 24: 0x7fc35e74d470 - std::sys::imp::thread::Thread::new::threadstart::h7d03d727f96da002 25: 0x7fc357684453 - startthread 26: 0x7fc35e4147de - GI__clone 27: 0x0 - <unknown
triage: P-high Seems bad. Assigning to based on bisection.
Fixed in .

.collect::<Vec<_>>() .into(), id: fld.new_id(id), <del> ident: ident, </del> <ins> ident: fld.fold_ident(ident), </ins> bounds: fld.fold_bounds(bounds), default: default.map(|x| fld.fold_ty(x)), span: span


Question:
Test case: Compiles successfully on , causes an ICE on . Diff contains only , CC Found while trying to minimize , but filed separately since the error message is different and this one has a small test case.
Do you have a backtrace?
Yes of course. Sorry I forgot to include it: rust error: internal compiler error: attempted .defid() on invalid def: Err note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: note: run with for a backtrace thread 'rustc' panicked at 'Box<Any', stack backtrace: 1: 0x7fc35e73fdf3 - std::sys::imp::backtrace::tracing::imp::write::hdfa3e34b856f69a3 2: 0x7fc35e74e5dd - std::panicking::defaulthook::{{closure}}::h20f8c1082e0ce86e 3: 0x7fc35e74e17b - std::panicking::defaulthook::hd31552ac08c2a241 4: 0x7fc35e74ea68 - std::panicking::rustpanicwithhook::h73969d230a072c1a 5: 0x7fc357eda667 - std::panicking::beginpanic::hb89a2261f4776ce3 6: 0x7fc357eef99f - rustcerrors::Handler::bug::h13b3b29154320abd 7: 0x7fc35bab053a - rustc::session::optspanbugfmt::{{closure}}::hfea18dd68f59976d 8: 0x7fc35baafff7 - rustc::session::optspanbugfmt::h7d370a0810dbdbbd 9: 0x7fc35baafce2 - rustc::session::bugfmt::hcde5f50c54004a4f 10: 0x7fc35b984552 - rustc::hir::def::Def::defid::h728c22aafbe84efc 11: 0x7fc35c6ddb3a - rustcprivacy::ObsoleteVisiblePrivateTypesVisitor::pathisprivatetype::h24756a49a68d1da9 12: 0x7fc35c6d53db - rustc::hir::intravisit::walkty::h64b13c0c45b7a09a 13: 0x7fc35c6d49ba - rustc::hir::intravisit::Visitor::visitfn::ha8ad665c42b1d643 14: 0x7fc35c6de7cf - <rustcprivacy::ObsoleteVisiblePrivateTypesVisitor<'a, 'tcxas rustc::hir::intravisit::Visitor<'tcx::visititem::hae9f32c7942ccca1 15: 0x7fc35c6deab5 - <rustcprivacy::ObsoleteVisiblePrivateTypesVisitor<'a, 'tcxas rustc::hir::intravisit::Visitor<'tcx::visititem::hae9f32c7942ccca1 16: 0x7fc35c6e1b7a - rustcprivacy::checkcrate::h5ba75e3c4ebe0690 17: 0x7fc35eaef747 - rustcdriver::driver::phase3runanalysispasses::{{closure}}::h388b9236cf305089 18: 0x7fc35ead66d6 - rustcdriver::driver::phase3runanalysispasses::h080c1a734c4f2909 19: 0x7fc35eac5425 - rustcdriver::driver::compileinput::hab55539b85c4ceed 20: 0x7fc35eb0ea51 - rustcdriver::runcompiler::h128b89b79f649304 21: 0x7fc35ea236fb - std::panicking::try::docall::h15bca94dda232804 22: 0x7fc35e757b06 - rustmaybecatchpanic 23: 0x7fc35ea44d01 - <F as alloc::boxed::FnBox<A::callbox::h8832766c4bda585b 24: 0x7fc35e74d470 - std::sys::imp::thread::Thread::new::threadstart::h7d03d727f96da002 25: 0x7fc357684453 - startthread 26: 0x7fc35e4147de - GI__clone 27: 0x0 - <unknown
triage: P-high Seems bad. Assigning to based on bisection.
Fixed in .

let fs = fields.move_map(|f| { Spanned { span: folder.new_span(f.span), node: ast::FieldPat { <del> ident: f.node.ident, </del> <ins> ident: folder.fold_ident(f.node.ident), </ins> pat: folder.fold_pat(f.node.pat), is_shorthand: f.node.is_shorthand, }}


Question:
Test case: Compiles successfully on , causes an ICE on . Diff contains only , CC Found while trying to minimize , but filed separately since the error message is different and this one has a small test case.
Do you have a backtrace?
Yes of course. Sorry I forgot to include it: rust error: internal compiler error: attempted .defid() on invalid def: Err note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: note: run with for a backtrace thread 'rustc' panicked at 'Box<Any', stack backtrace: 1: 0x7fc35e73fdf3 - std::sys::imp::backtrace::tracing::imp::write::hdfa3e34b856f69a3 2: 0x7fc35e74e5dd - std::panicking::defaulthook::{{closure}}::h20f8c1082e0ce86e 3: 0x7fc35e74e17b - std::panicking::defaulthook::hd31552ac08c2a241 4: 0x7fc35e74ea68 - std::panicking::rustpanicwithhook::h73969d230a072c1a 5: 0x7fc357eda667 - std::panicking::beginpanic::hb89a2261f4776ce3 6: 0x7fc357eef99f - rustcerrors::Handler::bug::h13b3b29154320abd 7: 0x7fc35bab053a - rustc::session::optspanbugfmt::{{closure}}::hfea18dd68f59976d 8: 0x7fc35baafff7 - rustc::session::optspanbugfmt::h7d370a0810dbdbbd 9: 0x7fc35baafce2 - rustc::session::bugfmt::hcde5f50c54004a4f 10: 0x7fc35b984552 - rustc::hir::def::Def::defid::h728c22aafbe84efc 11: 0x7fc35c6ddb3a - rustcprivacy::ObsoleteVisiblePrivateTypesVisitor::pathisprivatetype::h24756a49a68d1da9 12: 0x7fc35c6d53db - rustc::hir::intravisit::walkty::h64b13c0c45b7a09a 13: 0x7fc35c6d49ba - rustc::hir::intravisit::Visitor::visitfn::ha8ad665c42b1d643 14: 0x7fc35c6de7cf - <rustcprivacy::ObsoleteVisiblePrivateTypesVisitor<'a, 'tcxas rustc::hir::intravisit::Visitor<'tcx::visititem::hae9f32c7942ccca1 15: 0x7fc35c6deab5 - <rustcprivacy::ObsoleteVisiblePrivateTypesVisitor<'a, 'tcxas rustc::hir::intravisit::Visitor<'tcx::visititem::hae9f32c7942ccca1 16: 0x7fc35c6e1b7a - rustcprivacy::checkcrate::h5ba75e3c4ebe0690 17: 0x7fc35eaef747 - rustcdriver::driver::phase3runanalysispasses::{{closure}}::h388b9236cf305089 18: 0x7fc35ead66d6 - rustcdriver::driver::phase3runanalysispasses::h080c1a734c4f2909 19: 0x7fc35eac5425 - rustcdriver::driver::compileinput::hab55539b85c4ceed 20: 0x7fc35eb0ea51 - rustcdriver::runcompiler::h128b89b79f649304 21: 0x7fc35ea236fb - std::panicking::try::docall::h15bca94dda232804 22: 0x7fc35e757b06 - rustmaybecatchpanic 23: 0x7fc35ea44d01 - <F as alloc::boxed::FnBox<A::callbox::h8832766c4bda585b 24: 0x7fc35e74d470 - std::sys::imp::thread::Thread::new::threadstart::h7d03d727f96da002 25: 0x7fc357684453 - startthread 26: 0x7fc35e4147de - GI__clone 27: 0x0 - <unknown
triage: P-high Seems bad. Assigning to based on bisection.
Fixed in .

<ins> // Copyright 2016 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. pub struct Foo; macro_rules! reexport { () => { use Foo as Bar; } } reexport!(); fn main() { use Bar; fn f(_: Bar) {} } </ins>


Question:
While digging around for something else I have just discovered that setting the UID for a subprocess with also causes a call to in the child. This should be documented. (Related to )
re-tagging as ; would you like this to appear in the docs, or not? If so, we're happy to do it, but want to make sure to not over-specify.
This seems like something we should document, yes. It's an unusual special-case that people should be aware of. This also interacts with .
Ok, this is ready for a PR. I've labeled it accordingly.
hi! It may be a long time now but may I ask if this issue is still needed? Because I can't find the call anywhere. I looked it as follows: Did I lookup the wrong function and structs?

/// Sets the child process's user ID. This translates to a /// `setuid` call in the child process. Failure in the `setuid` /// call will cause the spawn to fail. <ins> /// /// # Notes /// /// This will also trigger a call to `setgroups(0, NULL)` in the child /// process if no groups have been specified. /// This removes supplementary groups that might have given the child /// unwanted permissions. </ins> #[stable(feature = "rust1", since = "1.0.0")] fn uid(&mut self, id: UserId) -> &mut process::Command;


Question:
While digging around for something else I have just discovered that setting the UID for a subprocess with also causes a call to in the child. This should be documented. (Related to )
re-tagging as ; would you like this to appear in the docs, or not? If so, we're happy to do it, but want to make sure to not over-specify.
This seems like something we should document, yes. It's an unusual special-case that people should be aware of. This also interacts with .
Ok, this is ready for a PR. I've labeled it accordingly.
hi! It may be a long time now but may I ask if this issue is still needed? Because I can't find the call anywhere. I looked it as follows: Did I lookup the wrong function and structs?

if let Some(u) = self.get_uid() { // When dropping privileges from root, the `setgroups` call // will remove any extraneous groups. We only drop groups <del> // if the current uid is 0 and we weren't given an explicit </del> <ins> // if we have CAP_SETGID and we weren't given an explicit </ins> // set of groups. If we don't call this, then even though our // uid has dropped, we may still have groups that enable us to // do super-user things. //FIXME: Redox kernel does not support setgroups yet #[cfg(not(target_os = "redox"))] <del> if libc::getuid() == 0 && self.get_groups().is_none() { cvt(libc::setgroups(0, crate::ptr::null()))?; </del> <ins> if self.get_groups().is_none() { let res = cvt(libc::setgroups(0, crate::ptr::null())); if let Err(e) = res { // Here we ignore the case of not having CAP_SETGID. // An alternative would be to require CAP_SETGID (in // addition to CAP_SETUID) for setting the UID. if e.raw_os_error() != Some(libc::EPERM) { return Err(e.into()); } } </ins> } cvt(libc::setuid(u as uid_t))?; }


Question:
broke a library of mine where I had code like this: calls that used to call this trait method now call the new inherent method, but since that’s unstable the crate didn’t build until I . After that I could remove the trait since the new method has the same behavior. Anyway, this is just FYI. If we don’t want this kind of breakage we can’t add any new method to existing types ever, so that doesn’t sound viable. If the new method had had different behavior or if I wanted to keep supporting older compilers, it wouldn’t be too hard to rename my trait’s method or use UFCS.
Yeah in general we reserve the right to break downstream code with differences in method resolution because the downstream code can always be written in an "elaborated" form which works on all compilers (e.g. using ufcs). If a change to the standard library breaks an excessive amount of code in the ecosystem, though, then we'd need to take the steps much more purposefully.
Sounds good. Again, I don’t expect anything to change here and only made the previous comment to let people know this happened. I made this particular crate as an experiment, I don’t know of anyone actually using it.
Given that the core changes to the bounds on existing methods were instantly stable, it doesn't make a lot of sense to keep and as unstable. I propose we immediately stabilize these APIs. fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [x] No concerns currently listed. Once these reviewers reach consensus, this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
ping (checkbox)
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period is now complete.
What’s the next step here? Batch stabilization PR near the end of the release cycle?
Yep, I'm preparing one right now.

## `Cell<T>` <del> [`Cell<T>`][cell] is a type that provides zero-cost interior mutability, but only for `Copy` types. </del> <ins> [`Cell<T>`][cell] is a type that provides zero-cost interior mutability by moving data in and out of the cell. </ins> Since the compiler knows that all the data owned by the contained value is on the stack, there's no worry of leaking any data behind references (or worse!) by simply replacing the data.


Question:
broke a library of mine where I had code like this: calls that used to call this trait method now call the new inherent method, but since that’s unstable the crate didn’t build until I . After that I could remove the trait since the new method has the same behavior. Anyway, this is just FYI. If we don’t want this kind of breakage we can’t add any new method to existing types ever, so that doesn’t sound viable. If the new method had had different behavior or if I wanted to keep supporting older compilers, it wouldn’t be too hard to rename my trait’s method or use UFCS.
Yeah in general we reserve the right to break downstream code with differences in method resolution because the downstream code can always be written in an "elaborated" form which works on all compilers (e.g. using ufcs). If a change to the standard library breaks an excessive amount of code in the ecosystem, though, then we'd need to take the steps much more purposefully.
Sounds good. Again, I don’t expect anything to change here and only made the previous comment to let people know this happened. I made this particular crate as an experiment, I don’t know of anyone actually using it.
Given that the core changes to the bounds on existing methods were instantly stable, it doesn't make a lot of sense to keep and as unstable. I propose we immediately stabilize these APIs. fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [x] No concerns currently listed. Once these reviewers reach consensus, this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
ping (checkbox)
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period is now complete.
What’s the next step here? Batch stabilization PR near the end of the release cycle?
Yep, I'm preparing one right now.

unnecessary. However, this also relaxes the guarantees that the restriction provides; so if your invariants depend on data stored within `Cell`, you should be careful. <del> This is useful for mutating primitives and other `Copy` types when there is no easy way of </del> <ins> This is useful for mutating primitives and other types when there is no easy way of </ins> doing it in line with the static rules of `&` and `&mut`. `Cell` does not let you obtain interior references to the data, which makes it safe to freely


Question:
broke a library of mine where I had code like this: calls that used to call this trait method now call the new inherent method, but since that’s unstable the crate didn’t build until I . After that I could remove the trait since the new method has the same behavior. Anyway, this is just FYI. If we don’t want this kind of breakage we can’t add any new method to existing types ever, so that doesn’t sound viable. If the new method had had different behavior or if I wanted to keep supporting older compilers, it wouldn’t be too hard to rename my trait’s method or use UFCS.
Yeah in general we reserve the right to break downstream code with differences in method resolution because the downstream code can always be written in an "elaborated" form which works on all compilers (e.g. using ufcs). If a change to the standard library breaks an excessive amount of code in the ecosystem, though, then we'd need to take the steps much more purposefully.
Sounds good. Again, I don’t expect anything to change here and only made the previous comment to let people know this happened. I made this particular crate as an experiment, I don’t know of anyone actually using it.
Given that the core changes to the bounds on existing methods were instantly stable, it doesn't make a lot of sense to keep and as unstable. I propose we immediately stabilize these APIs. fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [x] No concerns currently listed. Once these reviewers reach consensus, this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
ping (checkbox)
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period is now complete.
What’s the next step here? Batch stabilization PR near the end of the release cycle?
Yep, I'm preparing one right now.

#### Cost <del> There is no runtime cost to using `Cell<T>`, however if you are using it to wrap larger (`Copy`) </del> <ins> There is no runtime cost to using `Cell<T>`, however if you are using it to wrap larger </ins> structs, it might be worthwhile to instead wrap individual fields in `Cell<T>` since each write is otherwise a full copy of the struct. ## `RefCell<T>` <del> [`RefCell<T>`][refcell] also provides interior mutability, but isn't restricted to `Copy` types. </del> <ins> [`RefCell<T>`][refcell] also provides interior mutability, but doesn't move data in and out of the cell. </ins> <del> Instead, it has a runtime cost. `RefCell<T>` enforces the read-write lock pattern at runtime (it's </del> <ins> However, it has a runtime cost. `RefCell<T>` enforces the read-write lock pattern at runtime (it's </ins> like a single-threaded mutex), unlike `&T`/`&mut T` which do so at compile time. This is done by the `borrow()` and `borrow_mut()` functions, which modify an internal reference count and return smart pointers which can be dereferenced immutably and mutably respectively. The refcount is restored when


Question:
broke a library of mine where I had code like this: calls that used to call this trait method now call the new inherent method, but since that’s unstable the crate didn’t build until I . After that I could remove the trait since the new method has the same behavior. Anyway, this is just FYI. If we don’t want this kind of breakage we can’t add any new method to existing types ever, so that doesn’t sound viable. If the new method had had different behavior or if I wanted to keep supporting older compilers, it wouldn’t be too hard to rename my trait’s method or use UFCS.
Yeah in general we reserve the right to break downstream code with differences in method resolution because the downstream code can always be written in an "elaborated" form which works on all compilers (e.g. using ufcs). If a change to the standard library breaks an excessive amount of code in the ecosystem, though, then we'd need to take the steps much more purposefully.
Sounds good. Again, I don’t expect anything to change here and only made the previous comment to let people know this happened. I made this particular crate as an experiment, I don’t know of anyone actually using it.
Given that the core changes to the bounds on existing methods were instantly stable, it doesn't make a lot of sense to keep and as unstable. I propose we immediately stabilize these APIs. fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [x] No concerns currently listed. Once these reviewers reach consensus, this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
ping (checkbox)
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period is now complete.
What’s the next step here? Batch stabilization PR near the end of the release cycle?
Yep, I'm preparing one right now.

//! references. We say that `Cell<T>` and `RefCell<T>` provide 'interior mutability', in contrast //! with typical Rust types that exhibit 'inherited mutability'. //! <del> //! Cell types come in two flavors: `Cell<T>` and `RefCell<T>`. `Cell<T>` provides `get` and `set` //! methods that change the interior value with a single method call. `Cell<T>` though is only //! compatible with types that implement `Copy`. For other types, one must use the `RefCell<T>` //! type, acquiring a write lock before mutating. </del> <ins> //! Cell types come in two flavors: `Cell<T>` and `RefCell<T>`. `Cell<T>` implements interior //! mutability by moving values in and out of the `Cell<T>`. To use references instead of values, //! one must use the `RefCell<T>` type, acquiring a write lock before mutating. `Cell<T>` provides //! methods to retrieve and change the current interior value: //! //!  - For types that implement `Copy`, the `get` method retrieves the current interior value. //!  - For types that implement `Default`, the `take` method replaces the current interior value //!    with `Default::default()` and returns the replaced value. //!  - For all types, the `replace` method replaces the current interior value and returns the //!    replaced value and the `into_inner` method consumes the `Cell<T>` and returns the interior //!    value. Additionally, the `set` method replaces the interior value, dropping the replaced //!    value. </ins> //! //! `RefCell<T>` uses Rust's lifetimes to implement 'dynamic borrowing', a process whereby one can //! claim temporary, exclusive, mutable access to the inner value. Borrows for `RefCell<T>`s are


Question:
broke a library of mine where I had code like this: calls that used to call this trait method now call the new inherent method, but since that’s unstable the crate didn’t build until I . After that I could remove the trait since the new method has the same behavior. Anyway, this is just FYI. If we don’t want this kind of breakage we can’t add any new method to existing types ever, so that doesn’t sound viable. If the new method had had different behavior or if I wanted to keep supporting older compilers, it wouldn’t be too hard to rename my trait’s method or use UFCS.
Yeah in general we reserve the right to break downstream code with differences in method resolution because the downstream code can always be written in an "elaborated" form which works on all compilers (e.g. using ufcs). If a change to the standard library breaks an excessive amount of code in the ecosystem, though, then we'd need to take the steps much more purposefully.
Sounds good. Again, I don’t expect anything to change here and only made the previous comment to let people know this happened. I made this particular crate as an experiment, I don’t know of anyone actually using it.
Given that the core changes to the bounds on existing methods were instantly stable, it doesn't make a lot of sense to keep and as unstable. I propose we immediately stabilize these APIs. fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [x] No concerns currently listed. Once these reviewers reach consensus, this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
ping (checkbox)
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period is now complete.
What’s the next step here? Batch stabilization PR near the end of the release cycle?
Yep, I'm preparing one right now.

use cmp::Ordering; use fmt::{self, Debug, Display}; use marker::Unsize; <ins> use mem; </ins> use ops::{Deref, DerefMut, CoerceUnsized}; <del> /// A mutable memory location that admits only `Copy` data. </del> <ins> /// A mutable memory location. </ins> /// /// See the [module-level documentation](index.html) for more. #[stable(feature = "rust1", since = "1.0.0")]


Question:
broke a library of mine where I had code like this: calls that used to call this trait method now call the new inherent method, but since that’s unstable the crate didn’t build until I . After that I could remove the trait since the new method has the same behavior. Anyway, this is just FYI. If we don’t want this kind of breakage we can’t add any new method to existing types ever, so that doesn’t sound viable. If the new method had had different behavior or if I wanted to keep supporting older compilers, it wouldn’t be too hard to rename my trait’s method or use UFCS.
Yeah in general we reserve the right to break downstream code with differences in method resolution because the downstream code can always be written in an "elaborated" form which works on all compilers (e.g. using ufcs). If a change to the standard library breaks an excessive amount of code in the ecosystem, though, then we'd need to take the steps much more purposefully.
Sounds good. Again, I don’t expect anything to change here and only made the previous comment to let people know this happened. I made this particular crate as an experiment, I don’t know of anyone actually using it.
Given that the core changes to the bounds on existing methods were instantly stable, it doesn't make a lot of sense to keep and as unstable. I propose we immediately stabilize these APIs. fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [x] No concerns currently listed. Once these reviewers reach consensus, this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
ping (checkbox)
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period is now complete.
What’s the next step here? Batch stabilization PR near the end of the release cycle?
Yep, I'm preparing one right now.

} impl<T:Copy> Cell<T> { <del> /// Creates a new `Cell` containing the given value. /// /// # Examples /// /// ``` /// use std::cell::Cell; /// /// let c = Cell::new(5); /// ``` #[stable(feature = "rust1", since = "1.0.0")] #[inline] pub const fn new(value: T) -> Cell<T> { Cell { value: UnsafeCell::new(value), } } </del> /// Returns a copy of the contained value. /// /// # Examples


Question:
broke a library of mine where I had code like this: calls that used to call this trait method now call the new inherent method, but since that’s unstable the crate didn’t build until I . After that I could remove the trait since the new method has the same behavior. Anyway, this is just FYI. If we don’t want this kind of breakage we can’t add any new method to existing types ever, so that doesn’t sound viable. If the new method had had different behavior or if I wanted to keep supporting older compilers, it wouldn’t be too hard to rename my trait’s method or use UFCS.
Yeah in general we reserve the right to break downstream code with differences in method resolution because the downstream code can always be written in an "elaborated" form which works on all compilers (e.g. using ufcs). If a change to the standard library breaks an excessive amount of code in the ecosystem, though, then we'd need to take the steps much more purposefully.
Sounds good. Again, I don’t expect anything to change here and only made the previous comment to let people know this happened. I made this particular crate as an experiment, I don’t know of anyone actually using it.
Given that the core changes to the bounds on existing methods were instantly stable, it doesn't make a lot of sense to keep and as unstable. I propose we immediately stabilize these APIs. fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [x] No concerns currently listed. Once these reviewers reach consensus, this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
ping (checkbox)
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period is now complete.
What’s the next step here? Batch stabilization PR near the end of the release cycle?
Yep, I'm preparing one right now.

unsafe{ *self.value.get() } } <del> /// Sets the contained value. /// /// # Examples /// /// ``` /// use std::cell::Cell; /// /// let c = Cell::new(5); /// /// c.set(10); /// ``` #[inline] #[stable(feature = "rust1", since = "1.0.0")] pub fn set(&self, value: T) { unsafe { *self.value.get() = value; } } </del> /// Returns a reference to the underlying `UnsafeCell`. /// /// # Examples


Question:
broke a library of mine where I had code like this: calls that used to call this trait method now call the new inherent method, but since that’s unstable the crate didn’t build until I . After that I could remove the trait since the new method has the same behavior. Anyway, this is just FYI. If we don’t want this kind of breakage we can’t add any new method to existing types ever, so that doesn’t sound viable. If the new method had had different behavior or if I wanted to keep supporting older compilers, it wouldn’t be too hard to rename my trait’s method or use UFCS.
Yeah in general we reserve the right to break downstream code with differences in method resolution because the downstream code can always be written in an "elaborated" form which works on all compilers (e.g. using ufcs). If a change to the standard library breaks an excessive amount of code in the ecosystem, though, then we'd need to take the steps much more purposefully.
Sounds good. Again, I don’t expect anything to change here and only made the previous comment to let people know this happened. I made this particular crate as an experiment, I don’t know of anyone actually using it.
Given that the core changes to the bounds on existing methods were instantly stable, it doesn't make a lot of sense to keep and as unstable. I propose we immediately stabilize these APIs. fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [x] No concerns currently listed. Once these reviewers reach consensus, this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
ping (checkbox)
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period is now complete.
What’s the next step here? Batch stabilization PR near the end of the release cycle?
Yep, I'm preparing one right now.

} } <ins> impl<T> Cell<T> { /// Creates a new `Cell` containing the given value. /// /// # Examples /// /// ``` /// use std::cell::Cell; /// /// let c = Cell::new(5); /// ``` #[stable(feature = "rust1", since = "1.0.0")] #[inline] pub const fn new(value: T) -> Cell<T> { Cell { value: UnsafeCell::new(value), } } /// Sets the contained value. /// /// # Examples /// /// ``` /// use std::cell::Cell; /// /// let c = Cell::new(5); /// /// c.set(10); /// ``` #[inline] #[stable(feature = "rust1", since = "1.0.0")] pub fn set(&self, val: T) { let old = self.replace(val); drop(old); } /// Replaces the contained value. /// /// # Examples /// /// ``` /// #![feature(move_cell)] /// use std::cell::Cell; /// /// let c = Cell::new(5); /// let old = c.replace(10); /// /// assert_eq!(5, old); /// ``` #[unstable(feature = "move_cell", issue = "39264")] pub fn replace(&self, val: T) -> T { mem::replace(unsafe { &mut *self.value.get() }, val) } /// Unwraps the value. /// /// # Examples /// /// ``` /// #![feature(move_cell)] /// use std::cell::Cell; /// /// let c = Cell::new(5); /// let five = c.into_inner(); /// /// assert_eq!(five, 5); /// ``` #[unstable(feature = "move_cell", issue = "39264")] pub fn into_inner(self) -> T { unsafe { self.value.into_inner() } } } impl<T: Default> Cell<T> { /// Takes the value of the cell, leaving `Default::default()` in its place. /// /// # Examples /// /// ``` /// #![feature(move_cell)] /// use std::cell::Cell; /// /// let c = Cell::new(5); /// let five = c.take(); /// /// assert_eq!(five, 5); /// assert_eq!(c.into_inner(), 0); /// ``` #[unstable(feature = "move_cell", issue = "39264")] pub fn take(&self) -> T { self.replace(Default::default()) } } </ins> #[unstable(feature = "coerce_unsized", issue = "27732")] impl<T: CoerceUnsized<U>, U> CoerceUnsized<Cell<U>> for Cell<T> {}


Question:
broke a library of mine where I had code like this: calls that used to call this trait method now call the new inherent method, but since that’s unstable the crate didn’t build until I . After that I could remove the trait since the new method has the same behavior. Anyway, this is just FYI. If we don’t want this kind of breakage we can’t add any new method to existing types ever, so that doesn’t sound viable. If the new method had had different behavior or if I wanted to keep supporting older compilers, it wouldn’t be too hard to rename my trait’s method or use UFCS.
Yeah in general we reserve the right to break downstream code with differences in method resolution because the downstream code can always be written in an "elaborated" form which works on all compilers (e.g. using ufcs). If a change to the standard library breaks an excessive amount of code in the ecosystem, though, then we'd need to take the steps much more purposefully.
Sounds good. Again, I don’t expect anything to change here and only made the previous comment to let people know this happened. I made this particular crate as an experiment, I don’t know of anyone actually using it.
Given that the core changes to the bounds on existing methods were instantly stable, it doesn't make a lot of sense to keep and as unstable. I propose we immediately stabilize these APIs. fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [x] No concerns currently listed. Once these reviewers reach consensus, this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
ping (checkbox)
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period is now complete.
What’s the next step here? Batch stabilization PR near the end of the release cycle?
Yep, I'm preparing one right now.

} #[test] <ins> fn cell_set() { let cell = Cell::new(10); cell.set(20); assert_eq!(20, cell.get()); let cell = Cell::new("Hello".to_owned()); cell.set("World".to_owned()); assert_eq!("World".to_owned(), cell.into_inner()); } #[test] fn cell_replace() { let cell = Cell::new(10); assert_eq!(10, cell.replace(20)); assert_eq!(20, cell.get()); let cell = Cell::new("Hello".to_owned()); assert_eq!("Hello".to_owned(), cell.replace("World".to_owned())); assert_eq!("World".to_owned(), cell.into_inner()); } #[test] fn cell_into_inner() { let cell = Cell::new(10); assert_eq!(10, cell.into_inner()); let cell = Cell::new("Hello world".to_owned()); assert_eq!("Hello world".to_owned(), cell.into_inner()); } #[test] </ins> fn refcell_default() { let cell: RefCell<u64> = Default::default(); assert_eq!(0, *cell.borrow());


Question:
broke a library of mine where I had code like this: calls that used to call this trait method now call the new inherent method, but since that’s unstable the crate didn’t build until I . After that I could remove the trait since the new method has the same behavior. Anyway, this is just FYI. If we don’t want this kind of breakage we can’t add any new method to existing types ever, so that doesn’t sound viable. If the new method had had different behavior or if I wanted to keep supporting older compilers, it wouldn’t be too hard to rename my trait’s method or use UFCS.
Yeah in general we reserve the right to break downstream code with differences in method resolution because the downstream code can always be written in an "elaborated" form which works on all compilers (e.g. using ufcs). If a change to the standard library breaks an excessive amount of code in the ecosystem, though, then we'd need to take the steps much more purposefully.
Sounds good. Again, I don’t expect anything to change here and only made the previous comment to let people know this happened. I made this particular crate as an experiment, I don’t know of anyone actually using it.
Given that the core changes to the bounds on existing methods were instantly stable, it doesn't make a lot of sense to keep and as unstable. I propose we immediately stabilize these APIs. fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [x] No concerns currently listed. Once these reviewers reach consensus, this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
ping (checkbox)
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period is now complete.
What’s the next step here? Batch stabilization PR near the end of the release cycle?
Yep, I'm preparing one right now.

#![feature(ordering_chaining)] #![feature(result_unwrap_or_default)] #![feature(ptr_unaligned)] <ins> #![feature(move_cell)] </ins> extern crate core; extern crate test;


Question: Hi, at this point, rust nightly pretty much builds out of the box (assuming you have an already built beta rustc compiler) on Solaris for x86_64. However, it doesn't (yet) build for sparcv9. I will provide a pull request shortly that adds the final, missing piece to support sparcv9 / Solaris.

ostype += 'abi64' elif cputype in {'powerpc', 'ppc', 'ppc64'}: cputype = 'powerpc' <ins> elif cputype == 'sparcv9': pass </ins> elif cputype in {'amd64', 'x86_64', 'x86-64', 'x64'}: cputype = 'x86_64' else:


Question: Hi, at this point, rust nightly pretty much builds out of the box (assuming you have an already built beta rustc compiler) on Solaris for x86_64. However, it doesn't (yet) build for sparcv9. I will provide a pull request shortly that adds the final, missing piece to support sparcv9 / Solaris.

// compiler-rt's build system already cfg.flag("-fno-builtin"); cfg.flag("-fvisibility=hidden"); <del> cfg.flag("-fomit-frame-pointer"); </del> <ins> // Accepted practice on Solaris is to never omit frame pointer so that // system observability tools work as expected.  In addition, at least // on Solaris, -fomit-frame-pointer on sparcv9 appears to generate // references to data outside of the current stack frame.  A search of // the gcc bug database provides a variety of issues surrounding // -fomit-frame-pointer on non-x86 platforms. if !target.contains("solaris") && !target.contains("sparc") { cfg.flag("-fomit-frame-pointer"); } </ins> cfg.flag("-ffreestanding"); cfg.define("VISIBILITY_HIDDEN", None); }


Question: Hi, at this point, rust nightly pretty much builds out of the box (assuming you have an already built beta rustc compiler) on Solaris for x86_64. However, it doesn't (yet) build for sparcv9. I will provide a pull request shortly that adds the final, missing piece to support sparcv9 / Solaris.

("armv7s-apple-ios", armv7s_apple_ios), ("x86_64-sun-solaris", x86_64_sun_solaris), <ins> ("sparcv9-sun-solaris", sparcv9_sun_solaris), </ins> ("x86_64-pc-windows-gnu", x86_64_pc_windows_gnu), ("i686-pc-windows-gnu", i686_pc_windows_gnu),


Question: Hi, at this point, rust nightly pretty much builds out of the box (assuming you have an already built beta rustc compiler) on Solaris for x86_64. However, it doesn't (yet) build for sparcv9. I will provide a pull request shortly that adds the final, missing piece to support sparcv9 / Solaris.

<ins> // Copyright 2016 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. use target::{Target, TargetResult}; pub fn target() -> TargetResult { let mut base = super::solaris_base::opts(); base.pre_link_args.push("-m64".to_string()); // llvm calls this "v9" base.cpu = "v9".to_string(); base.max_atomic_width = Some(64); Ok(Target { llvm_target: "sparcv9-sun-solaris".to_string(), target_endian: "big".to_string(), target_pointer_width: "64".to_string(), data_layout: "E-m:e-i64:64-n32:64-S128".to_string(), // Use "sparc64" instead of "sparcv9" here, since the former is already // used widely in the source base.  If we ever needed ABI // differentiation from the sparc64, we could, but that would probably // just be confusing. arch: "sparc64".to_string(), target_os: "solaris".to_string(), target_env: "".to_string(), target_vendor: "sun".to_string(), options: base, }) } </ins>


Question:
is this code: yielding:
. I don't know why we do this, the "else" part of "if" or "if-let" is an arbitrary expression: This seems simpler, less error prone and it won't hit arbitrary limitations specific to guards.
The RFC states: This doesn't feel like a compelling reason, particularly since the desugaring is not otherwise user visible. I would call this a bug.
triage: P-medium
This is a great mentoring bug! I'm going to write up some very quick pointers for now. Please reach out for more details. In short, the code that needs to be changed is in the "HIR lowering", which converts from the AST (what the user wrote) to the compiler's internal HIR (also an abstract syntax tree, but somewhat desugared). The code in question is in , specifically right . There is also some more logic. You'll want to change how it is desugaring along the lines that suggested .
I'm interested in taking this bug.
Hello I'm new to open source and Rust project. I wanted to contribute to the project. May I work on this bug?
Sure thing! Let us know how far you get with We're also on IRC.
I'll yield to you -- good luck!
If IfLet expression is desugared to the one shown in desugar_test() then it works as suggested by I have also reproduced the bug after desugaring the expression.

// //   match <sub_expr> { //     <pat> => <body>, <del> //     [_ if <else_opt_if_cond> => <else_opt_if_body>,] </del> //     _ => [<else_opt> | ()] //   }


Question:
is this code: yielding:
. I don't know why we do this, the "else" part of "if" or "if-let" is an arbitrary expression: This seems simpler, less error prone and it won't hit arbitrary limitations specific to guards.
The RFC states: This doesn't feel like a compelling reason, particularly since the desugaring is not otherwise user visible. I would call this a bug.
triage: P-medium
This is a great mentoring bug! I'm going to write up some very quick pointers for now. Please reach out for more details. In short, the code that needs to be changed is in the "HIR lowering", which converts from the AST (what the user wrote) to the compiler's internal HIR (also an abstract syntax tree, but somewhat desugared). The code in question is in , specifically right . There is also some more logic. You'll want to change how it is desugaring along the lines that suggested .
I'm interested in taking this bug.
Hello I'm new to open source and Rust project. I wanted to contribute to the project. May I work on this bug?
Sure thing! Let us know how far you get with We're also on IRC.
I'll yield to you -- good luck!
If IfLet expression is desugared to the one shown in desugar_test() then it works as suggested by I have also reproduced the bug after desugaring the expression.

arms.push(self.arm(hir_vec![pat], body_expr)); } <del> // `[_ if <else_opt_if_cond> => <else_opt_if_body>,]` // `_ => [<else_opt> | ()]` </del> <ins> // _ => [<else_opt>|()] </ins> { <del> let mut current: Option<&Expr> = else_opt.as_ref().map(|p| &**p); let mut else_exprs: Vec<Option<&Expr>> = vec![current]; // First, we traverse the AST and recursively collect all // `else` branches into else_exprs, e.g.: // // if let Some(_) = x { //    ... // } else if ... {  // Expr1 //    ... // } else if ... {  // Expr2 //    ... // } else {         // Expr3 //    ... // } // // ... results in else_exprs = [Some(&Expr1), //                              Some(&Expr2), //                              Some(&Expr3)] // // Because there also the case there is no `else`, these // entries can also be `None`, as in: // // if let Some(_) = x { //    ... // } else if ... {  // Expr1 //    ... // } else if ... {  // Expr2 //    ... // } // // ... results in else_exprs = [Some(&Expr1), //                              Some(&Expr2), //                              None] // // The last entry in this list is always translated into // the final "unguard" wildcard arm of the `match`. In the // case of a `None`, it becomes `_ => ()`. loop { if let Some(e) = current { // There is an else branch at this level if let ExprKind::If(_, _, ref else_opt) = e.node { // The else branch is again an if-expr current = else_opt.as_ref().map(|p| &**p); else_exprs.push(current); } else { // The last item in the list is not an if-expr, // stop here break } } else { // We have no more else branch break } } // Now translate the list of nested else-branches into the // arms of the match statement. for else_expr in else_exprs { if let Some(else_expr) = else_expr { let (guard, body) = if let ExprKind::If(ref cond, ref then, _) = else_expr.node { let then = self.lower_block(then, false); (Some(cond), self.expr_block(then, ThinVec::new())) } else { (None, self.lower_expr(else_expr)) }; arms.push(hir::Arm { attrs: hir_vec![], pats: hir_vec![self.pat_wild(e.span)], guard: guard.map(|e| P(self.lower_expr(e))), body: P(body), }); } else { // There was no else-branch, push a noop let pat_under = self.pat_wild(e.span); let unit = self.expr_tuple(e.span, hir_vec![]); arms.push(self.arm(hir_vec![pat_under], unit)); } } </del> <ins> let wildcard_arm: Option<&Expr> = else_opt.as_ref().map(|p| &**p); let wildcard_pattern = self.pat_wild(e.span); let body = if let Some(else_expr) = wildcard_arm { P(self.lower_expr(else_expr)) } else { self.expr_tuple(e.span, hir_vec![]) }; arms.push(self.arm(hir_vec![wildcard_pattern], body)); </ins> } let contains_else_clause = else_opt.is_some();


Question:
is this code: yielding:
. I don't know why we do this, the "else" part of "if" or "if-let" is an arbitrary expression: This seems simpler, less error prone and it won't hit arbitrary limitations specific to guards.
The RFC states: This doesn't feel like a compelling reason, particularly since the desugaring is not otherwise user visible. I would call this a bug.
triage: P-medium
This is a great mentoring bug! I'm going to write up some very quick pointers for now. Please reach out for more details. In short, the code that needs to be changed is in the "HIR lowering", which converts from the AST (what the user wrote) to the compiler's internal HIR (also an abstract syntax tree, but somewhat desugared). The code in question is in , specifically right . There is also some more logic. You'll want to change how it is desugaring along the lines that suggested .
I'm interested in taking this bug.
Hello I'm new to open source and Rust project. I wanted to contribute to the project. May I work on this bug?
Sure thing! Let us know how far you get with We're also on IRC.
I'll yield to you -- good luck!
If IfLet expression is desugared to the one shown in desugar_test() then it works as suggested by I have also reproduced the bug after desugaring the expression.

<ins> // Copyright 2017 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; impl Foo { fn bar(&mut self) -> bool { true } } fn error(foo: &mut Foo) { if let Some(_) = Some(true) { } else if foo.bar() {} } fn ok(foo: &mut Foo) { if let Some(_) = Some(true) { } else { if foo.bar() {} } } fn main() {} </ins>


Question: fails on emscripten with the following error message: Thus the test is currently ignored on emscripten. Note: it may be that the failure occurs only on when the test is compiled with optimizations. Note: this happens when using LLVM 4.0 (this issue was opened now to get an issue number to reference).

# 32/64-bit MinGW builds. # <del> # The MinGW builds unfortunately have to both download a custom toolchain and # avoid the one installed by AppVeyor by default. Interestingly, though, for # different reasons! </del> <ins> # We are using MinGW with posix threads since LLVM does not compile with # the win32 threads version due to missing support for C++'s std::thread. </ins> # <del> # For 32-bit the installed gcc toolchain on AppVeyor uses the pthread # threading model. This is unfortunately not what we want, and if we compile # with it then there's lots of link errors in the standard library (undefined # references to pthread symbols). # # For 64-bit the installed gcc toolchain is currently 5.3.0 which # unfortunately segfaults on Windows with --enable-llvm-assertions (segfaults # in LLVM). See rust-lang/rust#28445 for more information, but to work around # this we go back in time to 4.9.2 specifically. </del> <ins> # Instead of relying on the MinGW version installed on appveryor we download # and install one ourselves so we won't be surprised by changes to appveyor's # build image. </ins> # # Finally, note that the downloads below are all in the `rust-lang-ci` S3 # bucket, but they cleraly didn't originate there! The downloads originally # came from the mingw-w64 SourceForge download site. Unfortunately # SourceForge is notoriously flaky, so we mirror it on our own infrastructure. <del> # # And as a final point of note, the 32-bit MinGW build using the makefiles do # *not* use debug assertions and llvm assertions. This is because they take # too long on appveyor and this is tested by rustbuild below. </del> - MSYS_BITS: 32 RUST_CONFIGURE_ARGS: --build=i686-pc-windows-gnu --enable-ninja SCRIPT: python x.py test MINGW_URL: https://s3.amazonaws.com/rust-lang-ci/rust-ci-mirror <del> MINGW_ARCHIVE: i686-6.2.0-release-win32-dwarf-rt_v5-rev1.7z </del> <ins> MINGW_ARCHIVE: i686-6.2.0-release-posix-dwarf-rt_v5-rev1.7z </ins> MINGW_DIR: mingw32 - MSYS_BITS: 64 SCRIPT: python x.py test RUST_CONFIGURE_ARGS: --build=x86_64-pc-windows-gnu --enable-ninja MINGW_URL: https://s3.amazonaws.com/rust-lang-ci/rust-ci-mirror <del> MINGW_ARCHIVE: x86_64-6.2.0-release-win32-seh-rt_v5-rev1.7z </del> <ins> MINGW_ARCHIVE: x86_64-6.2.0-release-posix-seh-rt_v5-rev1.7z </ins> MINGW_DIR: mingw64 # 32/64 bit MSVC and GNU deployment


Question: fails on emscripten with the following error message: Thus the test is currently ignored on emscripten. Note: it may be that the failure occurs only on when the test is compiled with optimizations. Note: this happens when using LLVM 4.0 (this issue was opened now to get an issue number to reference).

RUST_CONFIGURE_ARGS: --build=i686-pc-windows-gnu --enable-extended --enable-ninja SCRIPT: python x.py dist MINGW_URL: https://s3.amazonaws.com/rust-lang-ci/rust-ci-mirror <del> MINGW_ARCHIVE: i686-6.2.0-release-win32-dwarf-rt_v5-rev1.7z </del> <ins> MINGW_ARCHIVE: i686-6.2.0-release-posix-dwarf-rt_v5-rev1.7z </ins> MINGW_DIR: mingw32 DEPLOY: 1 - MSYS_BITS: 64 SCRIPT: python x.py dist RUST_CONFIGURE_ARGS: --build=x86_64-pc-windows-gnu --enable-extended --enable-ninja MINGW_URL: https://s3.amazonaws.com/rust-lang-ci/rust-ci-mirror <del> MINGW_ARCHIVE: x86_64-6.2.0-release-win32-seh-rt_v5-rev1.7z </del> <ins> MINGW_ARCHIVE: x86_64-6.2.0-release-posix-seh-rt_v5-rev1.7z </ins> MINGW_DIR: mingw64 DEPLOY: 1


Question: fails on emscripten with the following error message: Thus the test is currently ignored on emscripten. Note: it may be that the failure occurs only on when the test is compiled with optimizations. Note: this happens when using LLVM 4.0 (this issue was opened now to get an issue number to reference).

COPY build-emscripten.sh /tmp/ RUN ./build-emscripten.sh ENV PATH=$PATH:/tmp/emsdk_portable <del> ENV PATH=$PATH:/tmp/emsdk_portable/clang/tag-e1.37.1/build_tag-e1.37.1_32/bin </del> <ins> ENV PATH=$PATH:/tmp/emsdk_portable/clang/tag-e1.37.10/build_tag-e1.37.10_32/bin </ins> ENV PATH=$PATH:/tmp/emsdk_portable/node/4.1.1_32bit/bin <del> ENV PATH=$PATH:/tmp/emsdk_portable/emscripten/tag-1.37.1 ENV EMSCRIPTEN=/tmp/emsdk_portable/emscripten/tag-1.37.1 </del> <ins> ENV PATH=$PATH:/tmp/emsdk_portable/emscripten/tag-1.37.10 ENV EMSCRIPTEN=/tmp/emsdk_portable/emscripten/tag-1.37.10 </ins> ENV RUST_CONFIGURE_ARGS --target=asmjs-unknown-emscripten


Question: fails on emscripten with the following error message: Thus the test is currently ignored on emscripten. Note: it may be that the failure occurs only on when the test is compiled with optimizations. Note: this happens when using LLVM 4.0 (this issue was opened now to get an issue number to reference).

source emsdk_portable/emsdk_env.sh hide_output emsdk update <del> hide_output emsdk install --build=Release sdk-tag-1.37.1-32bit hide_output emsdk activate --build=Release sdk-tag-1.37.1-32bit </del> <ins> hide_output emsdk install --build=Release sdk-tag-1.37.10-32bit hide_output emsdk activate --build=Release sdk-tag-1.37.10-32bit </ins>


Question: fails on emscripten with the following error message: Thus the test is currently ignored on emscripten. Note: it may be that the failure occurs only on when the test is compiled with optimizations. Note: this happens when using LLVM 4.0 (this issue was opened now to get an issue number to reference).

<del> Subproject commit d30da544a8afc5d78391dee270bdf40e74a215d3 </del> <ins> Subproject commit c8a8767c56ad3d3f4eb45c87b95026936fb9aa35 </ins>


Question: fails on emscripten with the following error message: Thus the test is currently ignored on emscripten. Note: it may be that the failure occurs only on when the test is compiled with optimizations. Note: this happens when using LLVM 4.0 (this issue was opened now to get an issue number to reference).

} if target.contains("arm") && !target.contains("ios") { <ins> // (At least) udivsi3.S is broken for Thumb 1 which our gcc uses by // default, we don't want Thumb 2 since it isn't supported on some // devices, so disable thumb entirely. // Upstream bug: https://bugs.llvm.org/show_bug.cgi?id=32492 cfg.define("__ARM_ARCH_ISA_THUMB", Some("0")); </ins> sources.extend(&["arm/aeabi_cdcmp.S", "arm/aeabi_cdcmpeq_check_nan.c", "arm/aeabi_cfcmp.S",


Question: fails on emscripten with the following error message: Thus the test is currently ignored on emscripten. Note: it may be that the failure occurs only on when the test is compiled with optimizations. Note: this happens when using LLVM 4.0 (this issue was opened now to get an issue number to reference).

<del> Subproject commit 2e951c3ae354bcbd2e50b30798e232949a926b75 </del> <ins> Subproject commit a884d21cc5f0b23a1693d1e872fd8998a4fdd17f </ins>


Question: fails on emscripten with the following error message: Thus the test is currently ignored on emscripten. Note: it may be that the failure occurs only on when the test is compiled with optimizations. Note: this happens when using LLVM 4.0 (this issue was opened now to get an issue number to reference).

// write_volatile causes an LLVM assert with composite types <ins> // ignore-emscripten See #41299: probably a bad optimization </ins> #![feature(volatile)] use std::ptr::{read_volatile, write_volatile};


Question: fails on emscripten with the following error message: Thus the test is currently ignored on emscripten. Note: it may be that the failure occurs only on when the test is compiled with optimizations. Note: this happens when using LLVM 4.0 (this issue was opened now to get an issue number to reference).

exit_success_if_unwind::bar(do_panic); } } <del> let s = Command::new(env::args_os().next().unwrap()).arg("foo").status(); </del> <ins> let mut cmd = Command::new(env::args_os().next().unwrap()); cmd.arg("foo"); // ARMv6 hanges while printing the backtrace, see #41004 if cfg!(target_arch = "arm") && cfg!(target_env = "gnu") { cmd.env("RUST_BACKTRACE", "0"); } let s = cmd.status(); </ins> assert!(s.unwrap().code() != Some(0)); }


Question: fails on emscripten with the following error message: Thus the test is currently ignored on emscripten. Note: it may be that the failure occurs only on when the test is compiled with optimizations. Note: this happens when using LLVM 4.0 (this issue was opened now to get an issue number to reference).

panic!("try to catch me"); } } <del> let s = Command::new(env::args_os().next().unwrap()).arg("foo").status(); </del> <ins> let mut cmd = Command::new(env::args_os().next().unwrap()); cmd.arg("foo"); // ARMv6 hanges while printing the backtrace, see #41004 if cfg!(target_arch = "arm") && cfg!(target_env = "gnu") { cmd.env("RUST_BACKTRACE", "0"); } let s = cmd.status(); </ins> assert!(s.unwrap().code() != Some(0)); }


Question:
hi, my code used to compile last week. I updated the compiler today and now it crashes note that you can get my code here ()
note: going back to nightly-2017-04-01; everything work again. 'nightly-2017-04-17 is not ok. so troubles started somewhere in between.
cc
not too sure what to do with this message. can I help you with something ? I can do a small dichotomy to figure out the last working nightly if this can help.
Minified:
there is a pending fix (), no action needed on your part
triage: P-high

// So peel off one-level, turning the &T into T. match base_ty.builtin_deref(false, ty::NoPreference) { Some(t) => t.ty, <del> None => { return Err(()); } </del> <ins> None => { debug!("By-ref binding of non-derefable type {:?}", base_ty); return Err(()); } </ins> } } _ => base_ty,


Question:
hi, my code used to compile last week. I updated the compiler today and now it crashes note that you can get my code here ()
note: going back to nightly-2017-04-01; everything work again. 'nightly-2017-04-17 is not ok. so troubles started somewhere in between.
cc
not too sure what to do with this message. can I help you with something ? I can do a small dichotomy to figure out the last working nightly if this can help.
Minified:
there is a pending fix (), no action needed on your part
triage: P-high

match base_cmt.ty.builtin_index() { Some(ty) => (ty, ElementKind::VecElement), None => { <ins> debug!("Explicit index of non-indexable type {:?}", base_cmt); </ins> return Err(()); } }


Question:
hi, my code used to compile last week. I updated the compiler today and now it crashes note that you can get my code here ()
note: going back to nightly-2017-04-01; everything work again. 'nightly-2017-04-17 is not ok. so troubles started somewhere in between.
cc
not too sure what to do with this message. can I help you with something ? I can do a small dichotomy to figure out the last working nightly if this can help.
Minified:
there is a pending fix (), no action needed on your part
triage: P-high

PatKind::TupleStruct(hir::QPath::Resolved(_, ref path), ..) | PatKind::Struct(hir::QPath::Resolved(_, ref path), ..) => { match path.def { <del> Def::Err => return Err(()), </del> <ins> Def::Err => { debug!("access to unresolvable pattern {:?}", pat); return Err(()) } </ins> Def::Variant(variant_did) | Def::VariantCtor(variant_did, ..) => { // univariant enums do not need downcasts


Question:
hi, my code used to compile last week. I updated the compiler today and now it crashes note that you can get my code here ()
note: going back to nightly-2017-04-01; everything work again. 'nightly-2017-04-17 is not ok. so troubles started somewhere in between.
cc
not too sure what to do with this message. can I help you with something ? I can do a small dichotomy to figure out the last working nightly if this can help.
Minified:
there is a pending fix (), no action needed on your part
triage: P-high

panic!(ExplicitBug); } pub fn delay_span_bug<S: Into<MultiSpan>>(&self, sp: S, msg: &str) { <ins> if self.treat_err_as_bug { self.span_bug(sp, msg); } </ins> let mut delayed = self.delayed_span_bug.borrow_mut(); *delayed = Some((sp.into(), msg.to_string())); }


Question:
hi, my code used to compile last week. I updated the compiler today and now it crashes note that you can get my code here ()
note: going back to nightly-2017-04-01; everything work again. 'nightly-2017-04-17 is not ok. so troubles started somewhere in between.
cc
not too sure what to do with this message. can I help you with something ? I can do a small dichotomy to figure out the last working nightly if this can help.
Minified:
there is a pending fix (), no action needed on your part
triage: P-high

}; let index_expr_ty = self.node_ty(index_expr.id); <ins> let adjusted_base_ty = self.resolve_type_vars_if_possible(&adjusted_base_ty); let index_expr_ty = self.resolve_type_vars_if_possible(&index_expr_ty); </ins> let result = self.try_index_step(ty::MethodCall::expr(expr.id), expr,


Question:
hi, my code used to compile last week. I updated the compiler today and now it crashes note that you can get my code here ()
note: going back to nightly-2017-04-01; everything work again. 'nightly-2017-04-17 is not ok. so troubles started somewhere in between.
cc
not too sure what to do with this message. can I help you with something ? I can do a small dichotomy to figure out the last working nightly if this can help.
Minified:
there is a pending fix (), no action needed on your part
triage: P-high

let expr_ty = self.node_ty(expr.id); self.demand_suptype(expr.span, expr_ty, return_ty); <ins> } else { // We could not perform a mutable index. Re-apply the // immutable index adjustments - borrowck will detect // this as an error. if let Some(adjustment) = adjustment { self.apply_adjustment(expr.id, adjustment); } self.tcx.sess.delay_span_bug( expr.span, "convert_lvalue_derefs_to_mutable failed"); </ins> } } hir::ExprUnary(hir::UnDeref, ref base_expr) => {


Question:
hi, my code used to compile last week. I updated the compiler today and now it crashes note that you can get my code here ()
note: going back to nightly-2017-04-01; everything work again. 'nightly-2017-04-17 is not ok. so troubles started somewhere in between.
cc
not too sure what to do with this message. can I help you with something ? I can do a small dichotomy to figure out the last working nightly if this can help.
Minified:
there is a pending fix (), no action needed on your part
triage: P-high

<ins> // Copyright 2017 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. // regression test for issue #41498. struct S; impl S { fn mutate(&mut self) {} } fn call_and_ref<T, F: FnOnce() -> T>(x: &mut Option<T>, f: F) -> &mut T { *x = Some(f()); x.as_mut().unwrap() } fn main() { let mut n = None; call_and_ref(&mut n, || [S])[0].mutate(); } </ins>


Question:
running yields Happening on . Did not happen on the latest nightly available through rustup on 27.04.2017.
Last working nightly: First broken nightly: .
maybe it was ? cc
could be. let me try it on my big MIR refactoring branch =)
I confirm that the error occurs at but not at So it looks to me like is indeed the culprit.
Yes. I can reproduce. Will investigate.
I see the problem. PR coming soon.
Fix at
I'm still seeing this issue, on the latest nightly and on master.
can you give more details of how you are reproducing the problem? (I a test for the precise scenario reported, so I'm reasonably sure it's not that case anymore.)
Hmm, perhaps my regression test wasn't sufficient. I see I used ; I remember that the test did fail, but I guess that it passing doesn't prove all issues are resolved. =)
The earliest commit where I can reproduce this problem is

use rustc::mir::*; use rustc::mir::transform::{MirSuite, MirPassIndex, MirSource}; use rustc::ty::TyCtxt; <ins> use rustc::ty::item_path; </ins> use rustc_data_structures::fx::FxHashMap; use rustc_data_structures::indexed_vec::{Idx}; use std::fmt::Display;


Question:
running yields Happening on . Did not happen on the latest nightly available through rustup on 27.04.2017.
Last working nightly: First broken nightly: .
maybe it was ? cc
could be. let me try it on my big MIR refactoring branch =)
I confirm that the error occurs at but not at So it looks to me like is indeed the culprit.
Yes. I can reproduce. Will investigate.
I see the problem. PR coming soon.
Fix at
I'm still seeing this issue, on the latest nightly and on master.
can you give more details of how you are reproducing the problem? (I a test for the precise scenario reported, so I'm reasonably sure it's not that case anymore.)
Hmm, perhaps my regression test wasn't sufficient. I see I used ; I remember that the test did fail, but I guess that it passing doesn't prove all issues are resolved. =)
The earliest commit where I can reproduce this problem is

return; } <del> let node_path = tcx.item_path_str(tcx.hir.local_def_id(source.item_id())); </del> <ins> let node_path = item_path::with_forced_impl_filename_line(|| { // see notes on #41697 below tcx.item_path_str(tcx.hir.local_def_id(source.item_id())) }); </ins> dump_matched_mir_node(tcx, pass_num, pass_name, &node_path, disambiguator, source, mir); for (index, promoted_mir) in mir.promoted.iter_enumerated() {


Question:
running yields Happening on . Did not happen on the latest nightly available through rustup on 27.04.2017.
Last working nightly: First broken nightly: .
maybe it was ? cc
could be. let me try it on my big MIR refactoring branch =)
I confirm that the error occurs at but not at So it looks to me like is indeed the culprit.
Yes. I can reproduce. Will investigate.
I see the problem. PR coming soon.
Fix at
I'm still seeing this issue, on the latest nightly and on master.
can you give more details of how you are reproducing the problem? (I a test for the precise scenario reported, so I'm reasonably sure it's not that case anymore.)
Hmm, perhaps my regression test wasn't sufficient. I see I used ; I remember that the test did fail, but I guess that it passing doesn't prove all issues are resolved. =)
The earliest commit where I can reproduce this problem is

Some(ref filters) => filters, }; let node_id = source.item_id(); <del> let node_path = tcx.item_path_str(tcx.hir.local_def_id(node_id)); </del> <ins> let node_path = item_path::with_forced_impl_filename_line(|| { // see notes on #41697 below tcx.item_path_str(tcx.hir.local_def_id(node_id)) }); </ins> filters.split("&") .any(|filter| { filter == "all" ||


Question:
running yields Happening on . Did not happen on the latest nightly available through rustup on 27.04.2017.
Last working nightly: First broken nightly: .
maybe it was ? cc
could be. let me try it on my big MIR refactoring branch =)
I confirm that the error occurs at but not at So it looks to me like is indeed the culprit.
Yes. I can reproduce. Will investigate.
I see the problem. PR coming soon.
Fix at
I'm still seeing this issue, on the latest nightly and on master.
can you give more details of how you are reproducing the problem? (I a test for the precise scenario reported, so I'm reasonably sure it's not that case anymore.)
Hmm, perhaps my regression test wasn't sufficient. I see I used ; I remember that the test did fail, but I guess that it passing doesn't prove all issues are resolved. =)
The earliest commit where I can reproduce this problem is

}) } <ins> // #41697 -- we use `with_forced_impl_filename_line()` because // `item_path_str()` would otherwise trigger `type_of`, and this can // run while we are already attempting to evaluate `type_of`. </ins> fn dump_matched_mir_node<'a, 'tcx>(tcx: TyCtxt<'a, 'tcx, 'tcx>, pass_num: Option<(MirSuite, MirPassIndex)>, pass_name: &str,


Question:
running yields Happening on . Did not happen on the latest nightly available through rustup on 27.04.2017.
Last working nightly: First broken nightly: .
maybe it was ? cc
could be. let me try it on my big MIR refactoring branch =)
I confirm that the error occurs at but not at So it looks to me like is indeed the culprit.
Yes. I can reproduce. Will investigate.
I see the problem. PR coming soon.
Fix at
I'm still seeing this issue, on the latest nightly and on master.
can you give more details of how you are reproducing the problem? (I a test for the precise scenario reported, so I'm reasonably sure it's not that case anymore.)
Hmm, perhaps my regression test wasn't sufficient. I see I used ; I remember that the test did fail, but I guess that it passing doesn't prove all issues are resolved. =)
The earliest commit where I can reproduce this problem is

<ins> // Copyright 2016 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. // compile-flags:-Zdump-mir=NEVER_MATCHED // Regression test for #41697. Using dump-mir was triggering // artificial cycles: during type-checking, we had to get the MIR for // the constant expressions in `[u8; 2]`, which in turn would trigger // an attempt to get the item-path, which in turn would request the // types of the impl, which would trigger a cycle. We supressed this // cycle now by forcing mir-dump to avoid asking for types of an impl. #![feature(rustc_attrs)] use std::sync::Arc; trait Foo { fn get(&self) -> [u8; 2]; } impl Foo for [u8; 2] { fn get(&self) -> [u8; 2] { *self } } struct Bar<T: ?Sized>(T); fn unsize_fat_ptr<'a>(x: &'a Bar<Foo + Send + 'a>) -> &'a Bar<Foo + 'a> { x } fn unsize_nested_fat_ptr(x: Arc<Foo + Send>) -> Arc<Foo> { x } fn main() { let x: Box<Bar<Foo + Send>> = Box::new(Bar([1,2])); assert_eq!(unsize_fat_ptr(&*x).0.get(), [1, 2]); let x: Arc<Foo + Send> = Arc::new([3, 4]); assert_eq!(unsize_nested_fat_ptr(x).get(), [3, 4]); } </ins>


Question:
running yields Happening on . Did not happen on the latest nightly available through rustup on 27.04.2017.
Last working nightly: First broken nightly: .
maybe it was ? cc
could be. let me try it on my big MIR refactoring branch =)
I confirm that the error occurs at but not at So it looks to me like is indeed the culprit.
Yes. I can reproduce. Will investigate.
I see the problem. PR coming soon.
Fix at
I'm still seeing this issue, on the latest nightly and on master.
can you give more details of how you are reproducing the problem? (I a test for the precise scenario reported, so I'm reasonably sure it's not that case anymore.)
Hmm, perhaps my regression test wasn't sufficient. I see I used ; I remember that the test did fail, but I guess that it passing doesn't prove all issues are resolved. =)
The earliest commit where I can reproduce this problem is

output: $output:tt) => { define_map_struct! { tcx: $tcx, <del> ready: ([pub] $attrs $name), </del> <ins> ready: ([] $attrs $name), </ins> input: ($($input)*), output: $output }


Question:
running yields Happening on . Did not happen on the latest nightly available through rustup on 27.04.2017.
Last working nightly: First broken nightly: .
maybe it was ? cc
could be. let me try it on my big MIR refactoring branch =)
I confirm that the error occurs at but not at So it looks to me like is indeed the culprit.
Yes. I can reproduce. Will investigate.
I see the problem. PR coming soon.
Fix at
I'm still seeing this issue, on the latest nightly and on master.
can you give more details of how you are reproducing the problem? (I a test for the precise scenario reported, so I'm reasonably sure it's not that case anymore.)
Hmm, perhaps my regression test wasn't sufficient. I see I used ; I remember that the test did fail, but I guess that it passing doesn't prove all issues are resolved. =)
The earliest commit where I can reproduce this problem is

MirSource::Promoted(_, i) => write!(w, "{:?} in", i)? } <del> write!(w, " {}", tcx.node_path_str(src.item_id()))?; </del> <ins> item_path::with_forced_impl_filename_line(|| { // see notes on #41697 elsewhere write!(w, " {}", tcx.node_path_str(src.item_id())) })?; </ins> if let MirSource::Fn(_) = src { write!(w, "(")?;


Question:
running yields Happening on . Did not happen on the latest nightly available through rustup on 27.04.2017.
Last working nightly: First broken nightly: .
maybe it was ? cc
could be. let me try it on my big MIR refactoring branch =)
I confirm that the error occurs at but not at So it looks to me like is indeed the culprit.
Yes. I can reproduce. Will investigate.
I see the problem. PR coming soon.
Fix at
I'm still seeing this issue, on the latest nightly and on master.
can you give more details of how you are reproducing the problem? (I a test for the precise scenario reported, so I'm reasonably sure it's not that case anymore.)
Hmm, perhaps my regression test wasn't sufficient. I see I used ; I remember that the test did fail, but I guess that it passing doesn't prove all issues are resolved. =)
The earliest commit where I can reproduce this problem is

<ins> // Copyright 2016 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. // Regression test for #41697. Using dump-mir was triggering // artificial cycles: during type-checking, we had to get the MIR for // the constant expressions in `[u8; 2]`, which in turn would trigger // an attempt to get the item-path, which in turn would request the // types of the impl, which would trigger a cycle. We supressed this // cycle now by forcing mir-dump to avoid asking for types of an impl. #![feature(rustc_attrs)] use std::sync::Arc; trait Foo { fn get(&self) -> [u8; 2]; } impl Foo for [u8; 2] { fn get(&self) -> [u8; 2] { *self } } struct Bar<T: ?Sized>(T); fn unsize_fat_ptr<'a>(x: &'a Bar<Foo + Send + 'a>) -> &'a Bar<Foo + 'a> { x } fn unsize_nested_fat_ptr(x: Arc<Foo + Send>) -> Arc<Foo> { x } fn main() { let x: Box<Bar<Foo + Send>> = Box::new(Bar([1,2])); assert_eq!(unsize_fat_ptr(&*x).0.get(), [1, 2]); let x: Arc<Foo + Send> = Arc::new([3, 4]); assert_eq!(unsize_nested_fat_ptr(x).get(), [3, 4]); } </ins>


Question:
running yields Happening on . Did not happen on the latest nightly available through rustup on 27.04.2017.
Last working nightly: First broken nightly: .
maybe it was ? cc
could be. let me try it on my big MIR refactoring branch =)
I confirm that the error occurs at but not at So it looks to me like is indeed the culprit.
Yes. I can reproduce. Will investigate.
I see the problem. PR coming soon.
Fix at
I'm still seeing this issue, on the latest nightly and on master.
can you give more details of how you are reproducing the problem? (I a test for the precise scenario reported, so I'm reasonably sure it's not that case anymore.)
Hmm, perhaps my regression test wasn't sufficient. I see I used ; I remember that the test did fail, but I guess that it passing doesn't prove all issues are resolved. =)
The earliest commit where I can reproduce this problem is

<del> // Copyright 2016 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. // compile-flags:-Zdump-mir=NEVER_MATCHED // Regression test for #41697. Using dump-mir was triggering // artificial cycles: during type-checking, we had to get the MIR for // the constant expressions in `[u8; 2]`, which in turn would trigger // an attempt to get the item-path, which in turn would request the // types of the impl, which would trigger a cycle. We supressed this // cycle now by forcing mir-dump to avoid asking for types of an impl. #![feature(rustc_attrs)] use std::sync::Arc; trait Foo { fn get(&self) -> [u8; 2]; } impl Foo for [u8; 2] { fn get(&self) -> [u8; 2] { *self } } struct Bar<T: ?Sized>(T); fn unsize_fat_ptr<'a>(x: &'a Bar<Foo + Send + 'a>) -> &'a Bar<Foo + 'a> { x } fn unsize_nested_fat_ptr(x: Arc<Foo + Send>) -> Arc<Foo> { x } fn main() { let x: Box<Bar<Foo + Send>> = Box::new(Bar([1,2])); assert_eq!(unsize_fat_ptr(&*x).0.get(), [1, 2]); let x: Arc<Foo + Send> = Arc::new([3, 4]); assert_eq!(unsize_nested_fat_ptr(x).get(), [3, 4]); } </del>


Question:
cc Maybe related to
Also affects eclectica-0.0.9 cc
Also igo-0.2.1 cc
Also isbfc-0.0.1 cc
Also cargo-update-0.8.0 () cc
Also cc
Rust commit: (looks like bug isn't here) Cargo commit: , which seems correct. is the stable/nightly issue, is the PR updating cargo submodule to fix this, which probably needs to be backported to beta. I'm uncertain, though.
cc sorry to tag you in again, but if you could help take a look at this that'd be great! If not no worries!
Hi this definitely looks related to my changes in cargo. I've investigated and this crate defines two bins ( and ). I suppose they were intended to be aliases and this was possible because of a original "bug" in cargo (falling back to ). I have mixed feelings about this. I would say that cargo should fail here instead of falling back to , but I suppose we cannot do that because of backwards compatibility. Right? fails because it defines bin targets inside directly, instead of . Seems easy and I'll try to fix this today in the evening. Could you please provide me with the cargo's output for the other crates (especially )? That would be great.
Ah yeah for now our priority is to stem the breakage, and afterwards we can evaluate warnings cycles/etc to push further towards the desired behavior here. Thanks for investigating this
I think I have fixed this, just need one more day to do some more testing and I should open a pull request tomorrow.
Added a proposed fix.
Ah we should actually leave this open to track the inclusion into beta, I'll close when all the backports are done.
Ok I've , updated our and updated our , this'll get closed when those start merging. Thanks again for fixing this
Ok, I think everything's landed here

let path = @{span: span, global: false, idents: ~[nm], rp: None, types: ~[]}; @{id: self.next_id(), <del> node: ast::pat_ident(ast::bind_by_implicit_ref, </del> <ins> node: ast::pat_ident(ast::bind_by_ref(ast::m_imm), </ins> path, None), span: span}


Question:
cc Maybe related to
Also affects eclectica-0.0.9 cc
Also igo-0.2.1 cc
Also isbfc-0.0.1 cc
Also cargo-update-0.8.0 () cc
Also cc
Rust commit: (looks like bug isn't here) Cargo commit: , which seems correct. is the stable/nightly issue, is the PR updating cargo submodule to fix this, which probably needs to be backported to beta. I'm uncertain, though.
cc sorry to tag you in again, but if you could help take a look at this that'd be great! If not no worries!
Hi this definitely looks related to my changes in cargo. I've investigated and this crate defines two bins ( and ). I suppose they were intended to be aliases and this was possible because of a original "bug" in cargo (falling back to ). I have mixed feelings about this. I would say that cargo should fail here instead of falling back to , but I suppose we cannot do that because of backwards compatibility. Right? fails because it defines bin targets inside directly, instead of . Seems easy and I'll try to fix this today in the evening. Could you please provide me with the cargo's output for the other crates (especially )? That would be great.
Ah yeah for now our priority is to stem the breakage, and afterwards we can evaluate warnings cycles/etc to push further towards the desired behavior here. Thanks for investigating this
I think I have fixed this, just need one more day to do some more testing and I should open a pull request tomorrow.
Added a proposed fix.
Ah we should actually leave this open to track the inclusion into beta, I'll close when all the backports are done.
Ok I've , updated our and updated our , this'll get closed when those start merging. Thanks again for fixing this
Ok, I think everything's landed here

let pat_node = if pats.is_empty() { ast::pat_ident( <del> ast::bind_by_implicit_ref, </del> <ins> ast::bind_by_ref(ast::m_imm), </ins> cx.path(span, ~[v_name]), None )


Question:
cc Maybe related to
Also affects eclectica-0.0.9 cc
Also igo-0.2.1 cc
Also isbfc-0.0.1 cc
Also cargo-update-0.8.0 () cc
Also cc
Rust commit: (looks like bug isn't here) Cargo commit: , which seems correct. is the stable/nightly issue, is the PR updating cargo submodule to fix this, which probably needs to be backported to beta. I'm uncertain, though.
cc sorry to tag you in again, but if you could help take a look at this that'd be great! If not no worries!
Hi this definitely looks related to my changes in cargo. I've investigated and this crate defines two bins ( and ). I suppose they were intended to be aliases and this was possible because of a original "bug" in cargo (falling back to ). I have mixed feelings about this. I would say that cargo should fail here instead of falling back to , but I suppose we cannot do that because of backwards compatibility. Right? fails because it defines bin targets inside directly, instead of . Seems easy and I'll try to fix this today in the evening. Could you please provide me with the cargo's output for the other crates (especially )? That would be great.
Ah yeah for now our priority is to stem the breakage, and afterwards we can evaluate warnings cycles/etc to push further towards the desired behavior here. Thanks for investigating this
I think I have fixed this, just need one more day to do some more testing and I should open a pull request tomorrow.
Added a proposed fix.
Ah we should actually leave this open to track the inclusion into beta, I'll close when all the backports are done.
Ok I've , updated our and updated our , this'll get closed when those start merging. Thanks again for fixing this
Ok, I think everything's landed here

<ins> #[forbid(deprecated_pattern)]; </ins> extern mod std; // These tests used to be separate files, but I wanted to refactor all


Question:
cc Maybe related to
Also affects eclectica-0.0.9 cc
Also igo-0.2.1 cc
Also isbfc-0.0.1 cc
Also cargo-update-0.8.0 () cc
Also cc
Rust commit: (looks like bug isn't here) Cargo commit: , which seems correct. is the stable/nightly issue, is the PR updating cargo submodule to fix this, which probably needs to be backported to beta. I'm uncertain, though.
cc sorry to tag you in again, but if you could help take a look at this that'd be great! If not no worries!
Hi this definitely looks related to my changes in cargo. I've investigated and this crate defines two bins ( and ). I suppose they were intended to be aliases and this was possible because of a original "bug" in cargo (falling back to ). I have mixed feelings about this. I would say that cargo should fail here instead of falling back to , but I suppose we cannot do that because of backwards compatibility. Right? fails because it defines bin targets inside directly, instead of . Seems easy and I'll try to fix this today in the evening. Could you please provide me with the cargo's output for the other crates (especially )? That would be great.
Ah yeah for now our priority is to stem the breakage, and afterwards we can evaluate warnings cycles/etc to push further towards the desired behavior here. Thanks for investigating this
I think I have fixed this, just need one more day to do some more testing and I should open a pull request tomorrow.
Added a proposed fix.
Ah we should actually leave this open to track the inclusion into beta, I'll close when all the backports are done.
Ok I've , updated our and updated our , this'll get closed when those start merging. Thanks again for fixing this
Ok, I think everything's landed here

let ebml_w = &EBWriter::Serializer(wr); a1.serialize(ebml_w) }; <del> let d = EBReader::Doc(@bytes); </del> <ins> let d = EBReader::Doc(@move bytes); </ins> let a2: A = deserialize(&EBReader::Deserializer(d)); assert *a1 == a2; }


Question:
About to submit a PR for exposing intrinsics::needs_drop under mem. Needs a tracking issue. Here it is!
The PR is
fcp merge Seems like this may be good to stabilize!
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [x] No concerns currently listed. Once these reviewers reach consensus, this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period is now complete.

#![feature(core_intrinsics)] #![feature(dropck_eyepatch)] #![feature(generic_param_attrs)] <del> #![feature(needs_drop)] </del> #![cfg_attr(test, feature(test))] #![allow(deprecated)]


Question:
About to submit a PR for exposing intrinsics::needs_drop under mem. Needs a tracking issue. Here it is!
The PR is
fcp merge Seems like this may be good to stabilize!
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [x] No concerns currently listed. Once these reviewers reach consensus, this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period is now complete.

/// Here's an example of how a collection might make use of needs_drop: /// /// ``` <del> /// #![feature(needs_drop)] </del> /// use std::{mem, ptr}; /// /// pub struct MyCollection<T> {


Question:
About to submit a PR for exposing intrinsics::needs_drop under mem. Needs a tracking issue. Here it is!
The PR is
fcp merge Seems like this may be good to stabilize!
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [x] No concerns currently listed. Once these reviewers reach consensus, this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period is now complete.

/// } /// ``` #[inline] <del> #[unstable(feature = "needs_drop", issue = "41890")] </del> <ins> #[stable(feature = "needs_drop", since = "1.22.0")] </ins> pub fn needs_drop<T>() -> bool { unsafe { intrinsics::needs_drop::<T>() } }


Question:
About to submit a PR for exposing intrinsics::needs_drop under mem. Needs a tracking issue. Here it is!
The PR is
fcp merge Seems like this may be good to stabilize!
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [x] No concerns currently listed. Once these reviewers reach consensus, this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period is now complete.

#![feature(macro_reexport)] #![feature(macro_vis_matcher)] #![feature(needs_panic_runtime)] <del> #![feature(needs_drop)] </del> #![feature(never_type)] #![feature(num_bits_bytes)] #![feature(old_wrapping)]


Question: Test case: Compiling this stuck forever in the "expansion" pass. cc ( tracking issue). Since can match "nothing", the macro should error with "repetition matches empty token tree".

TokenTree::Sequence(span, ref seq) => { if seq.separator.is_none() && seq.tts.iter().all(|seq_tt| { match *seq_tt { <ins> TokenTree::MetaVarDecl(_, _, id) => id.name == "vis", </ins> TokenTree::Sequence(_, ref sub_seq) => sub_seq.op == quoted::KleeneOp::ZeroOrMore, _ => false,


Question: Test case: Compiling this stuck forever in the "expansion" pass. cc ( tracking issue). Since can match "nothing", the macro should error with "repetition matches empty token tree".

<ins> // Copyright 2017 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(macro_vis_matcher)] macro_rules! foo { ($($p:vis)*) => {} //~ ERROR repetition matches empty token tree } foo!(a); </ins>