jiebi/CodeConvo huggingface dataset:
Code change:
Given the example code: I get a really nice warning message about what I did wrong: However, if I change the main function to match multiple patterns: The error message is really confusing with no hint how to fix it: Please expand the error message for the second case to look a bit more like the first case.
Triage: no change. We need to supply the line in E0408.
so I thought I would implement the change you've proposed but have been thinking how best to restrict the kinds of cases where this help note would be appended to the error as I figured it may be rather noisy and/or confusing within the context of some false negatives. So during resolution we of course cannot look at the types to see if it's possible we're matching against an enum. But what do you think about having the help note kick in only if the binding starts with an upper case letter? I know this is a convention that should not really be a concern of the compiler but seeing that using it would only make the diagnostic note a bit more fine-grained, perhaps it's not a terrible idea?
we already do that in some places, like the parser to infer intent, but in this case how would you figure out that you want to suggest and without resolving ? I believe a more holistic solution would be to detect "variable not bound in all patterns" errors where all bindings are single idents, record that fact while throwing the current error and recovering as if there had been a single variable, and later when we have access to the machinery uses emit a warning suggesting and . It is a bit more involved but if we recover as if only had been present the current diagnostic should kick in suggesting (leaving without a suggestion). Edit: that won't work as things stand, as the warning won't be emitted today if there are errors, I think. That would also need to be changed to make it always be emitted :-/
no, I didn't mean to say we need to suggest possible variants. I too concluded that it's non-trivial with the current ordering of passes and the early bailout (indeed, type checking is impossible without resolution succeeding). I was going to add the help note you proposed back in May, just that I would make it dependent on bindings having a Variant-alike naming. From what you're saying there's a precedent in , so I guess this is an acceptable solution? I'll make a PR then.
sorry, I misunderstood. Go ahead, it sounds good.
no, it's likely me who wasn't clear enough. :) I submitted a PR.

Related discussion:
text: use crate::resolve_imports::{ImportDirective, ImportDirectiveSubclass, ImportResolver}; use crate::{path_names_to_string, KNOWN_TOOLS}; <del> use crate::{CrateLint, LegacyScope, Module, ModuleOrUniformRoot}; </del> <ins> use crate::{BindingError, CrateLint, LegacyScope, Module, ModuleOrUniformRoot}; </ins> use crate::{PathResult, ParentScope, ResolutionError, Resolver, Scope, ScopeSet, Segment}; type Res = def::Res<ast::NodeId>;
Code change:
Given the example code: I get a really nice warning message about what I did wrong: However, if I change the main function to match multiple patterns: The error message is really confusing with no hint how to fix it: Please expand the error message for the second case to look a bit more like the first case.
Triage: no change. We need to supply the line in E0408.
so I thought I would implement the change you've proposed but have been thinking how best to restrict the kinds of cases where this help note would be appended to the error as I figured it may be rather noisy and/or confusing within the context of some false negatives. So during resolution we of course cannot look at the types to see if it's possible we're matching against an enum. But what do you think about having the help note kick in only if the binding starts with an upper case letter? I know this is a convention that should not really be a concern of the compiler but seeing that using it would only make the diagnostic note a bit more fine-grained, perhaps it's not a terrible idea?
we already do that in some places, like the parser to infer intent, but in this case how would you figure out that you want to suggest and without resolving ? I believe a more holistic solution would be to detect "variable not bound in all patterns" errors where all bindings are single idents, record that fact while throwing the current error and recovering as if there had been a single variable, and later when we have access to the machinery uses emit a warning suggesting and . It is a bit more involved but if we recover as if only had been present the current diagnostic should kick in suggesting (leaving without a suggestion). Edit: that won't work as things stand, as the warning won't be emitted today if there are errors, I think. That would also need to be changed to make it always be emitted :-/
no, I didn't mean to say we need to suggest possible variants. I too concluded that it's non-trivial with the current ordering of passes and the early bailout (indeed, type checking is impossible without resolution succeeding). I was going to add the help note you proposed back in May, just that I would make it dependent on bindings having a Variant-alike naming. From what you're saying there's a precedent in , so I guess this is an acceptable solution? I'll make a PR then.
sorry, I misunderstood. Go ahead, it sounds good.
no, it's likely me who wasn't clear enough. :) I submitted a PR.

Related discussion:
text: self.resolve_pattern(pat, source, &mut bindings_list); } // This has to happen *after* we determine which pat_idents are variants <del> self.check_consistent_bindings(pats); </del> <ins> if pats.len() > 1 { self.check_consistent_bindings(pats); } </ins> } fn resolve_block(&mut self, block: &Block) {
Code change:
Given the example code: I get a really nice warning message about what I did wrong: However, if I change the main function to match multiple patterns: The error message is really confusing with no hint how to fix it: Please expand the error message for the second case to look a bit more like the first case.
Triage: no change. We need to supply the line in E0408.
so I thought I would implement the change you've proposed but have been thinking how best to restrict the kinds of cases where this help note would be appended to the error as I figured it may be rather noisy and/or confusing within the context of some false negatives. So during resolution we of course cannot look at the types to see if it's possible we're matching against an enum. But what do you think about having the help note kick in only if the binding starts with an upper case letter? I know this is a convention that should not really be a concern of the compiler but seeing that using it would only make the diagnostic note a bit more fine-grained, perhaps it's not a terrible idea?
we already do that in some places, like the parser to infer intent, but in this case how would you figure out that you want to suggest and without resolving ? I believe a more holistic solution would be to detect "variable not bound in all patterns" errors where all bindings are single idents, record that fact while throwing the current error and recovering as if there had been a single variable, and later when we have access to the machinery uses emit a warning suggesting and . It is a bit more involved but if we recover as if only had been present the current diagnostic should kick in suggesting (leaving without a suggestion). Edit: that won't work as things stand, as the warning won't be emitted today if there are errors, I think. That would also need to be changed to make it always be emitted :-/
no, I didn't mean to say we need to suggest possible variants. I too concluded that it's non-trivial with the current ordering of passes and the early bailout (indeed, type checking is impossible without resolution succeeding). I was going to add the help note you proposed back in May, just that I would make it dependent on bindings having a Variant-alike naming. From what you're saying there's a precedent in , so I guess this is an acceptable solution? I'll make a PR then.
sorry, I misunderstood. Go ahead, it sounds good.
no, it's likely me who wasn't clear enough. :) I submitted a PR.

Related discussion:
text: name: Name, origin: BTreeSet<Span>, target: BTreeSet<Span>, <ins> could_be_path: bool </ins> } impl PartialOrd for BindingError {
Code change:
Given the example code: I get a really nice warning message about what I did wrong: However, if I change the main function to match multiple patterns: The error message is really confusing with no hint how to fix it: Please expand the error message for the second case to look a bit more like the first case.
Triage: no change. We need to supply the line in E0408.
so I thought I would implement the change you've proposed but have been thinking how best to restrict the kinds of cases where this help note would be appended to the error as I figured it may be rather noisy and/or confusing within the context of some false negatives. So during resolution we of course cannot look at the types to see if it's possible we're matching against an enum. But what do you think about having the help note kick in only if the binding starts with an upper case letter? I know this is a convention that should not really be a concern of the compiler but seeing that using it would only make the diagnostic note a bit more fine-grained, perhaps it's not a terrible idea?
we already do that in some places, like the parser to infer intent, but in this case how would you figure out that you want to suggest and without resolving ? I believe a more holistic solution would be to detect "variable not bound in all patterns" errors where all bindings are single idents, record that fact while throwing the current error and recovering as if there had been a single variable, and later when we have access to the machinery uses emit a warning suggesting and . It is a bit more involved but if we recover as if only had been present the current diagnostic should kick in suggesting (leaving without a suggestion). Edit: that won't work as things stand, as the warning won't be emitted today if there are errors, I think. That would also need to be changed to make it always be emitted :-/
no, I didn't mean to say we need to suggest possible variants. I too concluded that it's non-trivial with the current ordering of passes and the early bailout (indeed, type checking is impossible without resolution succeeding). I was going to add the help note you proposed back in May, just that I would make it dependent on bindings having a Variant-alike naming. From what you're saying there's a precedent in , so I guess this is an acceptable solution? I'll make a PR then.
sorry, I misunderstood. Go ahead, it sounds good.
no, it's likely me who wasn't clear enough. :) I submitted a PR.

Related discussion:
text: error[E0408]: variable `a` is not bound in all patterns <del> --> $DIR/resolve-inconsistent-names.rs:4:12 </del> <ins> --> $DIR/resolve-inconsistent-names.rs:13:12 </ins> | LL |        a | b => {} |        -   ^ pattern doesn't bind `a`
Code change:
rustc --version; cat ; env RUSTBACKTRACE=1 rustc --emit asm --crate-type dylib -O --target thumbv7em-none-eabihf rustc 1.28.0-nightly ( 2018-05-21) #![nostd] pub fn pete() -u32 { 2 } warning: dropping unsupported crate type for target thread 'main' panicked at 'called on a value', stack backtrace: 0: std::sys::unix::backtrace::tracing::imp::unwindbacktrace at 1: std::syscommon::backtrace::print at at 2: std::panicking::defaulthook::{{closure}} at 3: std::panicking::defaulthook at 4: rustc::util::common::panichook 5: std::panicking::rustpanicwithhook at 6: std::panicking::beginpanicfmt at 7: rustbeginunwind at 8: core::panicking::panicfmt at 9: core::panicking::panic at 10: rustccodegenllvm::base::writemetadata 11: rustc::util::common::time 12: rustccodegenllvm::base::codegencrate 13: <rustccodegenllvm::LlvmCodegenBackend as rustccodegenutils::codegenbackend::CodegenBackend::codegencrate 14: rustc::util::common::time 15: rustcdriver::driver::phase4codegen 16: rustcdriver::driver::compileinput::{{closure}} 17: rustc::ty::context::tls::entercontext 18: <std::thread::local::LocalKey<T::with 19: rustc::ty::context::TyCtxt::createandenter 20: rustcdriver::driver::compileinput 21: rustcdriver::runcompilerwithpool 22: syntax::withglobals 23: <std::panic::AssertUnwindSafe<Fas core::ops::function::FnOnce<()::callonce 24: rustmaybecatchpanic at 25: rustcdriver::run 26: rustcdriver::main 27: std::rt::langstart::{{closure}} 28: std::panicking::try::docall at at 29: rustmaybecatchpanic at 30: std::rt::langstartinternal at at at 31: main 32: _libcstartmain 33: <unknownquery stack during panic: end of query stack error: internal compiler error: unexpected panic note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: note: rustc 1.28.0-nightly ( 2018-05-21) running on x8664-unknown-linux-gnu note: compiler flags: --crate-type dylib
This does not happen on either stable or beta, only nightly.
if it's easy for you, any chance you could bisect with this tool? That would help us pinpoint precisely what introduced the fault. But this is presumably a simple fix...
Sorry, i was a little bit too sloppy. On stable it does not crash, but just because stable does not know the target thumv7em-none-eabi. Beta does indeed crash as well on the same error. I think will fix the problem, let's see. Hadn't time to do a bisect yet
Oh... this might be a new bug entiretly then. Most likely a bisection would point to the PR that said targets
I can confirm, that your patch fixes the ICE :) thanks . The question is, what is it supposed to do now. I creates a file, but it remains mostly empty (so no assembly is generated for that function). Is that what it is supposed to do?
I have no idea. Is that problematic?
Not at all, I'm just curious to know.

Related discussion:
text: config::CrateTypeDylib | config::CrateTypeProcMacro => MetadataKind::Compressed, } <del> }).max().unwrap(); </del> <ins> }).max().unwrap_or(MetadataKind::None); </ins> if kind == MetadataKind::None { return (metadata_llcx,
Code change:
rustc --version; cat ; env RUSTBACKTRACE=1 rustc --emit asm --crate-type dylib -O --target thumbv7em-none-eabihf rustc 1.28.0-nightly ( 2018-05-21) #![nostd] pub fn pete() -u32 { 2 } warning: dropping unsupported crate type for target thread 'main' panicked at 'called on a value', stack backtrace: 0: std::sys::unix::backtrace::tracing::imp::unwindbacktrace at 1: std::syscommon::backtrace::print at at 2: std::panicking::defaulthook::{{closure}} at 3: std::panicking::defaulthook at 4: rustc::util::common::panichook 5: std::panicking::rustpanicwithhook at 6: std::panicking::beginpanicfmt at 7: rustbeginunwind at 8: core::panicking::panicfmt at 9: core::panicking::panic at 10: rustccodegenllvm::base::writemetadata 11: rustc::util::common::time 12: rustccodegenllvm::base::codegencrate 13: <rustccodegenllvm::LlvmCodegenBackend as rustccodegenutils::codegenbackend::CodegenBackend::codegencrate 14: rustc::util::common::time 15: rustcdriver::driver::phase4codegen 16: rustcdriver::driver::compileinput::{{closure}} 17: rustc::ty::context::tls::entercontext 18: <std::thread::local::LocalKey<T::with 19: rustc::ty::context::TyCtxt::createandenter 20: rustcdriver::driver::compileinput 21: rustcdriver::runcompilerwithpool 22: syntax::withglobals 23: <std::panic::AssertUnwindSafe<Fas core::ops::function::FnOnce<()::callonce 24: rustmaybecatchpanic at 25: rustcdriver::run 26: rustcdriver::main 27: std::rt::langstart::{{closure}} 28: std::panicking::try::docall at at 29: rustmaybecatchpanic at 30: std::rt::langstartinternal at at at 31: main 32: _libcstartmain 33: <unknownquery stack during panic: end of query stack error: internal compiler error: unexpected panic note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: note: rustc 1.28.0-nightly ( 2018-05-21) running on x8664-unknown-linux-gnu note: compiler flags: --crate-type dylib
This does not happen on either stable or beta, only nightly.
if it's easy for you, any chance you could bisect with this tool? That would help us pinpoint precisely what introduced the fault. But this is presumably a simple fix...
Sorry, i was a little bit too sloppy. On stable it does not crash, but just because stable does not know the target thumv7em-none-eabi. Beta does indeed crash as well on the same error. I think will fix the problem, let's see. Hadn't time to do a bisect yet
Oh... this might be a new bug entiretly then. Most likely a bisection would point to the PR that said targets
I can confirm, that your patch fixes the ICE :) thanks . The question is, what is it supposed to do now. I creates a file, but it remains mostly empty (so no assembly is generated for that function). Is that what it is supposed to do?
I have no idea. Is that problematic?
Not at all, I'm just curious to know.

Related discussion:
text: <ins> warning: dropping unsupported crate type `dylib` for target `thumbv7em-none-eabihf` </ins>
Code change:
Running the following code triggers an internal compiler error and the error message says that it's a bug and I should report it, so I'm doing that now:
mcve:
Note, that this does not ICE anymore on nightly, instead it gives me: Can this be closed

Related discussion:
text: <ins> // ignore-emscripten no asm! support #![feature(asm)] fn main() { unsafe { asm! {"mov $0,$1"::"0"("bx"),"1"(0x00)} //~^ ERROR: invalid value for constraint in inline assembly } } </ins>
Code change:
Running the following code triggers an internal compiler error and the error message says that it's a bug and I should report it, so I'm doing that now:
mcve:
Note, that this does not ICE anymore on nightly, instead it gives me: Can this be closed

Related discussion:
text: <ins> error[E0669]: invalid value for constraint in inline assembly --> $DIR/issue-51431.rs:7:32 | LL |         asm! {"mov $0,$1"::"0"("bx"),"1"(0x00)} |                                ^^^^ error: aborting due to previous error </ins>
Code change:
Running the following code triggers an internal compiler error and the error message says that it's a bug and I should report it, so I'm doing that now:
mcve:
Note, that this does not ICE anymore on nightly, instead it gives me: Can this be closed

Related discussion:
text: <ins> trait A { const C: usize; fn f() -> ([u8; A::C], [u8; A::C]); //~^ ERROR: type annotations needed: cannot resolve //~| ERROR: type annotations needed: cannot resolve } fn main() {} </ins>
Code change:
Running the following code triggers an internal compiler error and the error message says that it's a bug and I should report it, so I'm doing that now:
mcve:
Note, that this does not ICE anymore on nightly, instead it gives me: Can this be closed

Related discussion:
text: <ins> error[E0283]: type annotations needed: cannot resolve `_: A` --> $DIR/issue-63496.rs:4:21 | LL |     const C: usize; |     --------------- required by `A::C` LL | LL |     fn f() -> ([u8; A::C], [u8; A::C]); |                     ^^^^ error[E0283]: type annotations needed: cannot resolve `_: A` --> $DIR/issue-63496.rs:4:33 | LL |     const C: usize; |     --------------- required by `A::C` LL | LL |     fn f() -> ([u8; A::C], [u8; A::C]); |                                 ^^^^ error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0283`. </ins>
Code change:
Running the following code triggers an internal compiler error and the error message says that it's a bug and I should report it, so I'm doing that now:
mcve:
Note, that this does not ICE anymore on nightly, instead it gives me: Can this be closed

Related discussion:
text: <ins> trait T<'x> { type V; } impl<'g> T<'g> for u32 { type V = u16; } fn main() { (&|_|()) as &dyn for<'x> Fn(<u32 as T<'x>>::V); //~^ ERROR: type mismatch in closure arguments //~| ERROR: type mismatch resolving } </ins>
Code change:
Running the following code triggers an internal compiler error and the error message says that it's a bug and I should report it, so I'm doing that now:
mcve:
Note, that this does not ICE anymore on nightly, instead it gives me: Can this be closed

Related discussion:
text: <ins> error[E0631]: type mismatch in closure arguments --> $DIR/issue-41366.rs:10:5 | LL |     (&|_|()) as &dyn for<'x> Fn(<u32 as T<'x>>::V); |     ^^-----^ |     | | |     | found signature of `fn(_) -> _` |     expected signature of `for<'x> fn(<u32 as T<'x>>::V) -> _` | = note: required for the cast to the object type `dyn for<'x> std::ops::Fn(<u32 as T<'x>>::V)` error[E0271]: type mismatch resolving `for<'x> <[closure@$DIR/issue-41366.rs:10:7: 10:12] as std::ops::FnOnce<(<u32 as T<'x>>::V,)>>::Output == ()` --> $DIR/issue-41366.rs:10:5 | LL |     (&|_|()) as &dyn for<'x> Fn(<u32 as T<'x>>::V); |     ^^^^^^^^ expected bound lifetime parameter 'x, found concrete lifetime | = note: required for the cast to the object type `dyn for<'x> std::ops::Fn(<u32 as T<'x>>::V)` error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0271`. </ins>
Code change:
Running the following code triggers an internal compiler error and the error message says that it's a bug and I should report it, so I'm doing that now:
mcve:
Note, that this does not ICE anymore on nightly, instead it gives me: Can this be closed

Related discussion:
text: <ins> fn main() { [(); &(&'static: loop { |x| {}; }) as *const _ as usize] //~^ ERROR: invalid label name `'static` //~| ERROR: type annotations needed } </ins>
Code change:
Running the following code triggers an internal compiler error and the error message says that it's a bug and I should report it, so I'm doing that now:
mcve:
Note, that this does not ICE anymore on nightly, instead it gives me: Can this be closed

Related discussion:
text: <ins> error: invalid label name `'static` --> $DIR/issue-52437.rs:2:13 | LL |     [(); &(&'static: loop { |x| {}; }) as *const _ as usize] |             ^^^^^^^ error[E0282]: type annotations needed --> $DIR/issue-52437.rs:2:30 | LL |     [(); &(&'static: loop { |x| {}; }) as *const _ as usize] |                              ^ consider giving this closure parameter a type error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0282`. </ins>
Code change:
This is similar to the same buggy behavior we saw for matchers fixed in 1.20.0. For example in Rust 1.19 the following code fails to compile with the message , but correctly prints followed by as of 1.20. The matcher is currently broken in the same way. rustc 1.28.0-nightly ( 2018-06-09)
The ident issue was , so mentioning who fixed that one in . Would you be interested in taking a look at this similar case?
Duplicate of . should still be working on it I think?
Thanks! Let's continue to track this as part of .

Related discussion:
text: Token::Interpolated(ref nt) => may_be_ident(&nt.0), _ => false, }, <ins> "lifetime" => match *token { Token::Lifetime(_) => true, Token::Interpolated(ref nt) => match nt.0 { token::NtLifetime(_) | token::NtTT(_) => true, _ => false, }, _ => false, }, </ins> _ => match *token { token::CloseDelim(_) => false, _ => true,
Code change:
This is similar to the same buggy behavior we saw for matchers fixed in 1.20.0. For example in Rust 1.19 the following code fails to compile with the message , but correctly prints followed by as of 1.20. The matcher is currently broken in the same way. rustc 1.28.0-nightly ( 2018-06-09)
The ident issue was , so mentioning who fixed that one in . Would you be interested in taking a look at this similar case?
Duplicate of . should still be working on it I think?
Thanks! Let's continue to track this as part of .

Related discussion:
text: fn main() { m!(a); <del> //~^ ERROR expected a lifetime, found `a` </del> <ins> //~^ ERROR no rules expected the token `a` </ins> }