Question:
:
Triage: still an issue.
I just hit this, though the error is a bit different now: "resolving bounds after type-checking" rather than "fulfilling during trans". error: internal compiler error: Encountered errors resolving bounds after type-checking 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: 0x7f91a71b237a - std::sys::imp::backtrace::tracing::imp::write::h944c02ac40aee2d7 at /buildslave/rust-buildbot/slave/nightly-dist-rustc- 2: 0x7f91a71c122f - std::panicking::defaulthook::{{closure}}::h6875a2976258b020 at /buildslave/rust-buildbot/slave/nightly-dist-rustc- 3: 0x7f91a71c0dcd - std::panicking::defaulthook::h88ffbc5922643264 at /buildslave/rust-buildbot/slave/nightly-dist-rustc- 4: 0x7f91a71c16d7 - std::panicking::rustpanicwithhook::ha5aed1dfc0e220e3 at /buildslave/rust-buildbot/slave/nightly-dist-rustc- 5: 0x7f91a67fae4b - std::panicking::beginpanic::h264cdc75d51b518b at /buildslave/rust-buildbot/slave/nightly-dist-rustc- 6: 0x7f91a6817d93 - rustc::session::optspanbugfmt::{{closure}}::h4a9b70c3df8b4b3a at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/<panic macros:3 at /buildslave/rust-buildbot/slave/nightly-dist-rustc- 7: 0x7f91a6817bb6 - rustc::session::spanbugfmt::h0c5d2225aa96fe42 at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- 8: 0x7f91a688fc77 - rustctrans::common::fulfillobligation::{{closure}}::{{closure}}::hf13a4d09f7cbb18e at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- 9: 0x7f91a688c0dc - rustctrans::common::fulfillobligation::h6bfd7b7f15728b60 at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- 10: 0x7f91a6887278 - rustctrans::collector::dostaticdispatch::h9456c98c4201c352 at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- 11: 0x7f91a68868aa - <rustctrans::collector::MirNeighborCollector<'a, 'tcxas rustc::mir::visit::Visitor<'tcx::visitoperand::h7428e8287ff72240 at /buildslave/rust-buildbot/slave/nightly-dist-rustc- 12: 0x7f91a6886fe6 - <rustctrans::collector::MirNeighborCollector<'a, 'tcxas rustc::mir::visit::Visitor<'tcx::visitterminatorkind::h8233aed64e4688ea at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- 13: 0x7f91a6813387 - rustc::mir::visit::Visitor::visitmir::hc23b408d887d8c09 at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- 14: 0x7f91a688524c - rustctrans::collector::collectitemsrec::h9535e33b3068eb29 at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- 15: 0x7f91a68858ff - rustctrans::collector::collectitemsrec::h9535e33b3068eb29 at /buildslave/rust-buildbot/slave/nightly-dist-rustc- 16: 0x7f91a686f200 - rustctrans::base::collectandpartitiontranslationitems::{{closure}}::h9f2b052ae16b5f0b at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- 17: 0x7f91a686b59f - rustctrans::base::collectandpartitiontranslationitems::h6a325f48a6efa8c7 at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- 18: 0x7f91a685ddca - rustctrans::base::transcrate::h6e0b0bf1b66798ce at /buildslave/rust-buildbot/slave/nightly-dist-rustc- 19: 0x7f91a7571401 - rustcdriver::driver::phase4translatetollvm::h48ed91c172294403 at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- 20: 0x7f91a7541c36 - rustcdriver::driver::compileinput::{{closure}}::hf13172fc4e5a2f4d at /buildslave/rust-buildbot/slave/nightly-dist-rustc- 21: 0x7f91a755f503 - rustcdriver::driver::phase3runanalysispasses::{{closure}}::h97a3a12d948df547 at /buildslave/rust-buildbot/slave/nightly-dist-rustc- 22: 0x7f91a7558833 - rustcdriver::driver::phase3runanalysispasses::hb0ad9de18d423e67 at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- 23: 0x7f91a753fb77 - rustcdriver::driver::compileinput::h8e119234b60571d5 at /buildslave/rust-buildbot/slave/nightly-dist-rustc- 24: 0x7f91a7585cd8 - rustcdriver::runcompiler::hbdfc4f84e2e0f4b9 at /buildslave/rust-buildbot/slave/nightly-dist-rustc- 25: 0x7f91a74a1158 - std::panicking::try::docall::hf679f17bf3b43b0b at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- 26: 0x7f91a71cbc1a - _rustmaybecatchpanic at /buildslave/rust-buildbot/slave/nightly-dist-rustc- 27: 0x7f91a74c31b8 - <F as alloc::boxed::FnBox<A::callbox::h506fb5d7b8891cd4 at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- 28: 0x7f91a71c0094 - std::sys::imp::thread::Thread::new::threadstart::h8084b1107992ae5b at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- 29: 0x7f919f3f5709 - start_thread 30: 0x7f91a6e7a82c - clone 31: 0x0 - <unknown
ping how is this unsound?
Given that has seen fit to tag this as a soundness bug I'm nominating it so that it can receive a priority assessment, though I'll second ubsan in asking for a demonstration of the unsoundness here.
In general, having trait bounds that are not checked can lead to unsoundness, since some part of the code will assume that they hold when in fact they do not (consider, e.g., what might happen if the bound were ).
I'm going to mark this as P-medium and tag it from the specialization issue (it is specific to specialization, right?)
triage: P-medium
The code in the OP compiles for me with the latest nightly Rust (1.29.0-nightly ( 2018-08-01)). However, the following still fails (and I assume it's the same issue; if not I can file a new issue): Backtrace:
So I think this is "fixed-by-chalk", but this is fixed-by-chalk in a way that breaks specialization (cc Let's have a more easy-to-understand version of the problem: The problem is the following: our impl needs to prove the where-clause, which in the environment is . holds by (by the impl we are checking), so we can prove that obligation by (which will be a ) that depends on the . Therefore, wfchecking is OK. Therefore, fun. why isn't this a problem every time we have a projection? Normally, rustc normalizes to the real associated type, and then it can't find the , so no problem. With specialization, rustc can't normalize the associated type, so it sees the bug. I can't have a proof for this working, but this seems reasonably likely to work. way that might solve this in the rustc model would be to basically say that for any given trait ref, only the most specialized impl is supposed to be checking the wf requirement (for every trait-ref, there is always a most-specialized impl, so this is OK), and when checking wf, add the associated types for our own impl explicitly to our parameter environment (e.g., add - note no quantification over - to the param env in our example). That will make things normalize and work, and I'm not even sure is particularly ugly. I don't think it is less sound than , but then I don't quite know when is sound. what's going on with Chalk? Last time I saw it, the way we made implied bounds work was to move to the environment - in rustc terms, basically only allow it if we have proven the impl using . This solves the problem, because our impl was proven in a well-formed way, so a will ensure we make progress and there will be no cycles. The reason this does not work in specialization, is that we do want users to be able to prove things like , even while they might not know what is. For that, they need to have a keyed off a . I have no idea how to do this in the Chalk model. Was Chalk changed to do something else by now? Does this have a different interaction with specialization?
A PoC to show the unsoundness of this. It's a use-after free by 'copying' a String: Link to the playground:
This is fixed now: and needs a test

<ins> #![allow(incomplete_features)] #![feature(const_generics)] #![feature(const_evaluatable_checked)] #![feature(specialization)] pub trait Trait { type Type; } impl<T: ?Sized> Trait for T { default type Type = [u8; 1]; } impl<T: Trait> Trait for *const T { type Type = [u8; std::mem::size_of::<<T as Trait>::Type>()]; //~^ ERROR: unconstrained generic constant } fn main() {} </ins>


Question:
:
Triage: still an issue.
I just hit this, though the error is a bit different now: "resolving bounds after type-checking" rather than "fulfilling during trans". error: internal compiler error: Encountered errors resolving bounds after type-checking 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: 0x7f91a71b237a - std::sys::imp::backtrace::tracing::imp::write::h944c02ac40aee2d7 at /buildslave/rust-buildbot/slave/nightly-dist-rustc- 2: 0x7f91a71c122f - std::panicking::defaulthook::{{closure}}::h6875a2976258b020 at /buildslave/rust-buildbot/slave/nightly-dist-rustc- 3: 0x7f91a71c0dcd - std::panicking::defaulthook::h88ffbc5922643264 at /buildslave/rust-buildbot/slave/nightly-dist-rustc- 4: 0x7f91a71c16d7 - std::panicking::rustpanicwithhook::ha5aed1dfc0e220e3 at /buildslave/rust-buildbot/slave/nightly-dist-rustc- 5: 0x7f91a67fae4b - std::panicking::beginpanic::h264cdc75d51b518b at /buildslave/rust-buildbot/slave/nightly-dist-rustc- 6: 0x7f91a6817d93 - rustc::session::optspanbugfmt::{{closure}}::h4a9b70c3df8b4b3a at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/<panic macros:3 at /buildslave/rust-buildbot/slave/nightly-dist-rustc- 7: 0x7f91a6817bb6 - rustc::session::spanbugfmt::h0c5d2225aa96fe42 at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- 8: 0x7f91a688fc77 - rustctrans::common::fulfillobligation::{{closure}}::{{closure}}::hf13a4d09f7cbb18e at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- 9: 0x7f91a688c0dc - rustctrans::common::fulfillobligation::h6bfd7b7f15728b60 at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- 10: 0x7f91a6887278 - rustctrans::collector::dostaticdispatch::h9456c98c4201c352 at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- 11: 0x7f91a68868aa - <rustctrans::collector::MirNeighborCollector<'a, 'tcxas rustc::mir::visit::Visitor<'tcx::visitoperand::h7428e8287ff72240 at /buildslave/rust-buildbot/slave/nightly-dist-rustc- 12: 0x7f91a6886fe6 - <rustctrans::collector::MirNeighborCollector<'a, 'tcxas rustc::mir::visit::Visitor<'tcx::visitterminatorkind::h8233aed64e4688ea at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- 13: 0x7f91a6813387 - rustc::mir::visit::Visitor::visitmir::hc23b408d887d8c09 at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- 14: 0x7f91a688524c - rustctrans::collector::collectitemsrec::h9535e33b3068eb29 at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- 15: 0x7f91a68858ff - rustctrans::collector::collectitemsrec::h9535e33b3068eb29 at /buildslave/rust-buildbot/slave/nightly-dist-rustc- 16: 0x7f91a686f200 - rustctrans::base::collectandpartitiontranslationitems::{{closure}}::h9f2b052ae16b5f0b at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- 17: 0x7f91a686b59f - rustctrans::base::collectandpartitiontranslationitems::h6a325f48a6efa8c7 at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- 18: 0x7f91a685ddca - rustctrans::base::transcrate::h6e0b0bf1b66798ce at /buildslave/rust-buildbot/slave/nightly-dist-rustc- 19: 0x7f91a7571401 - rustcdriver::driver::phase4translatetollvm::h48ed91c172294403 at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- 20: 0x7f91a7541c36 - rustcdriver::driver::compileinput::{{closure}}::hf13172fc4e5a2f4d at /buildslave/rust-buildbot/slave/nightly-dist-rustc- 21: 0x7f91a755f503 - rustcdriver::driver::phase3runanalysispasses::{{closure}}::h97a3a12d948df547 at /buildslave/rust-buildbot/slave/nightly-dist-rustc- 22: 0x7f91a7558833 - rustcdriver::driver::phase3runanalysispasses::hb0ad9de18d423e67 at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- 23: 0x7f91a753fb77 - rustcdriver::driver::compileinput::h8e119234b60571d5 at /buildslave/rust-buildbot/slave/nightly-dist-rustc- 24: 0x7f91a7585cd8 - rustcdriver::runcompiler::hbdfc4f84e2e0f4b9 at /buildslave/rust-buildbot/slave/nightly-dist-rustc- 25: 0x7f91a74a1158 - std::panicking::try::docall::hf679f17bf3b43b0b at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- 26: 0x7f91a71cbc1a - _rustmaybecatchpanic at /buildslave/rust-buildbot/slave/nightly-dist-rustc- 27: 0x7f91a74c31b8 - <F as alloc::boxed::FnBox<A::callbox::h506fb5d7b8891cd4 at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- 28: 0x7f91a71c0094 - std::sys::imp::thread::Thread::new::threadstart::h8084b1107992ae5b at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- at /buildslave/rust-buildbot/slave/nightly-dist-rustc- 29: 0x7f919f3f5709 - start_thread 30: 0x7f91a6e7a82c - clone 31: 0x0 - <unknown
ping how is this unsound?
Given that has seen fit to tag this as a soundness bug I'm nominating it so that it can receive a priority assessment, though I'll second ubsan in asking for a demonstration of the unsoundness here.
In general, having trait bounds that are not checked can lead to unsoundness, since some part of the code will assume that they hold when in fact they do not (consider, e.g., what might happen if the bound were ).
I'm going to mark this as P-medium and tag it from the specialization issue (it is specific to specialization, right?)
triage: P-medium
The code in the OP compiles for me with the latest nightly Rust (1.29.0-nightly ( 2018-08-01)). However, the following still fails (and I assume it's the same issue; if not I can file a new issue): Backtrace:
So I think this is "fixed-by-chalk", but this is fixed-by-chalk in a way that breaks specialization (cc Let's have a more easy-to-understand version of the problem: The problem is the following: our impl needs to prove the where-clause, which in the environment is . holds by (by the impl we are checking), so we can prove that obligation by (which will be a ) that depends on the . Therefore, wfchecking is OK. Therefore, fun. why isn't this a problem every time we have a projection? Normally, rustc normalizes to the real associated type, and then it can't find the , so no problem. With specialization, rustc can't normalize the associated type, so it sees the bug. I can't have a proof for this working, but this seems reasonably likely to work. way that might solve this in the rustc model would be to basically say that for any given trait ref, only the most specialized impl is supposed to be checking the wf requirement (for every trait-ref, there is always a most-specialized impl, so this is OK), and when checking wf, add the associated types for our own impl explicitly to our parameter environment (e.g., add - note no quantification over - to the param env in our example). That will make things normalize and work, and I'm not even sure is particularly ugly. I don't think it is less sound than , but then I don't quite know when is sound. what's going on with Chalk? Last time I saw it, the way we made implied bounds work was to move to the environment - in rustc terms, basically only allow it if we have proven the impl using . This solves the problem, because our impl was proven in a well-formed way, so a will ensure we make progress and there will be no cycles. The reason this does not work in specialization, is that we do want users to be able to prove things like , even while they might not know what is. For that, they need to have a keyed off a . I have no idea how to do this in the Chalk model. Was Chalk changed to do something else by now? Does this have a different interaction with specialization?
A PoC to show the unsoundness of this. It's a use-after free by 'copying' a String: Link to the playground:
This is fixed now: and needs a test

<ins> error: unconstrained generic constant --> $DIR/issue-51892.rs:15:5 | LL |     type Type = [u8; std::mem::size_of::<<T as Trait>::Type>()]; |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = help: try adding a `where` bound using this expression: `where [(); std::mem::size_of::<<T as Trait>::Type>()]:` error: aborting due to previous error </ins>


Question:
We've always been unsure how much information to show about implementations, and right now, we only show signatures. someone suggested that including the summary line would be helpful, so that you can understand what these things actually do, if you haven't used that particular trait before.
Perhaps we should somehow link to the full description? With a [read more]-like link
Reducing the amount of link chasing necessary to understand what a function does sounds like a good idea, and I agree with that a "read more" link should be included. The question then is how much of the description to include. First sentence? Some arbitrary number of characters?

Ok(()) }  fn document_short(w: &mut fmt::Formatter, item: &clean::Item, link: AssocItemLink) -> fmt::Result { if let Some(s) = item.doc_value() { let markdown = if s.contains('n') { format!("{} [Read more]({})", &plain_summary_line(Some(s)), naive_assoc_href(item, link)) } else { format!("{}", &plain_summary_line(Some(s))) }; write!(w, "
{}
", Markdown(&markdown))?; } Ok(()) }  fn item_module(w: &mut fmt::Formatter, cx: &Context, item: &clean::Item, items: &[clean::Item]) -> fmt::Result { document(w, cx, item)?;


Question:
We've always been unsure how much information to show about implementations, and right now, we only show signatures. someone suggested that including the summary line would be helpful, so that you can understand what these things actually do, if you haven't used that particular trait before.
Perhaps we should somehow link to the full description? With a [read more]-like link
Reducing the amount of link chasing necessary to understand what a function does sounds like a good idea, and I agree with that a "read more" link should be included. The question then is how much of the description to include. First sentence? Some arbitrary number of characters?

} fn doctraititem(w: &mut fmt::Formatter, cx: &Context, item: &clean::Item, <del> link: AssocItemLink, render_static: bool, is_default_item: bool, outer_version: Option<&str>) -> fmt::Result { </del> <ins> link: AssocItemLink, render_static: bool, is_default_item: bool, outer_version: Option<&str>, trait_: Option<&clean::Trait>) -> fmt::Result { </ins> let shortty = shortty(item); let name = item.name.as_ref().unwrap();


Question:
We've always been unsure how much information to show about implementations, and right now, we only show signatures. someone suggested that including the summary line would be helpful, so that you can understand what these things actually do, if you haven't used that particular trait before.
Perhaps we should somehow link to the full description? With a [read more]-like link
Reducing the amount of link chasing necessary to understand what a function does sounds like a good idea, and I agree with that a "read more" link should be included. The question then is how much of the description to include. First sentence? Some arbitrary number of characters?

_ => panic!("can't make docs for trait item with name {:?}", item.name) } <del> if !is_default_item && (!is_static || render_static) { document(w, cx, item) } else { Ok(()) </del> <ins> if !is_static || render_static { if !is_default_item { if item.doc_value().is_some() { document(w, cx, item)?; } else { // In case the item isn't documented, // provide short documentation from the trait if let Some(t) = trait_ { if let Some(it) = t.items.iter() .find(|i| i.name == item.name) { document_short(w, it, link)?; } } } } else { document_short(w, item, link)?; } </ins> } <ins> Ok(()) </ins> } <ins> let traits = &cache().traits; let trait_ = i.trait_did().and_then(|did| traits.get(&did)); </ins> write!(w, "<div class='impl-items'>")?; for trait_item in &i.inner_impl().items { <del> doctraititem(w, cx, trait_item, link, render_header, false, outer_version)?; </del> <ins> doctraititem(w, cx, trait_item, link, render_header, false, outer_version, trait_)?; </ins> } fn render_default_items(w: &mut fmt::Formatter,


Question:
We've always been unsure how much information to show about implementations, and right now, we only show signatures. someone suggested that including the summary line would be helpful, so that you can understand what these things actually do, if you haven't used that particular trait before.
Perhaps we should somehow link to the full description? With a [read more]-like link
Reducing the amount of link chasing necessary to understand what a function does sounds like a good idea, and I agree with that a "read more" link should be included. The question then is how much of the description to include. First sentence? Some arbitrary number of characters?

let assoc_link = AssocItemLink::GotoSource(did, &i.provided_trait_methods); doctraititem(w, cx, trait_item, assoc_link, render_static, true, <del> outer_version)?; </del> <ins> outer_version, None)?; </ins> } Ok(()) } // If we've implemented a trait, then also emit documentation for all // default items which weren't overridden in the implementation block. <del> if let Some(did) = i.trait_did() { if let Some(t) = cache().traits.get(&did) { render_default_items(w, cx, t, &i.inner_impl(), render_header, outer_version)?; } </del> <ins> if let Some(t) = trait_ { render_default_items(w, cx, t, &i.inner_impl(), render_header, outer_version)?; </ins> } write!(w, "</div>")?; Ok(())


Question:
We've always been unsure how much information to show about implementations, and right now, we only show signatures. someone suggested that including the summary line would be helpful, so that you can understand what these things actually do, if you haven't used that particular trait before.
Perhaps we should somehow link to the full description? With a [read more]-like link
Reducing the amount of link chasing necessary to understand what a function does sounds like a good idea, and I agree with that a "read more" link should be included. The question then is how much of the description to include. First sentence? Some arbitrary number of characters?

fn b_method(&self) -> usize { self.a_method() } <ins> /// Docs associated with the trait c_method definition. /// /// There is another line fn c_method(&self) -> usize { self.a_method() } </ins> } // @has manual_impl/struct.S1.html '//*[@class="trait"]' 'T' // @has  - '//*[@class="docblock"]' 'Docs associated with the S1 trait implementation.' // @has  - '//*[@class="docblock"]' 'Docs associated with the S1 trait a_method implementation.' // @!has - '//*[@class="docblock"]' 'Docs associated with the trait a_method definition.' <del> // @!has - '//*[@class="docblock"]' 'Docs associated with the trait b_method definition.' </del> <ins> // @has - '//*[@class="docblock"]' 'Docs associated with the trait b_method definition.' // @has - '//*[@class="docblock"]' 'Docs associated with the trait b_method definition.' // @has - '//*[@class="docblock"]' 'Docs associated with the trait c_method definition.' // @!has - '//*[@class="docblock"]' 'There is another line' // @has - '//*[@class="docblock"]' 'Read more' </ins> pub struct S1(usize); /// Docs associated with the S1 trait implementation.


Question:
We've always been unsure how much information to show about implementations, and right now, we only show signatures. someone suggested that including the summary line would be helpful, so that you can understand what these things actually do, if you haven't used that particular trait before.
Perhaps we should somehow link to the full description? With a [read more]-like link
Reducing the amount of link chasing necessary to understand what a function does sounds like a good idea, and I agree with that a "read more" link should be included. The question then is how much of the description to include. First sentence? Some arbitrary number of characters?

// @has manual_impl/struct.S2.html '//*[@class="trait"]' 'T' // @has  - '//*[@class="docblock"]' 'Docs associated with the S2 trait implementation.' // @has  - '//*[@class="docblock"]' 'Docs associated with the S2 trait a_method implementation.' <del> // @has  - '//*[@class="docblock"]' 'Docs associated with the S2 trait b_method implementation.' </del> <ins> // @has  - '//*[@class="docblock"]' 'Docs associated with the S2 trait c_method implementation.' </ins> // @!has - '//*[@class="docblock"]' 'Docs associated with the trait a_method definition.' <del> // @!has - '//*[@class="docblock"]' 'Docs associated with the trait b_method definition.' </del> <ins> // @!has - '//*[@class="docblock"]' 'Docs associated with the trait c_method definition.' // @has - '//*[@class="docblock"]' 'Docs associated with the trait b_method definition.' // @!has - '//*[@class="docblock"]' 'Read more' </ins> pub struct S2(usize); /// Docs associated with the S2 trait implementation.


Question:
We've always been unsure how much information to show about implementations, and right now, we only show signatures. someone suggested that including the summary line would be helpful, so that you can understand what these things actually do, if you haven't used that particular trait before.
Perhaps we should somehow link to the full description? With a [read more]-like link
Reducing the amount of link chasing necessary to understand what a function does sounds like a good idea, and I agree with that a "read more" link should be included. The question then is how much of the description to include. First sentence? Some arbitrary number of characters?

self.0 } <del> /// Docs associated with the S2 trait b_method implementation. fn b_method(&self) -> usize { </del> <ins> /// Docs associated with the S2 trait c_method implementation. fn c_method(&self) -> usize { </ins> 5 } }


Question:
We've always been unsure how much information to show about implementations, and right now, we only show signatures. someone suggested that including the summary line would be helpful, so that you can understand what these things actually do, if you haven't used that particular trait before.
Perhaps we should somehow link to the full description? With a [read more]-like link
Reducing the amount of link chasing necessary to understand what a function does sounds like a good idea, and I agree with that a "read more" link should be included. The question then is how much of the description to include. First sentence? Some arbitrary number of characters?

// @has manual_impl/struct.S3.html '//*[@class="trait"]' 'T' // @has  - '//*[@class="docblock"]' 'Docs associated with the S3 trait implementation.' // @has  - '//*[@class="docblock"]' 'Docs associated with the S3 trait b_method implementation.' <del> // @!has - '//*[@class="docblock"]' 'Docs associated with the trait a_method definition.' </del> <ins> // @has - '//*[@class="docblock"]' 'Docs associated with the trait a_method definition.' </ins> pub struct S3(usize); /// Docs associated with the S3 trait implementation.


Question: The following snippet: produces the following error: How is anybody supposed to extract from that one forgot the in the closure? The explanation E0369 doesn't help here. Maybe a better thing for rustc would be to "try" and see if a combination of and would have solved the issue and offer a suggestion of the form "Did you meant to make a reference here?".

use super::FnCtxt; use hir::def_id::DefId; <del> use rustc::ty::{Ty, TypeFoldable, PreferMutLvalue}; </del> <ins> use rustc::ty::{Ty, TypeFoldable, PreferMutLvalue, TypeVariants}; </ins> use rustc::infer::type_variable::TypeVariableOrigin; use syntax::ast; use syntax::symbol::Symbol;


Question: The following snippet: produces the following error: How is anybody supposed to extract from that one forgot the in the closure? The explanation E0369 doesn't help here. Maybe a better thing for rustc would be to "try" and see if a combination of and would have solved the issue and offer a suggestion of the form "Did you meant to make a reference here?".

"binary operation `{}` cannot be applied to type `{}`", op.node.as_str(), lhs_ty); <ins> if let TypeVariants::TyRef(_, ref ty_mut) = lhs_ty.sty { if !self.infcx.type_moves_by_default(ty_mut.ty, lhs_expr.span) && self.lookup_op_method(expr, ty_mut.ty, vec![rhs_ty_var], Symbol::intern(name), trait_def_id, lhs_expr).is_ok() { err.span_note( lhs_expr.span, &format!( "this is a reference of type that `{}` can be applied to,  you need to dereference this variable once for this  operation to work", op.node.as_str())); } } </ins> let missing_trait = match op.node { hir::BiAdd    => Some("std::ops::Add"), hir::BiSub    => Some("std::ops::Sub"),


Question: The following snippet: produces the following error: How is anybody supposed to extract from that one forgot the in the closure? The explanation E0369 doesn't help here. Maybe a better thing for rustc would be to "try" and see if a combination of and would have solved the issue and offer a suggestion of the form "Did you meant to make a reference here?".

<ins> // Copyright 2012-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. fn main() { let v = vec![1, 2, 3, 4, 5, 6, 7, 8, 9]; let vr = v.iter().filter(|x| { x % 2 == 0 //~^ ERROR binary operation `%` cannot be applied to type `&&{integer}` //~| NOTE this is a reference of type that `%` can be applied to //~| NOTE an implementation of `std::ops::Rem` might be missing for `&&{integer}` }); println!("{:?}", vr); } </ins>


Question: The following snippet: produces the following error: How is anybody supposed to extract from that one forgot the in the closure? The explanation E0369 doesn't help here. Maybe a better thing for rustc would be to "try" and see if a combination of and would have solved the issue and offer a suggestion of the form "Did you meant to make a reference here?".

<ins> // Copyright 2012-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. fn main() { let a: &String = &"1".to_owned(); let b: &str = &"2"; let c = a + b; //~^ ERROR binary operation `+` cannot be applied to type `&std::string::String` //~| NOTE an implementation of `std::ops::Add` might be missing for `&std::string::String` println!("{:?}", c); } </ins>


Question: Check out in mode : This succeeds (when compiled with optimizations) despite having both a and a . is safe from this because at it believes it's mutably borrowed and panics. There's a line in which would catch this with debug assertions enabled, I believe it should be an ( is unstable and likely not performance critical anyway). cc

// Since this Ref exists, we know the borrow flag // is not set to WRITING. let borrow = self.borrow.get(); <del> debug_assert!(borrow != WRITING && borrow != UNUSED); </del> <ins> debug_assert!(borrow != UNUSED); // Prevent the borrow counter from overflowing. assert!(borrow != WRITING); </ins> self.borrow.set(borrow + 1); BorrowRef { borrow: self.borrow } }


Question: . It's been awhile since it's been updated. Here's two changes that haven't been merged into this document yet: Anything else?

the compiler. They are accessible via the `--explain` flag. Each explanation comes with an example of how to trigger it and advice on how to fix it. <ins> Please read [RFC 1567](https://github.com/rust-lang/rfcs/blob/master/text/1567-long-error-codes-explanation-normalization.md) for details on how to format and write long error codes. </ins> * All of them are accessible [online](http://doc.rust-lang.org/error-index.html), which are auto-generated from rustc source code in different places: [librustc](https://github.com/rust-lang/rust/blob/master/src/librustc/diagnostics.rs), <ins> [libsyntax](https://github.com/rust-lang/rust/blob/master/src/libsyntax/diagnostics.rs), </ins> [librustc_borrowck](https://github.com/rust-lang/rust/blob/master/src/librustc_borrowck/diagnostics.rs), [librustc_const_eval](https://github.com/rust-lang/rust/blob/master/src/librustc_const_eval/diagnostics.rs), <del> [librustc_lint](https://github.com/rust-lang/rust/blob/master/src/librustc_lint/types.rs), </del> [librustc_metadata](https://github.com/rust-lang/rust/blob/master/src/librustc_metadata/diagnostics.rs), [librustc_mir](https://github.com/rust-lang/rust/blob/master/src/librustc_mir/diagnostics.rs), [librustc_passes](https://github.com/rust-lang/rust/blob/master/src/librustc_passes/diagnostics.rs), [librustc_privacy](https://github.com/rust-lang/rust/blob/master/src/librustc_privacy/diagnostics.rs), [librustc_resolve](https://github.com/rust-lang/rust/blob/master/src/librustc_resolve/diagnostics.rs), [librustc_trans](https://github.com/rust-lang/rust/blob/master/src/librustc_trans/diagnostics.rs), <ins> [librustc_plugin](https://github.com/rust-lang/rust/blob/master/src/librustc_plugin/diagnostics.rs), </ins> [librustc_typeck](https://github.com/rust-lang/rust/blob/master/src/librustc_typeck/diagnostics.rs). * Explanations have full markdown support. Use it, especially to highlight code with backticks.


Question: . It's been awhile since it's been updated. Here's two changes that haven't been merged into this document yet: Anything else?

* Flags should be orthogonal to each other. For example, if we'd have a json-emitting variant of multiple actions `foo` and `bar`, an additional --json flag is better than adding `--foo-json` and `--bar-json`. <del> * Always give options a long descriptive name, if only for better </del> <ins> * Always give options a long descriptive name, if only for more </ins> understandable compiler scripts. * The `--verbose` flag is for adding verbose information to `rustc` output when not compiling a program. For example, using it with the `--version` flag


Question:
Today I learned that eight to the power of eight is zero. Who'da thunk? Incorrect: :arrowright: :x: :arrowright: :x: :arrowright: :x: Correct: :arrowright: overflow :whitecheckmark: :arrowright: overflow :whitecheckmark: :arrowright: overflow :whitecheckmark: Oddly enough, this one breaks the pattern: :arrowright: overflow :whitecheck_mark: Haven't bothered with further cases; at this point it's probably best to just look at the implementation and see what's going on.
was supposed to fix this; looks like it missed the unsigned version?
says that is on nightly.
I meant that fixed this for pow() on signed integers, but not on unsigned integers; it looks like the implementation is copy-pasted for some reason.
Could I take a stab at this?
Sure; feel free to ask if you have questions.
Is overflow checking off in the libcore tests? It'd be nice to be able to write some standard tests for overflow, but they seem to not panic even on cases that should right now.
Overflow checking in unit tests () reflects whether the whole compiler was built in debug or release mode. If you need to specify the overflow mode, you can use a separate test which explicitly specifies , like .
This has since been fixed, in , which it looks like also a test, so closing.

let mut base = self; let mut acc = 1; <del> let mut prev_base = self; let mut base_oflo = false; while exp > 0 { </del> <ins> while exp > 1 { </ins> if (exp & 1) == 1 { <del> if base_oflo { // ensure overflow occurs in the same manner it // would have otherwise (i.e. signal any exception // it would have otherwise). acc = acc * (prev_base * prev_base); } else { acc = acc * base; } </del> <ins> acc = acc * base; </ins> } <del> prev_base = base; let (new_base, new_base_oflo) = base.overflowing_mul(base); base = new_base; base_oflo = new_base_oflo; </del> exp /= 2; <ins> base = base * base; </ins> } <ins> // Deal with the final bit of the exponent separately, since // squaring the base afterwards is not necessary and may cause a // needless overflow. if exp == 1 { acc = acc * base; } </ins> acc }


Question:
Today I learned that eight to the power of eight is zero. Who'da thunk? Incorrect: :arrowright: :x: :arrowright: :x: :arrowright: :x: Correct: :arrowright: overflow :whitecheckmark: :arrowright: overflow :whitecheckmark: :arrowright: overflow :whitecheckmark: Oddly enough, this one breaks the pattern: :arrowright: overflow :whitecheck_mark: Haven't bothered with further cases; at this point it's probably best to just look at the implementation and see what's going on.
was supposed to fix this; looks like it missed the unsigned version?
says that is on nightly.
I meant that fixed this for pow() on signed integers, but not on unsigned integers; it looks like the implementation is copy-pasted for some reason.
Could I take a stab at this?
Sure; feel free to ask if you have questions.
Is overflow checking off in the libcore tests? It'd be nice to be able to write some standard tests for overflow, but they seem to not panic even on cases that should right now.
Overflow checking in unit tests () reflects whether the whole compiler was built in debug or release mode. If you need to specify the overflow mode, you can use a separate test which explicitly specifies , like .
This has since been fixed, in , which it looks like also a test, so closing.

<ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // error-pattern:thread 'main' panicked at 'attempt to multiply with overflow' // compile-flags: -C debug-assertions fn main() { let _x = 2i32.pow(1024); } </ins>


Question:
Today I learned that eight to the power of eight is zero. Who'da thunk? Incorrect: :arrowright: :x: :arrowright: :x: :arrowright: :x: Correct: :arrowright: overflow :whitecheckmark: :arrowright: overflow :whitecheckmark: :arrowright: overflow :whitecheckmark: Oddly enough, this one breaks the pattern: :arrowright: overflow :whitecheck_mark: Haven't bothered with further cases; at this point it's probably best to just look at the implementation and see what's going on.
was supposed to fix this; looks like it missed the unsigned version?
says that is on nightly.
I meant that fixed this for pow() on signed integers, but not on unsigned integers; it looks like the implementation is copy-pasted for some reason.
Could I take a stab at this?
Sure; feel free to ask if you have questions.
Is overflow checking off in the libcore tests? It'd be nice to be able to write some standard tests for overflow, but they seem to not panic even on cases that should right now.
Overflow checking in unit tests () reflects whether the whole compiler was built in debug or release mode. If you need to specify the overflow mode, you can use a separate test which explicitly specifies , like .
This has since been fixed, in , which it looks like also a test, so closing.

<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. // error-pattern:thread 'main' panicked at 'attempt to multiply with overflow' // compile-flags: -C debug-assertions fn main() { let _x = 2u32.pow(1024); } </ins>


Question:
Today I learned that eight to the power of eight is zero. Who'da thunk? Incorrect: :arrowright: :x: :arrowright: :x: :arrowright: :x: Correct: :arrowright: overflow :whitecheckmark: :arrowright: overflow :whitecheckmark: :arrowright: overflow :whitecheckmark: Oddly enough, this one breaks the pattern: :arrowright: overflow :whitecheck_mark: Haven't bothered with further cases; at this point it's probably best to just look at the implementation and see what's going on.
was supposed to fix this; looks like it missed the unsigned version?
says that is on nightly.
I meant that fixed this for pow() on signed integers, but not on unsigned integers; it looks like the implementation is copy-pasted for some reason.
Could I take a stab at this?
Sure; feel free to ask if you have questions.
Is overflow checking off in the libcore tests? It'd be nice to be able to write some standard tests for overflow, but they seem to not panic even on cases that should right now.
Overflow checking in unit tests () reflects whether the whole compiler was built in debug or release mode. If you need to specify the overflow mode, you can use a separate test which explicitly specifies , like .
This has since been fixed, in , which it looks like also a test, so closing.

<del> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // error-pattern:thread 'main' panicked at 'attempt to multiply with overflow' // compile-flags: -C debug-assertions fn main() { let _x = 2i32.pow(1024); } </del>


Question:
Some days ago, I wrote some code involving char as HashMap key. At that time, char didn't implement the IterBytes trait, so I implemented it locally myself. After updating rust, my code failed to compile with a somewhat less than obvious error. Example: Produces the following errors: Note that there is no way to know that the problem is the duplicate implementation of IterBytes.
Reproduced as of
Bumping to 0.7, though.
Not critical for 0.7. Nominating for milestone 5, production-ready.
accepted for production-ready milestone
Still reproduces: It has a bunch of other non-bug errors too, but it still exhibits this bug.
Accepted for P-high.

// each trait in the system to its implementations. <del> use metadata::csearch::{each_impl, get_impl_trait}; </del> <ins> use metadata::csearch::{each_impl, get_impl_trait, each_implementation_for_trait}; </ins> use metadata::csearch; use middle::ty::get; use middle::ty::{ImplContainer, lookup_item_type, subst};


Question:
Some days ago, I wrote some code involving char as HashMap key. At that time, char didn't implement the IterBytes trait, so I implemented it locally myself. After updating rust, my code failed to compile with a somewhat less than obvious error. Example: Produces the following errors: Note that there is no way to know that the problem is the duplicate implementation of IterBytes.
Reproduced as of
Bumping to 0.7, though.
Not critical for 0.7. Nominating for milestone 5, production-ready.
accepted for production-ready milestone
Still reproduces: It has a bunch of other non-bug errors too, but it still exhibits this bug.
Accepted for P-high.

pub fn check_implementation_coherence_of(&self, trait_def_id: DefId) { // Unify pairs of polytypes. <del> self.iter_impls_of_trait(trait_def_id, |a| { </del> <ins> self.iter_impls_of_trait_local(trait_def_id, |a| { </ins> let implementation_a = a; let polytype_a = self.get_self_type_for_implementation(implementation_a);


Question:
Some days ago, I wrote some code involving char as HashMap key. At that time, char didn't implement the IterBytes trait, so I implemented it locally myself. After updating rust, my code failed to compile with a somewhat less than obvious error. Example: Produces the following errors: Note that there is no way to know that the problem is the duplicate implementation of IterBytes.
Reproduced as of
Bumping to 0.7, though.
Not critical for 0.7. Nominating for milestone 5, production-ready.
accepted for production-ready milestone
Still reproduces: It has a bunch of other non-bug errors too, but it still exhibits this bug.
Accepted for P-high.

if self.polytypes_unify(polytype_a.clone(), polytype_b) { let session = self.crate_context.tcx.sess; session.span_err( <del> self.span_of_impl(implementation_b), </del> <ins> self.span_of_impl(implementation_a), </ins> format!("conflicting implementations for trait `{}`", ty::item_path_str(self.crate_context.tcx, trait_def_id))); <del> session.span_note(self.span_of_impl(implementation_a), "note conflicting implementation here"); </del> <ins> if implementation_b.did.crate == LOCAL_CRATE { session.span_note(self.span_of_impl(implementation_b), "note conflicting implementation here"); } else { let crate_store = self.crate_context.tcx.sess.cstore; let cdata = crate_store.get_crate_data(implementation_b.did.crate); session.note( "conflicting implementation in crate `" + cdata.name + "`"); } </ins> } } })


Question:
Some days ago, I wrote some code involving char as HashMap key. At that time, char didn't implement the IterBytes trait, so I implemented it locally myself. After updating rust, my code failed to compile with a somewhat less than obvious error. Example: Produces the following errors: Note that there is no way to know that the problem is the duplicate implementation of IterBytes.
Reproduced as of
Bumping to 0.7, though.
Not critical for 0.7. Nominating for milestone 5, production-ready.
accepted for production-ready milestone
Still reproduces: It has a bunch of other non-bug errors too, but it still exhibits this bug.
Accepted for P-high.

} pub fn iter_impls_of_trait(&self, trait_def_id: DefId, f: |@Impl|) { <ins> self.iter_impls_of_trait_local(trait_def_id, |x| f(x)); if trait_def_id.crate == LOCAL_CRATE { return; } let crate_store = self.crate_context.tcx.sess.cstore; csearch::each_implementation_for_trait(crate_store, trait_def_id, |impl_def_id| { let implementation = @csearch::get_impl(self.crate_context.tcx, impl_def_id); let _ = lookup_item_type(self.crate_context.tcx, implementation.did); f(implementation); }); } pub fn iter_impls_of_trait_local(&self, trait_def_id: DefId, f: |@Impl|) { </ins> let trait_impls = self.crate_context.tcx.trait_impls.borrow(); match trait_impls.get().find(&trait_def_id) { Some(impls) => {


Question:
Some days ago, I wrote some code involving char as HashMap key. At that time, char didn't implement the IterBytes trait, so I implemented it locally myself. After updating rust, my code failed to compile with a somewhat less than obvious error. Example: Produces the following errors: Note that there is no way to know that the problem is the duplicate implementation of IterBytes.
Reproduced as of
Bumping to 0.7, though.
Not critical for 0.7. Nominating for milestone 5, production-ready.
accepted for production-ready milestone
Still reproduces: It has a bunch of other non-bug errors too, but it still exhibits this bug.
Accepted for P-high.

<ins> // Copyright 2012 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 trait Foo { } impl Foo for int { } </ins>


Question:
Some days ago, I wrote some code involving char as HashMap key. At that time, char didn't implement the IterBytes trait, so I implemented it locally myself. After updating rust, my code failed to compile with a somewhat less than obvious error. Example: Produces the following errors: Note that there is no way to know that the problem is the duplicate implementation of IterBytes.
Reproduced as of
Bumping to 0.7, though.
Not critical for 0.7. Nominating for milestone 5, production-ready.
accepted for production-ready milestone
Still reproduces: It has a bunch of other non-bug errors too, but it still exhibits this bug.
Accepted for P-high.

<ins> // Copyright 2014 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 #3512 - conflicting trait impls in different crates should give a // 'conflicting implementations' error message. // aux-build:trait_impl_conflict.rs extern mod trait_impl_conflict; use trait_impl_conflict::Foo; impl<A> Foo for A { //~^ ERROR conflicting implementations for trait `trait_impl_conflict::Foo` //~^^ ERROR cannot provide an extension implementation where both trait and type are not defined in this crate } fn main() { } </ins>


Question: From: src/test/compile- Error E0164 needs a span_label, updating it from: To:

let &(ref first_arm_pats, _) = &arms[0]; let first_pat = &first_arm_pats[0]; let span = first_pat.span; <del> span_err!(cx.tcx.sess, span, E0165, "irrefutable while-let pattern"); </del> <ins> struct_span_err!(cx.tcx.sess, span, E0165, "irrefutable while-let pattern") .span_label(span, &format!("irrefutable pattern")) .emit(); </ins> }, hir::MatchSource::ForLoopDesugar => {


Question: From: src/test/compile- Error E0164 needs a span_label, updating it from: To:

tcx.sess.add_lint(lint::builtin::MATCH_OF_UNIT_VARIANT_VIA_PAREN_DOTDOT, pat.id, pat.span, msg); } else { <del> span_err!(tcx.sess, pat.span, E0164, "{}", msg); </del> <ins> struct_span_err!(tcx.sess, pat.span, E0164, "{}", msg) .span_label(pat.span, &format!("not a tuple variant or struct")).emit(); </ins> on_error(); } };


Question: From: src/test/compile- Error E0164 needs a span_label, updating it from: To:

.emit(); } Err(CopyImplementationError::HasDestructor) => { <del> span_err!(tcx.sess, span, E0184, </del> <ins> struct_span_err!(tcx.sess, span, E0184, </ins> "the trait `Copy` may not be implemented for this type;  <del> the type has a destructor"); </del> <ins> the type has a destructor") .span_label(span, &format!("Copy not allowed on types with destructors")) .emit(); </ins> } } });


Question: From: src/test/compile- Error E0164 needs a span_label, updating it from: To:

fn bar(foo: Foo) -> u32 { match foo { Foo::B(i) => i, //~ ERROR E0164 <ins> //~| NOTE not a tuple variant or struct </ins> } }


Question: From: src/test/compile- Error E0164 needs a span_label, updating it from: To:

fn main() { let irr = Irrefutable(0); while let Irrefutable(x) = irr { //~ ERROR E0165 <ins> //~| irrefutable pattern </ins> // ... } }


Question: From: src/test/compile- Error E0164 needs a span_label, updating it from: To:

// except according to those terms. #[derive(Copy)] //~ ERROR E0184 <ins> //~| NOTE Copy not allowed on types with destructors //~| NOTE in this expansion of #[derive(Copy)] </ins> struct Foo; impl Drop for Foo {


Question:
Here is a minimum example of the problem. Compilation fails with following error. Which means that the fragment qualifier is not taken into account to choose which variant of the macro is to be used.
Yeah, macros don't do backtracking. You'll need to adjust the matchers to provide some other way to disambiguate.
Yes, I obviously know that I could just put brackets or whatever around one of the patterns to make it distinct. But the whole point of having fragment qualifiers is precisely to distinguish between two otherwise identical patterns. If macros cannot do it although they have the perfect tool for it, then they are stupid and ought to be improved.
It wasn't obvious to me that you knew the workaround -- sorry for assuming! Also see .
Thanks for pointing the PR. It is blocked for now, but I suppose there is still hope. Sorry for being harsh. I have been raging for months over how annoyingly limited and stupid Rust macros are, and I finally found a case general and obvious enough to justify my complaining…
triage: Macros still don't backtrack. I can't find an issue for that, though I do suspect that one exists in some form. Labeling as A-macros, though.
here is (closed).
Closing in favor of -- macro rules do not backtrack.

return Error(span, "missing fragment specifier".to_string()); } } <del> TokenTree::MetaVarDecl(..) => { </del> <ins> TokenTree::MetaVarDecl(_, _, id) => { </ins> // Built-in nonterminals never start with these tokens, // so we can eliminate them from consideration. <del> match *token { token::CloseDelim(_) => {}, _ => bb_eis.push(ei), </del> <ins> if may_begin_with(&*id.name.as_str(), token) { bb_eis.push(ei); </ins> } } seq @ TokenTree::Delimited(..) | seq @ TokenTree::Token(_, DocComment(..)) => {


Question:
Here is a minimum example of the problem. Compilation fails with following error. Which means that the fragment qualifier is not taken into account to choose which variant of the macro is to be used.
Yeah, macros don't do backtracking. You'll need to adjust the matchers to provide some other way to disambiguate.
Yes, I obviously know that I could just put brackets or whatever around one of the patterns to make it distinct. But the whole point of having fragment qualifiers is precisely to distinguish between two otherwise identical patterns. If macros cannot do it although they have the perfect tool for it, then they are stupid and ought to be improved.
It wasn't obvious to me that you knew the workaround -- sorry for assuming! Also see .
Thanks for pointing the PR. It is blocked for now, but I suppose there is still hope. Sorry for being harsh. I have been raging for months over how annoyingly limited and stupid Rust macros are, and I finally found a case general and obvious enough to justify my complaining…
triage: Macros still don't backtrack. I can't find an issue for that, though I do suspect that one exists in some form. Labeling as A-macros, though.
here is (closed).
Closing in favor of -- macro rules do not backtrack.

} } <ins> /// Checks whether a non-terminal may begin with a particular token. /// /// Returning `false` is a *stability guarantee* that such a matcher will *never* begin with that /// token. Be conservative (return true) if not sure. fn may_begin_with(name: &str, token: &Token) -> bool { /// Checks whether the non-terminal may contain a single (non-keyword) identifier. fn may_be_ident(nt: &token::Nonterminal) -> bool { match *nt { token::NtItem(_) | token::NtBlock(_) | token::NtVis(_) => false, _ => true, } } match name { "expr" => token.can_begin_expr(), "ty" => token.can_begin_type(), "ident" => token.is_ident(), "vis" => match *token { // The follow-set of :vis + "priv" keyword + interpolated Token::Comma | Token::Ident(_) | Token::Interpolated(_) => true, _ => token.can_begin_type(), }, "block" => match *token { Token::OpenDelim(token::Brace) => true, Token::Interpolated(ref nt) => match nt.0 { token::NtItem(_) | token::NtPat(_) | token::NtTy(_) | token::NtIdent(_) | token::NtMeta(_) | token::NtPath(_) | token::NtVis(_) => false, // none of these may start with '{'. _ => true, }, _ => false, }, "path" | "meta" => match *token { Token::ModSep | Token::Ident(_) => true, Token::Interpolated(ref nt) => match nt.0 { token::NtPath(_) | token::NtMeta(_) => true, _ => may_be_ident(&nt.0), }, _ => false, }, "pat" => match *token { Token::Ident(_) |               // box, ref, mut, and other identifiers (can stricten) Token::OpenDelim(token::Paren) |    // tuple pattern Token::OpenDelim(token::Bracket) |  // slice pattern Token::BinOp(token::And) |          // reference Token::BinOp(token::Minus) |        // negative literal Token::AndAnd |                     // double reference Token::Literal(..) |                // literal Token::DotDot |                     // range pattern (future compat) Token::DotDotDot |                  // range pattern (future compat) Token::ModSep |                     // path Token::Lt |                         // path (UFCS constant) Token::BinOp(token::Shl) |          // path (double UFCS) Token::Underscore => true,          // placeholder Token::Interpolated(ref nt) => may_be_ident(&nt.0), _ => false, }, _ => match *token { token::CloseDelim(_) => false, _ => true, }, } } </ins> fn parse_nt<'a>(p: &mut Parser<'a>, sp: Span, name: &str) -> Nonterminal { if name == "tt" { return token::NtTT(p.parse_token_tree());


Question:
Here is a minimum example of the problem. Compilation fails with following error. Which means that the fragment qualifier is not taken into account to choose which variant of the macro is to be used.
Yeah, macros don't do backtracking. You'll need to adjust the matchers to provide some other way to disambiguate.
Yes, I obviously know that I could just put brackets or whatever around one of the patterns to make it distinct. But the whole point of having fragment qualifiers is precisely to distinguish between two otherwise identical patterns. If macros cannot do it although they have the perfect tool for it, then they are stupid and ought to be improved.
It wasn't obvious to me that you knew the workaround -- sorry for assuming! Also see .
Thanks for pointing the PR. It is blocked for now, but I suppose there is still hope. Sorry for being harsh. I have been raging for months over how annoyingly limited and stupid Rust macros are, and I finally found a case general and obvious enough to justify my complaining…
triage: Macros still don't backtrack. I can't find an issue for that, though I do suspect that one exists in some form. Labeling as A-macros, though.
here is (closed).
Closing in favor of -- macro rules do not backtrack.

// except according to those terms. fn main() { <del> panic!(@); //~ ERROR expected expression, found `@` </del> <ins> panic!(@); //~ ERROR no rules expected the token `@` </ins> }


Question:
Here is a minimum example of the problem. Compilation fails with following error. Which means that the fragment qualifier is not taken into account to choose which variant of the macro is to be used.
Yeah, macros don't do backtracking. You'll need to adjust the matchers to provide some other way to disambiguate.
Yes, I obviously know that I could just put brackets or whatever around one of the patterns to make it distinct. But the whole point of having fragment qualifiers is precisely to distinguish between two otherwise identical patterns. If macros cannot do it although they have the perfect tool for it, then they are stupid and ought to be improved.
It wasn't obvious to me that you knew the workaround -- sorry for assuming! Also see .
Thanks for pointing the PR. It is blocked for now, but I suppose there is still hope. Sorry for being harsh. I have been raging for months over how annoyingly limited and stupid Rust macros are, and I finally found a case general and obvious enough to justify my complaining…
triage: Macros still don't backtrack. I can't find an issue for that, though I do suspect that one exists in some form. Labeling as A-macros, though.
here is (closed).
Closing in favor of -- macro rules do not backtrack.

// except according to those terms. pub fn main() { <del> vec![,]; //~ ERROR expected expression, found `,` </del> <ins> vec![,]; //~ ERROR no rules expected the token `,` </ins> }


Question:
Here is a minimum example of the problem. Compilation fails with following error. Which means that the fragment qualifier is not taken into account to choose which variant of the macro is to be used.
Yeah, macros don't do backtracking. You'll need to adjust the matchers to provide some other way to disambiguate.
Yes, I obviously know that I could just put brackets or whatever around one of the patterns to make it distinct. But the whole point of having fragment qualifiers is precisely to distinguish between two otherwise identical patterns. If macros cannot do it although they have the perfect tool for it, then they are stupid and ought to be improved.
It wasn't obvious to me that you knew the workaround -- sorry for assuming! Also see .
Thanks for pointing the PR. It is blocked for now, but I suppose there is still hope. Sorry for being harsh. I have been raging for months over how annoyingly limited and stupid Rust macros are, and I finally found a case general and obvious enough to justify my complaining…
triage: Macros still don't backtrack. I can't find an issue for that, though I do suspect that one exists in some form. Labeling as A-macros, though.
here is (closed).
Closing in favor of -- macro rules do not backtrack.

<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)] //{{{ issue 40569 ============================================================== macro_rules! my_struct { ($(#[$meta:meta])* $ident:ident) => { $(#[$meta])* struct $ident; } } my_struct!(#[derive(Debug, PartialEq)] Foo40569); fn test_40569() { assert_eq!(Foo40569, Foo40569); } //}}} //{{{ issue 26444 ============================================================== macro_rules! foo_26444 { ($($beginning:ident),*; $middle:ident; $($end:ident),*) => { stringify!($($beginning,)* $middle $(,$end)*) } } fn test_26444() { assert_eq!("a , b , c , d , e", foo_26444!(a, b; c; d, e)); assert_eq!("f", foo_26444!(; f ;)); } macro_rules! pat_26444 { ($fname:ident $($arg:pat)* =) => {} } pat_26444!(foo 1 2 5...7 =); pat_26444!(bar Some(ref x) Ok(ref mut y) &(w, z) =); //}}} //{{{ issue 40984 ============================================================== macro_rules! thread_local_40984 { () => {}; ($(#[$attr:meta])* $vis:vis static $name:ident: $t:ty = $init:expr; $($rest:tt)*) => { thread_local_40984!($($rest)*); }; ($(#[$attr:meta])* $vis:vis static $name:ident: $t:ty = $init:expr) => {}; } thread_local_40984! { // no docs #[allow(unused)] static FOO: i32 = 42; /// docs pub static BAR: String = String::from("bar"); // look at these restrictions!! pub(crate) static BAZ: usize = 0; pub(in foo) static QUUX: usize = 0; } //}}} //{{{ issue 35650 ============================================================== macro_rules! size { ($ty:ty) => { std::mem::size_of::<$ty>() }; ($size:tt) => { $size }; } fn test_35650() { assert_eq!(size!(u64), 8); assert_eq!(size!(5), 5); } //}}} //{{{ issue 27832 ============================================================== macro_rules! m { ( $i:ident ) => (); ( $t:tt $j:tt ) => (); } m!(c); m!(t 9); m!(0 9); m!(struct); m!(struct Foo); macro_rules! m2 { ( $b:expr ) => (); ( $t:tt $u:tt ) => (); } m2!(3); m2!(1 2); m2!(_ 1); m2!(enum Foo); //}}} //{{{ issue 39964 ============================================================== macro_rules! foo_39964 { ($a:ident) => {}; (_) => {}; } foo_39964!(_); //}}} //{{{ issue 34030 ============================================================== macro_rules! foo_34030 { ($($t:ident),* /) => {}; } foo_34030!(a, b/); foo_34030!(a/); foo_34030!(/); //}}} //{{{ issue 24189 ============================================================== macro_rules! foo_24189 { ( pub enum $name:ident { $( #[$attr:meta] )* $var:ident } ) => { pub enum $name { $( #[$attr] )* $var } }; } foo_24189! { pub enum Foo24189 { #[doc = "Bar"] Baz } } macro_rules! serializable { ( $(#[$struct_meta:meta])* pub struct $name:ident { $( $(#[$field_meta:meta])* $field:ident: $type_:ty ),* , } ) => { $(#[$struct_meta])* pub struct $name { $( $(#[$field_meta])* $field: $type_ ),* , } } } serializable! { #[allow(dead_code)] /// This is a test pub struct Tester { #[allow(dead_code)] name: String, } } macro_rules! foo_24189_c { ( $( > )* $x:ident ) => { }; } foo_24189_c!( > a ); fn test_24189() { let _ = Foo24189::Baz; let _ = Tester { name: "".to_owned() }; } //}}} //{{{ some more tests ========================================================== macro_rules! test_block { (< $($b:block)* >) => {} } test_block!(<>); test_block!(<{}>); test_block!(<{1}{2}>); macro_rules! test_ty { ($($t:ty),* $(,)*) => {} } test_ty!(); test_ty!(,); test_ty!(u8); test_ty!(u8,); macro_rules! test_path { ($($t:path),* $(,)*) => {} } test_path!(); test_path!(,); test_path!(::std); test_path!(std::u8,); test_path!(any, super, super::super::self::path, X<Y>::Z<'a, T=U>); macro_rules! test_meta_block { ($($m:meta)* $b:block) => {}; } test_meta_block!(windows {}); //}}} fn main() { test_26444(); test_40569(); test_35650(); test_24189(); } </ins>


Question:
Can you provide more assistance in debugging as well? For example what was at line 896 of What configuration did you provide? etc.
Relevant line is a part of At that point anything pertaining i686 in my were Replacing with does still result in the same error. For now, I just specified for 32 bit version of LLVM I have, which works.
Ah ok, thanks for the info! Right now this should be a better error (of course) but the cause is how rustbuild treats the and arrays in the configuration. No C++ compilers are found for the array, so you can't request any host-related targets (e.g. LLVM) when a triple is only mentioned in the array. You can fix this by moving the target to the array.

/// Returns the path to the C++ compiler for the target specified, may panic /// if no C++ compiler was configured for the target. fn cxx(&self, target: &str) -> &Path { <del> self.cxx[target].path() </del> <ins> match self.cxx.get(target) { Some(p) => p.path(), None => panic!("nntarget `{}` is not configured as a host, only as a targetnn", target), } </ins> } /// Returns flags to pass to the compiler to generate code for `target`.


Question:
Inlined from Another issue. If a struct has two different custom derives on it and the second one panics, the error span will point to the first one, not the one which panicked. Reproduction Script
was "Reproduction Script" supposed to be a link? I'm spinning this off from as I don't think it's going to block stabilization and/or closing that issue.
Reproduction script there is a summary tag
<details<summaryReproduction Script</summaryIn a crate called In another crate The error will highlight even though panicked. </details
This seems to be fixed now, so this issue can be closed.
I ran this as a test, and got the following output:

"codegen-units"); suite("check-incremental", "src/test/incremental", "incremental", "incremental"); <del> suite("check-ui", "src/test/ui", "ui", "ui"); </del> } if build.config.build.contains("msvc") {


Question:
Inlined from Another issue. If a struct has two different custom derives on it and the second one panics, the error span will point to the first one, not the one which panicked. Reproduction Script
was "Reproduction Script" supposed to be a link? I'm spinning this off from as I don't think it's going to block stabilization and/or closing that issue.
Reproduction script there is a summary tag
<details<summaryReproduction Script</summaryIn a crate called In another crate The error will highlight even though panicked. </details
This seems to be fixed now, so this issue can be closed.
I ran this as a test, and got the following output:

}); }; <ins> suite("check-ui", "src/test/ui", "ui", "ui"); </ins> suite("check-rpass-full", "src/test/run-pass-fulldeps", "run-pass", "run-pass-fulldeps"); suite("check-rfail-full", "src/test/run-fail-fulldeps",


Question:
Inlined from Another issue. If a struct has two different custom derives on it and the second one panics, the error span will point to the first one, not the one which panicked. Reproduction Script
was "Reproduction Script" supposed to be a link? I'm spinning this off from as I don't think it's going to block stabilization and/or closing that issue.
Reproduction script there is a summary tag
<details<summaryReproduction Script</summaryIn a crate called In another crate The error will highlight even though panicked. </details
This seems to be fixed now, so this issue can be closed.
I ran this as a test, and got the following output:

assert!(plan.iter().any(|s| s.name.contains("-ui"))); assert!(plan.iter().any(|s| s.name.contains("cfail"))); <del> assert!(plan.iter().any(|s| s.name.contains("cfail"))); </del> assert!(plan.iter().any(|s| s.name.contains("cfail-full"))); assert!(plan.iter().any(|s| s.name.contains("codegen-units"))); assert!(plan.iter().any(|s| s.name.contains("debuginfo")));


Question:
Inlined from Another issue. If a struct has two different custom derives on it and the second one panics, the error span will point to the first one, not the one which panicked. Reproduction Script
was "Reproduction Script" supposed to be a link? I'm spinning this off from as I don't think it's going to block stabilization and/or closing that issue.
Reproduction script there is a summary tag
<details<summaryReproduction Script</summaryIn a crate called In another crate The error will highlight even though panicked. </details
This seems to be fixed now, so this issue can be closed.
I ran this as a test, and got the following output:

assert!(plan.iter().all(|s| s.host == "A")); assert!(plan.iter().all(|s| s.target == "C")); <del> assert!(plan.iter().any(|s| s.name.contains("-ui"))); assert!(plan.iter().any(|s| s.name.contains("cfail"))); </del> <ins> assert!(!plan.iter().any(|s| s.name.contains("-ui"))); </ins> assert!(plan.iter().any(|s| s.name.contains("cfail"))); assert!(!plan.iter().any(|s| s.name.contains("cfail-full"))); assert!(plan.iter().any(|s| s.name.contains("codegen-units")));


Question:
Inlined from Another issue. If a struct has two different custom derives on it and the second one panics, the error span will point to the first one, not the one which panicked. Reproduction Script
was "Reproduction Script" supposed to be a link? I'm spinning this off from as I don't think it's going to block stabilization and/or closing that issue.
Reproduction script there is a summary tag
<details<summaryReproduction Script</summaryIn a crate called In another crate The error will highlight even though panicked. </details
This seems to be fixed now, so this issue can be closed.
I ran this as a test, and got the following output:

<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. // no-prefer-dynamic #![crate_type = "proc-macro"] #![feature(proc_macro, proc_macro_lib)] extern crate proc_macro; use proc_macro::TokenStream; #[proc_macro_derive(Foo)] pub fn derive_foo(input: TokenStream) -> TokenStream { input } #[proc_macro_derive(Bar)] pub fn derive_bar(input: TokenStream) -> TokenStream { panic!("lolnope"); } </ins>


Question:
Inlined from Another issue. If a struct has two different custom derives on it and the second one panics, the error span will point to the first one, not the one which panicked. Reproduction Script
was "Reproduction Script" supposed to be a link? I'm spinning this off from as I don't think it's going to block stabilization and/or closing that issue.
Reproduction script there is a summary tag
<details<summaryReproduction Script</summaryIn a crate called In another crate The error will highlight even though panicked. </details
This seems to be fixed now, so this issue can be closed.
I ran this as a test, and got the following output:

<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. // aux-build:plugin.rs #![feature(proc_macro)] #[macro_use] extern crate plugin; #[derive(Foo, Bar)] struct Baz { a: i32, b: i32, } fn main() {} </ins>


Question:
Inlined from Another issue. If a struct has two different custom derives on it and the second one panics, the error span will point to the first one, not the one which panicked. Reproduction Script
was "Reproduction Script" supposed to be a link? I'm spinning this off from as I don't think it's going to block stabilization and/or closing that issue.
Reproduction script there is a summary tag
<details<summaryReproduction Script</summaryIn a crate called In another crate The error will highlight even though panicked. </details
This seems to be fixed now, so this issue can be closed.
I ran this as a test, and got the following output:

<ins> error: custom derive attribute panicked --> $DIR/issue-36935.rs:17:15 | 17 | #[derive(Foo, Bar)] |               ^^^ | = help: message: lolnope </ins>


Question:
Today when you compile for a target that does not exist rustc gives the standard message for failing to find a crate, for . We can and should be more explicit about what this means. Actually what is almost certainly happening is that you don't have that target installed: It could instead say: A reasonable heuristic for printing this might be if the crate is named or and the sysroot is not overridden.
When I run on I get the error:
I would like to try my hand at this if no one else has picked it up already. I am fairly new to rust, so I might need some assistance getting the pull request into a something resembling a reasonable state.

use schema::{METADATA_HEADER, rustc_version}; use rustc::hir::svh::Svh; <del> use rustc::session::Session; </del> <ins> use rustc::session::{config, Session}; </ins> use rustc::session::filesearch::{FileSearch, FileMatches, FileDoesntMatch}; use rustc::session::search_paths::PathKind; use rustc::util::common;


Question:
Today when you compile for a target that does not exist rustc gives the standard message for failing to find a crate, for . We can and should be more explicit about what this means. Actually what is almost certainly happening is that you don't have that target installed: It could instead say: A reasonable heuristic for printing this might be if the crate is named or and the sysroot is not overridden.
When I run on I get the error:
I would like to try my hand at this if no one else has picked it up already. I am fairly new to rust, so I might need some assistance getting the pull request into a something resembling a reasonable state.

"can't find crate for `{}`{}", self.ident, add); <ins> if (self.ident == "std" || self.ident == "core") && self.triple != config::host_triple() { err.note(&format!("the `{}` target may not be installed", self.triple)); } </ins> err.span_label(self.span, &format!("can't find crate")); err };


Question:
Today when you compile for a target that does not exist rustc gives the standard message for failing to find a crate, for . We can and should be more explicit about what this means. Actually what is almost certainly happening is that you don't have that target installed: It could instead say: A reasonable heuristic for printing this might be if the crate is named or and the sysroot is not overridden.
When I run on I get the error:
I would like to try my hand at this if no one else has picked it up already. I am fairly new to rust, so I might need some assistance getting the pull request into a something resembling a reasonable state.

<ins> // Copyright 2012-2014 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. // Tests that compiling for a target which is not installed will result in a helpful // error message. // compile-flags: --target=s390x-unknown-linux-gnu // ignore s390x // error-pattern:target may not be installed fn main() { } </ins>


Question:
Today when you compile for a target that does not exist rustc gives the standard message for failing to find a crate, for . We can and should be more explicit about what this means. Actually what is almost certainly happening is that you don't have that target installed: It could instead say: A reasonable heuristic for printing this might be if the crate is named or and the sysroot is not overridden.
When I run on I get the error:
I would like to try my hand at this if no one else has picked it up already. I am fairly new to rust, so I might need some assistance getting the pull request into a something resembling a reasonable state.

// FIXME (#9639): This needs to handle non-utf8 paths let mut args = vec![input_file.to_str().unwrap().to_owned(), "-L".to_owned(), <del> self.config.build_base.to_str().unwrap().to_owned(), format!("--target={}", target)]; </del> <ins> self.config.build_base.to_str().unwrap().to_owned()]; // Optionally prevent default --target if specified in test compile-flags. let custom_target = self.props.compile_flags .iter() .fold(false, |acc, ref x| acc || x.starts_with("--target")); if !custom_target { args.extend(vec![ format!("--target={}", target), ]); } </ins> if let Some(revision) = self.revision { args.extend(vec![


Question: So I tried to compile core and I get this errors from assembler: the code on line 9468 looks like this: I tried both (4.6.3) and (5.3.0) and both give the same errors. Then I've renamed symbol to in assembly and it compiled successfully. I think msp430 assembler just does not like character in symbol names. So I see 2 options: MSP430 target in LLVM so it will rename symbols with  to not emit on MSP430

use std::str; pub const MAX_BASE: u64 = 64; <ins> pub const ALPHANUMERIC_ONLY: u64 = 62; </ins> const BASE_64: &'static [u8; MAX_BASE as usize] = b"0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ@$";


Question: So I tried to compile core and I get this errors from assembler: the code on line 9468 looks like this: I tried both (4.6.3) and (5.3.0) and both give the same errors. Then I've renamed symbol to in assembly and it compiled successfully. I think msp430 assembler just does not like character in symbol names. So I see 2 options: MSP430 target in LLVM so it will rename symbols with  to not emit on MSP430

let mut name = String::with_capacity(prefix.len() + 6); name.push_str(prefix); name.push_str("."); <del> base_n::push_str(idx as u64, base_n::MAX_BASE, &mut name); </del> <ins> base_n::push_str(idx as u64, base_n::ALPHANUMERIC_ONLY, &mut name); </ins> name } }


Question:
Vec::withcapacity(u64) panics. Error message: rustc -v error: internal compiler error: ../src/librustctypeck unexpected definition: PrimTy(TyUint(u64)) note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: thread 'rustc' panicked at 'Box<Any', note: Run with for a backtrace. Minimal program: fn main() { let vec = Vec::with_capacity(u64); }
Duplicate of and , fixed in . /cc
Closing as a duplicate, thank you!

} } <del> #[derive(Copy, Clone)] </del> <ins> #[derive(Copy, Clone, PartialEq)] </ins> enum PathScope { Global, Lexical,


Question:
Vec::withcapacity(u64) panics. Error message: rustc -v error: internal compiler error: ../src/librustctypeck unexpected definition: PrimTy(TyUint(u64)) note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: thread 'rustc' panicked at 'Box<Any', note: Run with for a backtrace. Minimal program: fn main() { let vec = Vec::with_capacity(u64); }
Duplicate of and , fixed in . /cc
Closing as a duplicate, thank you!

// // Such behavior is required for backward compatibility. // The same fallback is used when `a` resolves to nothing. <del> _ if self.primitive_type_table.primitive_types.contains_key(&path[0].name) => { </del> <ins> PathResult::Module(..) | PathResult::Failed(..) if scope == PathScope::Lexical && (ns == TypeNS || path.len() > 1) && self.primitive_type_table.primitive_types.contains_key(&path[0].name) => { </ins> PathResolution { base_def: Def::PrimTy(self.primitive_type_table.primitive_types[&path[0].name]), depth: segments.len() - 1,


Question:
Vec::withcapacity(u64) panics. Error message: rustc -v error: internal compiler error: ../src/librustctypeck unexpected definition: PrimTy(TyUint(u64)) note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: thread 'rustc' panicked at 'Box<Any', note: Run with for a backtrace. Minimal program: fn main() { let vec = Vec::with_capacity(u64); }
Duplicate of and , fixed in . /cc
Closing as a duplicate, thank you!

<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. fn main() { // Make sure primitive type fallback doesn't work in value namespace std::mem::size_of(u16); //~^ ERROR unresolved name `u16` //~| ERROR this function takes 0 parameters but 1 parameter was supplied // Make sure primitive type fallback doesn't work with global paths let _: ::u8; //~^ ERROR type name `u8` is undefined or not in scope } </ins>


Question:
Compiling this code: Gives me the following error The error is not limited to just the i32 type. : rustc 1.15.0-nightly ( 2016-12-05) binary: rustc commit-hash: commit-date: 2016-12-05 host: x8664-unknown-linux-gnu release: 1.15.0-nightly LLVM version: 3.9 Backtrace:
Duplicate of , fixed in
Closing as duplicate, thanks!


Question:
Compiling this code: Gives me the following error The error is not limited to just the i32 type. : rustc 1.15.0-nightly ( 2016-12-05) binary: rustc commit-hash: commit-date: 2016-12-05 host: x8664-unknown-linux-gnu release: 1.15.0-nightly LLVM version: 3.9 Backtrace:
Duplicate of , fixed in
Closing as duplicate, thanks!


Question:
Compiling this code: Gives me the following error The error is not limited to just the i32 type. : rustc 1.15.0-nightly ( 2016-12-05) binary: rustc commit-hash: commit-date: 2016-12-05 host: x8664-unknown-linux-gnu release: 1.15.0-nightly LLVM version: 3.9 Backtrace:
Duplicate of , fixed in
Closing as duplicate, thanks!


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 .

impl<'a> Resolver<'a> { fn resolution(&self, module: Module<'a>, ident: Ident, ns: Namespace) -> &'a RefCell<NameResolution<'a>> { <ins> let ident = ident.unhygienize(); </ins> *module.resolutions.borrow_mut().entry((ident, ns)) .or_insert_with(|| self.arenas.alloc_name_resolution()) }


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 .

ignore_unresolved_invocations: bool, record_used: Option<Span>) -> Result<&'a NameBinding<'a>, Determinacy> { <del> let ident = ident.unhygienize(); </del> self.populate_module_if_necessary(module); let resolution = self.resolution(module, ident, ns)


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 .

ns: Namespace, binding: &'a NameBinding<'a>) -> Result<(), &'a NameBinding<'a>> { <del> let ident = ident.unhygienize(); </del> self.update_resolution(module, ident, ns, |this, resolution| { if let Some(old_binding) = resolution.binding { if binding.is_glob_import() {