jiebi/CodeConvo huggingface dataset:
Code change:
Because is the 's default for application-level logging and should not affect the output of the tools.
eh, it's only recently we've shifted away from using it for tools -- but seems like the trend is definitely to do so. I've filed

Related discussion:
text: 32_000_000 // 32MB on other platforms }; rustc_driver::set_sigpipe_handler(); <del> env_logger::init(); </del> <ins> env_logger::init_from_env("RUSTDOC_LOG"); </ins> let res = std::thread::Builder::new().stack_size(thread_stack_size).spawn(move || { get_args().map(|args| main_args(&args)).unwrap_or(1) }).unwrap().join().unwrap_or(rustc_driver::EXIT_FAILURE);
Code change:
I encountered this as well. What project are you trying to build? My theory is that it tries to run something like (in ?) and then fails to parse the output which is a mix of and ...
Way earlier, it runs it right at the start of a compilation to get the rustc version and enabled . Probably
Could someone use to narrow this down to a particular commit?
It looks to be caused by (I would assume it is in that rollup). It is now printing the time-passes information even for .
would you be up for a fix here?
I'll take a look on Monday. In the meantime, here's my best guess: I an extra entry to the output that prints the total time for the compilation. That extra line may not be indented at all, and it's possible this means it isn't ignored the same way as indented lines.
My theory about indentation was wrong. It was indeed a bad interaction between and , as others suggested, because they both print to . has a fix.

Related discussion:
text: impl Callbacks for TimePassesCallbacks { fn config(&mut self, config: &mut interface::Config) { <ins> // If a --prints=... option has been given, we don't print the "total" // time because it will mess up the --prints output. See #64339. </ins> self.time_passes = <del> config.opts.debugging_opts.time_passes || config.opts.debugging_opts.time; </del> <ins> config.opts.prints.is_empty() && (config.opts.debugging_opts.time_passes || config.opts.debugging_opts.time); </ins> } }
Code change:
Hello, I ran into a problem using lifetime with async struct methods, here is the example: struct Foo<'a{ swag: &'a i32 } impl Foo<'{ async fn bar(&self) -i32 { 1337 } } The error is: '_ Everything is fine if I use explicit lifetime like . Version: 1.39 Nighly (2019-09-19 on playground)
This is happening because the desugaring of uses the lifetime. This is sort of unfortunate, but seems backwards compatible to fix, so I don't think we should block on this.
We decided to focus on this one in the WG meeting -- you still interested in working on it?
Yes, I'm still interested in working on this. I don't think that this should be too hard to fix though if someone else wants it.

Related discussion:
text: /// header, we convert it to an in-band lifetime. fn collect_fresh_in_band_lifetime(&mut self, span: Span) -> ParamName { assert!(self.is_collecting_in_band_lifetimes); <del> let index = self.lifetimes_to_define.len(); </del> <ins> let index = self.lifetimes_to_define.len() + self.in_scope_lifetimes.len(); </ins> let hir_name = ParamName::Fresh(index); self.lifetimes_to_define.push((span, hir_name)); hir_name
Code change:
Hello, I ran into a problem using lifetime with async struct methods, here is the example: struct Foo<'a{ swag: &'a i32 } impl Foo<'{ async fn bar(&self) -i32 { 1337 } } The error is: '_ Everything is fine if I use explicit lifetime like . Version: 1.39 Nighly (2019-09-19 on playground)
This is happening because the desugaring of uses the lifetime. This is sort of unfortunate, but seems backwards compatible to fix, so I don't think we should block on this.
We decided to focus on this one in the WG meeting -- you still interested in working on it?
Yes, I'm still interested in working on this. I don't think that this should be too hard to fix though if someone else wants it.

Related discussion:
text: <ins> // check-pass // Check that the anonymous lifetimes used here aren't considered to shadow one // another. Note that `async fn` is different to `fn` here because the lifetimes // are numbered by HIR lowering, rather than lifetime resolution. // edition:2018 struct A<'a, 'b>(&'a &'b i32); struct B<'a>(&'a i32); impl A<'_, '_> { async fn assoc(x: &u32, y: B<'_>) { async fn nested(x: &u32, y: A<'_, '_>) {} } async fn assoc2(x: &u32, y: A<'_, '_>) { impl A<'_, '_> { async fn nested_assoc(x: &u32, y: B<'_>) {} } } } fn main() {} </ins>
Code change:
Godbolt link: So I expect these two functions has the same assembly: But the result is not:
modify labels: -C-bug -I-slow T-compiler
Hey I tried solving this but wasn't really sure how to. I believe the implementation to the LLVM generation is right here. Hope someone can solve this!
Turn out I was wrong! The is working correctly (i.e. those two functions are not equivalent): I would add some doctests to show that and close this issue.

Related discussion:
text: ``` ", $Feature, "assert_eq!(100", stringify!($SelfT), ".saturating_add(1), 101); assert_eq!(", stringify!($SelfT), "::max_value().saturating_add(100), ", stringify!($SelfT), <del> "::max_value());", </del> <ins> "::max_value()); assert_eq!(", stringify!($SelfT), "::min_value().saturating_add(-1), ", stringify!($SelfT), "::min_value());", </ins> $EndFeature, " ```"),
Code change:
Godbolt link: So I expect these two functions has the same assembly: But the result is not:
modify labels: -C-bug -I-slow T-compiler
Hey I tried solving this but wasn't really sure how to. I believe the implementation to the LLVM generation is right here. Hope someone can solve this!
Turn out I was wrong! The is working correctly (i.e. those two functions are not equivalent): I would add some doctests to show that and close this issue.

Related discussion:
text: } } doc_comment! { concat!("Saturating integer subtraction. Computes `self - rhs`, saturating at the numeric bounds instead of overflowing.
Code change:
Godbolt link: So I expect these two functions has the same assembly: But the result is not:
modify labels: -C-bug -I-slow T-compiler
Hey I tried solving this but wasn't really sure how to. I believe the implementation to the LLVM generation is right here. Hope someone can solve this!
Turn out I was wrong! The is working correctly (i.e. those two functions are not equivalent): I would add some doctests to show that and close this issue.

Related discussion:
text: ``` ", $Feature, "assert_eq!(100", stringify!($SelfT), ".saturating_sub(127), -27); assert_eq!(", stringify!($SelfT), "::min_value().saturating_sub(100), ", stringify!($SelfT), <del> "::min_value());", </del> <ins> "::min_value()); assert_eq!(", stringify!($SelfT), "::max_value().saturating_sub(-1), ", stringify!($SelfT), "::max_value());", </ins> $EndFeature, " ```"), #[stable(feature = "rust1", since = "1.0.0")]
Code change:
The following example code yields an error: It's unclear from this error message how to proceed - I'm not sure of the syntax, location, or where I should be putting the "GetString" trait bound. It should be shown with a better example or link when this error is presented, as the current message is not sufficient for a resolution to be arrived at.
cc
Fixing in . To fix your code write:
Thanks!

Related discussion:
text: } else { "items from traits can only be used if the trait is implemented and in scope" }); <del> let mut msg = format!( </del> <ins> let message = |action| format!( </ins> "the following {traits_define} an item `{name}`, perhaps you need to {action}  {one_of_them}:", traits_define = if candidates.len() == 1 {
Code change:
The following example code yields an error: It's unclear from this error message how to proceed - I'm not sure of the syntax, location, or where I should be putting the "GetString" trait bound. It should be shown with a better example or link when this error is presented, as the current message is not sufficient for a resolution to be arrived at.
cc
Fixing in . To fix your code write:
Thanks!

Related discussion:
text: } else { "traits define" }, <del> action = if let Some(param) = param_type { format!("restrict type parameter `{}` with", param) } else { "implement".to_string() }, </del> <ins> action = action, </ins> one_of_them = if candidates.len() == 1 { "it" } else {
Code change:
The following example code yields an error: It's unclear from this error message how to proceed - I'm not sure of the syntax, location, or where I should be putting the "GetString" trait bound. It should be shown with a better example or link when this error is presented, as the current message is not sufficient for a resolution to be arrived at.
cc
Fixing in . To fix your code write:
Thanks!

Related discussion:
text: <ins> // run-rustfix // check-only #[derive(Debug)] struct Demo { a: String } trait GetString { fn get_a(&self) -> &String; } trait UseString: std::fmt::Debug + GetString { fn use_string(&self) { println!("{:?}", self.get_a()); //~ ERROR no method named `get_a` found for type `&Self` } } trait UseString2: GetString { fn use_string(&self) { println!("{:?}", self.get_a()); //~ ERROR no method named `get_a` found for type `&Self` } } impl GetString for Demo { fn get_a(&self) -> &String { &self.a } } impl UseString for Demo {} impl UseString2 for Demo {} #[cfg(test)] mod tests { use crate::{Demo, UseString}; #[test] fn it_works() { let d = Demo { a: "test".to_string() }; d.use_string(); } } fn main() {} </ins>
Code change:
The following example code yields an error: It's unclear from this error message how to proceed - I'm not sure of the syntax, location, or where I should be putting the "GetString" trait bound. It should be shown with a better example or link when this error is presented, as the current message is not sufficient for a resolution to be arrived at.
cc
Fixing in . To fix your code write:
Thanks!

Related discussion:
text: <ins> // run-rustfix // check-only #[derive(Debug)] struct Demo { a: String } trait GetString { fn get_a(&self) -> &String; } trait UseString: std::fmt::Debug { fn use_string(&self) { println!("{:?}", self.get_a()); //~ ERROR no method named `get_a` found for type `&Self` } } trait UseString2 { fn use_string(&self) { println!("{:?}", self.get_a()); //~ ERROR no method named `get_a` found for type `&Self` } } impl GetString for Demo { fn get_a(&self) -> &String { &self.a } } impl UseString for Demo {} impl UseString2 for Demo {} #[cfg(test)] mod tests { use crate::{Demo, UseString}; #[test] fn it_works() { let d = Demo { a: "test".to_string() }; d.use_string(); } } fn main() {} </ins>
Code change:
The following example code yields an error: It's unclear from this error message how to proceed - I'm not sure of the syntax, location, or where I should be putting the "GetString" trait bound. It should be shown with a better example or link when this error is presented, as the current message is not sufficient for a resolution to be arrived at.
cc
Fixing in . To fix your code write:
Thanks!

Related discussion:
text: <ins> error[E0599]: no method named `get_a` found for type `&Self` in the current scope --> $DIR/constrain-trait.rs:15:31 | LL |         println!("{:?}", self.get_a()); |                               ^^^^^ method not found in `&Self` | = help: items from traits can only be used if the type parameter is bounded by the trait help: the following trait defines an item `get_a`, perhaps you need to add another supertrait for it: | LL | trait UseString: std::fmt::Debug + GetString { |                                  ^^^^^^^^^^^ error[E0599]: no method named `get_a` found for type `&Self` in the current scope --> $DIR/constrain-trait.rs:21:31 | LL |         println!("{:?}", self.get_a()); |                               ^^^^^ method not found in `&Self` | = help: items from traits can only be used if the type parameter is bounded by the trait help: the following trait defines an item `get_a`, perhaps you need to add a supertrait for it: | LL | trait UseString2: GetString { |                 ^^^^^^^^^^^ error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0599`. </ins>
Code change:
The and targets force panic=abort. said : This looks related to , which points at these now-merged LLVM changes: It's possible that we do not need to force panic=abort anymore for arm64 Windows as a result. What's the best way to determine if this is still required?
Theoretically the way to fix this issue is: First Next, run the build Finally, run the tests If that all passes, then the change can land! The tests may be able to be skipped, and some tests may fail, so it may be possible to switch the defaults and we can fixup bugs later. I don't personally have hardware to test these changes on myself, though.
I occasionally have access to a Windows arm64 laptop, so I'll try and get a rustc build going on it at some point.

Related discussion:
text: } else if #[cfg(target_os = "hermit")] { #[path = "hermit.rs"] mod real_imp; <del> } else if #[cfg(all(target_env = "msvc", target_arch = "aarch64"))] { #[path = "dummy.rs"] mod real_imp; </del> } else if #[cfg(target_env = "msvc")] { #[path = "seh.rs"] mod real_imp;
Code change:
The and targets force panic=abort. said : This looks related to , which points at these now-merged LLVM changes: It's possible that we do not need to force panic=abort anymore for arm64 Windows as a result. What's the best way to determine if this is still required?
Theoretically the way to fix this issue is: First Next, run the build Finally, run the tests If that all passes, then the change can land! The tests may be able to be skipped, and some tests may fail, so it may be possible to switch the defaults and we can fixup bugs later. I don't personally have hardware to test these changes on myself, though.
I occasionally have access to a Windows arm64 laptop, so I'll try and get a rustc build going on it at some point.

Related discussion:
text: } } <del> #[cfg(any(target_arch = "x86_64", target_arch = "arm"))] </del> <ins> #[cfg(not(target_arch = "x86"))] </ins> #[macro_use] mod imp { pub type ptr_t = u32;
Code change:
The and targets force panic=abort. said : This looks related to , which points at these now-merged LLVM changes: It's possible that we do not need to force panic=abort anymore for arm64 Windows as a result. What's the best way to determine if this is still required?
Theoretically the way to fix this issue is: First Next, run the build Finally, run the tests If that all passes, then the change can land! The tests may be able to be skipped, and some tests may fail, so it may be possible to switch the defaults and we can fixup bugs later. I don't personally have hardware to test these changes on myself, though.
I occasionally have access to a Windows arm64 laptop, so I'll try and get a rustc build going on it at some point.

Related discussion:
text: <del> use crate::spec::{LinkerFlavor, PanicStrategy, Target, TargetResult}; </del> <ins> use crate::spec::{LinkerFlavor, Target, TargetResult}; </ins> pub fn target() -> TargetResult { let mut base = super::windows_msvc_base::opts();
Code change:
The and targets force panic=abort. said : This looks related to , which points at these now-merged LLVM changes: It's possible that we do not need to force panic=abort anymore for arm64 Windows as a result. What's the best way to determine if this is still required?
Theoretically the way to fix this issue is: First Next, run the build Finally, run the tests If that all passes, then the change can land! The tests may be able to be skipped, and some tests may fail, so it may be possible to switch the defaults and we can fixup bugs later. I don't personally have hardware to test these changes on myself, though.
I occasionally have access to a Windows arm64 laptop, so I'll try and get a rustc build going on it at some point.

Related discussion:
text: base.has_elf_tls = true; base.features = "+neon,+fp-armv8".to_string(); <del> // FIXME: this shouldn't be panic=abort, it should be panic=unwind base.panic_strategy = PanicStrategy::Abort; </del> Ok(Target { llvm_target: "aarch64-pc-windows-msvc".to_string(), target_endian: "little".to_string(),
Code change:
The and targets force panic=abort. said : This looks related to , which points at these now-merged LLVM changes: It's possible that we do not need to force panic=abort anymore for arm64 Windows as a result. What's the best way to determine if this is still required?
Theoretically the way to fix this issue is: First Next, run the build Finally, run the tests If that all passes, then the change can land! The tests may be able to be skipped, and some tests may fail, so it may be possible to switch the defaults and we can fixup bugs later. I don't personally have hardware to test these changes on myself, though.
I occasionally have access to a Windows arm64 laptop, so I'll try and get a rustc build going on it at some point.

Related discussion:
text: <del> use crate::spec::{LinkerFlavor, PanicStrategy, Target, TargetResult}; </del> <ins> use crate::spec::{LinkerFlavor, Target, TargetResult}; </ins> pub fn target() -> TargetResult { let mut base = super::windows_uwp_msvc_base::opts(); base.max_atomic_width = Some(64); base.has_elf_tls = true; <del> // FIXME: this shouldn't be panic=abort, it should be panic=unwind base.panic_strategy = PanicStrategy::Abort; </del> Ok(Target { llvm_target: "aarch64-pc-windows-msvc".to_string(), target_endian: "little".to_string(),
Code change:
The and targets force panic=abort. said : This looks related to , which points at these now-merged LLVM changes: It's possible that we do not need to force panic=abort anymore for arm64 Windows as a result. What's the best way to determine if this is still required?
Theoretically the way to fix this issue is: First Next, run the build Finally, run the tests If that all passes, then the change can land! The tests may be able to be skipped, and some tests may fail, so it may be possible to switch the defaults and we can fixup bugs later. I don't personally have hardware to test these changes on myself, though.
I occasionally have access to a Windows arm64 laptop, so I'll try and get a rustc build going on it at some point.

Related discussion:
text: <del> Subproject commit 130721d6f4e6cba3b910ccdf5e0aa62b9dffc95f </del> <ins> Subproject commit 027e428197f3702599cfbb632883768175f49173 </ins>
Code change:
I tried to compile some massive project and the rust compiler unexpectedly panicked. Luckily, I have managed to replicate the error in a small, reproducible example (still panics on rust playground online, 11 lines of code): I expected a regular error without a panic, but the compiler simply halted. Output of RUSTBACKTRACE=1 rustc -o -C debuginfo=2: Output of :
Maximal reduction: This didn't ICE in 1.37.0 (checked with godbolt).
triage: P-medium (based on assumption that one will always see something like that error message, with its span, before the ICE). Assigning to self for now (but I welcome others who would like to work-steal it). Removing nomination label.
assigning to as well based on insight that this ICE may be arising from diagnostics.
I believe I have a fix. I'll post it after lunch. Edit: faster than I thought.

Related discussion:
text: // the `enclosing_loops` field and let's coerce the // type of `expr_opt` into what is expected. let mut enclosing_breakables = self.enclosing_breakables.borrow_mut(); <del> let ctxt = enclosing_breakables.find_breakable(target_id); </del> <ins> let ctxt = match enclosing_breakables.opt_find_breakable(target_id) { Some(ctxt) => ctxt, None => { // Avoid ICE when `break` is inside a closure (#65383). self.tcx.sess.delay_span_bug( expr.span, "break was outside loop, but no error was emitted", ); return tcx.types.err; } }; </ins> if let Some(ref mut coerce) = ctxt.coerce { if let Some(ref e) = expr_opt { coerce.coerce(self, &cause, e, e_ty);
Code change:
I tried to compile some massive project and the rust compiler unexpectedly panicked. Luckily, I have managed to replicate the error in a small, reproducible example (still panics on rust playground online, 11 lines of code): I expected a regular error without a panic, but the compiler simply halted. Output of RUSTBACKTRACE=1 rustc -o -C debuginfo=2: Output of :
Maximal reduction: This didn't ICE in 1.37.0 (checked with godbolt).
triage: P-medium (based on assumption that one will always see something like that error message, with its span, before the ICE). Assigning to self for now (but I welcome others who would like to work-steal it). Removing nomination label.
assigning to as well based on insight that this ICE may be arising from diagnostics.
I believe I have a fix. I'll post it after lunch. Edit: faster than I thought.

Related discussion:
text: } } else { // If `ctxt.coerce` is `None`, we can just ignore <del> // the type of the expresison.  This is because </del> <ins> // the type of the expression.  This is because </ins> // either this was a break *without* a value, in // which case it is always a legal type (`()`), or // else an error would have been flagged by the
Code change:
I tried to compile some massive project and the rust compiler unexpectedly panicked. Luckily, I have managed to replicate the error in a small, reproducible example (still panics on rust playground online, 11 lines of code): I expected a regular error without a panic, but the compiler simply halted. Output of RUSTBACKTRACE=1 rustc -o -C debuginfo=2: Output of :
Maximal reduction: This didn't ICE in 1.37.0 (checked with godbolt).
triage: P-medium (based on assumption that one will always see something like that error message, with its span, before the ICE). Assigning to self for now (but I welcome others who would like to work-steal it). Removing nomination label.
assigning to as well based on insight that this ICE may be arising from diagnostics.
I believe I have a fix. I'll post it after lunch. Edit: faster than I thought.

Related discussion:
text: impl<'tcx> EnclosingBreakables<'tcx> { fn find_breakable(&mut self, target_id: hir::HirId) -> &mut BreakableCtxt<'tcx> { <del> let ix = *self.by_id.get(&target_id).unwrap_or_else(|| { </del> <ins> self.opt_find_breakable(target_id).unwrap_or_else(|| { </ins> bug!("could not find enclosing breakable with id {}", target_id); <del> }); &mut self.stack[ix] </del> <ins> }) } fn opt_find_breakable(&mut self, target_id: hir::HirId) -> Option<&mut BreakableCtxt<'tcx>> { match self.by_id.get(&target_id) { Some(ix) => Some(&mut self.stack[*ix]), None => None, } </ins> } }
Code change:
I tried to compile some massive project and the rust compiler unexpectedly panicked. Luckily, I have managed to replicate the error in a small, reproducible example (still panics on rust playground online, 11 lines of code): I expected a regular error without a panic, but the compiler simply halted. Output of RUSTBACKTRACE=1 rustc -o -C debuginfo=2: Output of :
Maximal reduction: This didn't ICE in 1.37.0 (checked with godbolt).
triage: P-medium (based on assumption that one will always see something like that error message, with its span, before the ICE). Assigning to self for now (but I welcome others who would like to work-steal it). Removing nomination label.
assigning to as well based on insight that this ICE may be arising from diagnostics.
I believe I have a fix. I'll post it after lunch. Edit: faster than I thought.

Related discussion:
text: let rs: Foo = Foo{t: pth}; let unconstrained = break; //~ ERROR: `break` outside of a loop <ins> // This used to ICE because `target_id` passed to `check_expr_break` would be the closure and // not the `loop`, which failed in the call to `find_breakable`. (#65383) 'lab: loop { || { break 'lab; //~ ERROR `break` inside of a closure }; } </ins> }