jiebi/CodeConvo huggingface dataset:
Change:
// //   match <sub_expr> { //     <pat> => <body>, <del> //     [_ if <else_opt_if_cond> => <else_opt_if_body>,] </del> //     _ => [<else_opt> | ()] //   }

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

Discussion:
I hit an internal compiler error in rustc 0.12.0-nightly ( 2014-10-02 01:22:20 +0000). Notes: trying to compile ncollide / nphysics. It wasn't finding crates, possibly because of ncollide recently switching to use cargo's 'feature' feature, so I was randomly prodding the files trying to get it working. The internal error appears to happen when it's trying to abort after a legitimate error. This is on OSX 10.9.5. Could not compile .
Still happening consistently as of rustc 0.12.0-nightly ( 2014-10-04 23:42:07 +0000). Also, it's not caused by task abort as I speculated above; it happens consistently when trying to compile nphysics's even in the absence of other errors.
Do you have a reduced testcase?
I do not really have a reduced testcase, though, somehow, I was able to work around the ICE on this commit: What I did is to remove explicit calls to and explicitely dereference anything that had the type or before I call . For example, if has the type , I changed to . Note thit this fix is done on . The ICE seems to happend only when is used by another library/binary (and not during the compilation of itself).
Change:
<ins> // Verifies that computing a layout of a generator tainted by type errors // doesn't ICE. Regression test for #80998. // // edition:2018 #![feature(type_alias_impl_trait)] use std::future::Future; pub struct Task<F: Future>(F); impl<F: Future> Task<F> { fn new() -> Self { todo!() } fn spawn(&self, _: impl FnOnce() -> F) { todo!() } } fn main() { async fn cb() { let a = Foo; //~ ERROR cannot find value `Foo` in this scope } type F = impl Future; // Check that statics are inhabited computes they layout. static POOL: Task<F> = Task::new(); Task::spawn(&POOL, || cb()); } </ins>

Discussion:
See below:
Reduced to only use the task proc-macro: It seems important, that Foo isn't defined, if I define a , the ICE goes away.
searched nightlies: from nightly-2020-06-01 to nightly-2021-01-01 regressed nightly: nightly-2020-10-27 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsI'm pretty sure that isn't at fault here, but instead it just uncovers the problem.
MCVE:
Panic location:
Change:
assert_eq!(map.get(&10).unwrap(), &1000); assert_eq!(map.len(), 6); } <ins> #[test] fn test_entry_take_doesnt_corrupt() { // Test for #19292 fn check(m: &HashMap<int, ()>) { for k in m.keys() { assert!(m.contains_key(k), "{} is in keys() but not in the map?", k); } } let mut m = HashMap::new(); let mut rng = weak_rng(); // Populate the map with some items. for _ in range(0u, 50) { let x = rng.gen_range(-10, 10); m.insert(x, ()); } for i in range(0u, 1000) { let x = rng.gen_range(-10, 10); match m.entry(x) { Vacant(_) => {}, Occupied(e) => { println!("{}: remove {}", i, x); e.take(); }, } check(&m); } } </ins> }

Discussion:
This code manipulates a HashMap using the new Entry API, checking for consistency after each step. The assertion in should never fail, but in my tests it does so reliably, almost always within the first 10 iterations of the second loop. When it does fail, the value of is not one of the values previously removed during the loop (that is, is right to return this key, and is wrong to report it as absent). I tested this with on 64-bit Linux.
cc
Fffffff--- looking into it now. cc
Oh thank god it was a simple stupid mistake, and not something complicated.
Change:
<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(exclusive_range_pattern)] fn main() { // These cases should generate no warning. match 10 { 1..10 => {}, 10 => {}, _ => {}, } match 10 { 1..10 => {}, 9...10 => {}, _ => {}, } match 10 { 1..10 => {}, 10...10 => {}, _ => {}, } // These cases should generate an "unreachable pattern" warning. match 10 { 1..10 => {}, 9 => {}, _ => {}, } match 10 { 1..10 => {}, 8...9 => {}, _ => {}, } match 10 { 1..10 => {}, 9...9 => {}, _ => {}, } } </ins>  No newline at end of file

Discussion:
With rust nightly compiler, the result on the screen is even though the compiler warning that 11 case is unreachable. Link to rust playground:
Change:
let cargo_release = args.next().unwrap(); let rls_release = args.next().unwrap(); let rustfmt_release = args.next().unwrap(); <ins> let _llvm_tools_vers = args.next().unwrap(); // FIXME do something with it? </ins> let s3_address = args.next().unwrap(); let mut passphrase = String::new(); t!(io::stdin().read_to_string(&mut passphrase));

Discussion:
There seems to be a malformed URL in the rustup manifest since 1.27 got released today.
Related to ?
This is causing problems on Travis too, see for example
This affects the mozilla overlay for nixpkgs as well, since that uses the same URLs.
Comparison of nightly and stable metadata for rustup: Somehow got replaced by for latest nightly, other things seem fine. Opening in the browser starts downloading of the archive.
Regression caused by .
you were few minutes faster. tool doesn't expect additional argument: Forget about it, old commit
You're looking at an old commit
Oops, commit from 27 Jul 2017. Probably I should've had a bit more sleep :unamused:
Updating with a previous version such as seems to work for me...
Indeed, this breaks every single project having CI against Rust nightly.
For anyone wondering, PR has fixed the bug. It will take until the next scheduled nightly upload until rustup starts working again.
Should rustup tests be as part of the release process?
There is already an open issue about testing rustup.
when is the next scheduled nightly upload?
It should be in progress right now. runs at midnight UTC.
Nightly should release within the next 30 minutes, probably the next 10-15 minutes. Until then, yes, the command won't work.
2018-06-23 is live and the url is fixed
Same issue with current meta for nightly: From
Please reply to the stickied issue , thanks.
Change:
} impl<'a, 'gcx, 'lcx, 'tcx> ty::TyS<'tcx> { <del> fn sort_string(&self, tcx: TyCtxt<'a, 'gcx, 'lcx>) -> String { </del> <ins> pub fn sort_string(&self, tcx: TyCtxt<'a, 'gcx, 'lcx>) -> String { </ins> match self.sty { ty::TyBool | ty::TyChar | ty::TyInt(_) | ty::TyUint(_) | ty::TyFloat(_) | ty::TyStr | ty::TyNever => self.to_string(),

Discussion:
This code is wrong, but the error message is confusing: Because I used accidentally as a type name when not using the right syntax ... this is pretty confusing:
One solution would be to add detail after the expected/found lines if primitive shadowing has come into play. This would not change the language, but make the error look like:
Change:
/// "Constrained" basically means that it appears in any type but /// not amongst the inputs to a projection. In other words, `<&'a /// T as Trait<''b>>::Foo` does not constrain `'a` or `'b`. <del> fn is_late_bound_map(tcx: TyCtxt<'_>, def_id: LocalDefId) -> Option<&FxHashSet<LocalDefId>> { </del> <ins> fn is_late_bound_map(tcx: TyCtxt<'_>, def_id: LocalDefId) -> Option<&FxIndexSet<LocalDefId>> { </ins> let hir_id = tcx.hir().local_def_id_to_hir_id(def_id); let decl = tcx.hir().fn_decl_by_hir_id(hir_id)?; let generics = tcx.hir().get_generics(def_id)?; <del> let mut late_bound = FxHashSet::default(); </del> <ins> let mut late_bound = FxIndexSet::default(); </ins> let mut constrained_by_input = ConstrainedCollector::default(); for arg_ty in decl.inputs {

Discussion:
The following diff: if done in between s, makes the second check fail with: Aside: that error is printed twice, which is also curious. To reproduce, the following snippet fails on the Playground: I've reported it over to avoid defining a duplicate issue, but now that I've noticed it's a regression, I prefer to risk it being a dup than it going unnoticed. I've also mentioned this over: https://rust- This is causing major breakage with users of who have switched to Rust or up, as showcased by: modify labels: +regression-from-stable-to-stable -regression-untriaged
The bug also reproduces when the is above the impl, but only when that does not change the spans of the impl. It also reproduces when the is add in a different file, or when a or an is instead. This suggests to me that this is somehow related to the overall set of DefIds changing. It does not reproduce when the function is non-async. any ideas? Where there any big refactorings during that time frame that could be the cause of this?
Maybe something related to generators / async functions generates numeric IDs based raw DefIndex values which are then not hashed in a stable way?
Bisection seems to point to
That does sound related. might have an idea.
WG-prioritization assigning priority (). label -I-prioritize +P-critical
Let's keep this open until the backporting situation of the fix is clarified.
was backported to 1.63.0-beta in -- ready to close?
Is this worth a stable backport? The experience of developing async code with this issue isn’t great.
I tried a stable backport locally just to see, but it's non-trivial -- builds on changes from and at least, but that's as far as I investigated before giving up. Maybe a more targeted fix for 1.62.0 could be developed though.
Backported to stable.
Change:
// You can also find more info on why Windows is whitelisted here in: //      https://bugzilla.mozilla.org/show_bug.cgi?id=1302078 if !cx.sess().no_landing_pads() || <del> cx.sess().target.target.options.is_like_windows { </del> <ins> cx.sess().target.target.options.requires_uwtable { </ins> attributes::emit_uwtable(lldecl, true); }

Discussion:
From Gecko profiler uses EHABI information to walk stack. But since rustc doesn't generate EHABI, it cannot walk stack on generated code by rust. says, "-C panic=abort" causes that EHABI isn't emitted", so we need a option not to remove it (or don't remove EHABI even if -C panic=abort).
Note the same actually applies to EH_FRAME info on x86-64, which iirc the Firefox profiler also uses on x86-64. More generally, it can be desirable to have unwind info even when panic doesn't unwind.
For C/C++ code in Firefox we use  to ensure that the compiler generates these when is on: The equivalent for x86-64 is  which is apparently on by default. It seems like having a compiler option to enable this would be good enough, since the behavior here mirrors what gcc does: only emit unwind info if needed for exceptions/unwinding.
LLVM seems to turn on EHABI as default by (EnableARMEHABI is removed by this landing, but still has it) is similar issue for Win64 ABI.
This may or may not be related to , but I can prepare a patch like for the targets here. do you know what targets are in use by Firefox and would need this treatment?
Change:
onEach(document.getElementById('main').getElementsByTagName('pre'), function(e) { onEach(e.getElementsByClassName('attributes'), function(i_e) { i_e.parentNode.insertBefore(createToggleWrapper(), i_e); <del> collapseDocs(i_e.previousSibling.childNodes[0]); </del> <ins> collapseDocs(i_e.previousSibling.childNodes[0], "toggle"); </ins> }); });

Discussion:
When pressing the hotkey on type's documentation such as on the , the methods of the are still shown. This is however mostly useless information that gets in the way of scrolling to see what traits a type implements. It would be more ergonomic if would hide every method of every trait but still show all associated items (types and consts) for each (since they carry useful information). In addition, a / link should be on all the s (including non-trait impls) either besides or to the left of the (as done with s this expands and collapses the impls but keeps associated items shown.
I can rewrite this as an RFC if required, but I was unsure about the protocol wrt. rustdoc.
Similar request:
Closing as resolved.

For example, looking at the docs for , some important trait implementations are hard to find in between all the implementations for each size of fixed-size arrays: Hopefully these impls will eventually become generic, but in the meantime we should consider some way of hiding or collapsing them in the docs.
cc
Dupe of
Change:
ExprKind::MethodCall(_, _) => "a method call", ExprKind::Call(_, _) => "a function call", ExprKind::Await(_) => "`.await`", <ins> ExprKind::Err => return Ok(with_postfix), </ins> _ => unreachable!("parse_dot_or_call_expr_with_ shouldn't produce this"), } );

Discussion:
I'm seeing an internal compiler error on the following input (found by ):
Report from : searched nightlies: from nightly-2020-01-09 to nightly-2020-03-30 regressed nightly: nightly-2020-03-08 searched commits: from to regressed commit:
is the cause. Reduced to: clarified to: clarified further to:
Change:
<ins> // Copyright 2018 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(nll)] pub struct DescriptorSet<'a> { pub slots: Vec<AttachInfo<'a, Resources>> } pub trait ResourcesTrait<'r>: Sized { type DescriptorSet: 'r; } pub struct Resources; impl<'a> ResourcesTrait<'a> for Resources { type DescriptorSet = DescriptorSet<'a>; } pub enum AttachInfo<'a, R: ResourcesTrait<'a>> { NextDescriptorSet(Box<R::DescriptorSet>) } fn main() { let _x = DescriptorSet {slots: Vec::new()}; } </ins>

Discussion:
I'd like to work on this.
This appears to be a regular error, not an ICE.
Change:
<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. // ignore-tidy-linelength struct Foo { x: int } impl Fo { //~ERROR inherent implementations are not allowed for types not defined in the current module. fn foo() {} } fn main() {} </ins>

Discussion:
The code <pretrait T {} impl&lt;U: T&gt; Vec&lt;U&gt; {} fn main() { let r = Vec::fromslice(&[1u]); } </prefails with 4:36 error: unresolved name . fn main() { let r = Vec::from_slice(&[1u]); } </preRemoving the <codeimpl</codeline causes the code to compile fine. Thx Ms2ger for finding such a small example case.
I think this is related to anonymous modules appearing, resolves to a module due to the impl. If you change to this you get another interesting error:
Note that a workaround is to wrap in parens, as Then you get the correct error message about trying to on a type outside of its crate.
I've spent some time investigating this bug and I think that the cleanest thing to do is to (closed B-RFC right now, does anyone have a link to a relevant RFC?) and require to occur only in the same module as, and after, the definition of . This check would be done before creating the anonymous trait module with name . Otherwise in the case of where a definition of is not visible, is not resolved until typeck (at which point the compiler will complain if is defined outside the current crate, or not at all), but if there are resolve errors like the current bug, these will be exposed to the user first and halt compilation. The current behaviour upon encountering where has not been defined in the current module is to create a module (which shadows any other modules exposed by statements) and try to resolve any symbols into this module. This means that the current support for outside of the module is defined in is <ialready</ibroken. Consider for example will error out with "unresolved name ". I'm sure I could come up with other examples of currently broken behaviour like this.
the closing of that bug predates our RFC process, so there would not be a link to an RFC.
Interestingly, this breaks in the opposite direction if you qualify the :
My suggestion is that should be disallowed. I will submit an RFC with these changes.
Change:
<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. // ignore-tidy-linelength struct Foo { x: int } impl Fo { //~ERROR inherent implementations are not allowed for types not defined in the current module. fn foo() {} } fn main() {} </ins>

Discussion:
Could this be fixed by "::unwrap" in the file (src/test/compile-fail/trait-or-new-type-) // error-pattern: found value name used as a type impl<TOption<T::unwrap { pub fn foo(&self) { } fn main() { } !
I don't understand your question, and that's not valid syntax. You can only create an impl for a type in the same module.
definitely I'm confused :-P. Im trying to determine how to fix this issue.Has been a while I didnt work with C like language(last 5 years have been working with C# and Java) ;-) If I create my own file (as you did writing the ) and implement the same code, I get the issue. Rust is a compiler, so Im assuming that a compiler file should be fixed in order to avoid the user implement namespace overlapping imports. Is my assumption correct about this problem?
Yes, your assumption is correct. The goal is to provide an error message that makes sense when a program tries to create an impl for a type that is not in scope (ie. does not exist).
The code I provided is a Rust compiler file (which i changed), not a new one. Im trying to understand where in the code can I implement this fix
Find the place that generates the error message, and follow the code backwards until it's clear where you could modify it to produce a better error message for this case.
Someone gave me a good tip on how to debug Rust I will try this. The terminal is quite archaic ;-P
I think point was essentially "grep for the error message, and look at the code there", using a full debugger to find out where it is is probably still quite hard at the moment. In any case, running turns up . So it looks like one could just expand the pattern to cover more cases.
I used Eclipse as explained by Michael and did a search and found that file. Now correct me if I'm wrong but the it seems that there is no "match a_def {" (startting at line 444) for the impl type. I'm going to attempt to add a case and test
in there is an enumeration, I dont see one for 'impl' (such as DefTrait for example) line 226. Isn't suppose to be one?

No, because the name we are creating an impl for is not itself an impl; the compiler seems to think that it is a module instead. Figuring out why this is the case would be a good start.
seems like astriranna solved the issue by adding: ast::DefMod(_) =
I just tested but this does not work for 'impl' (still get the same error message)
Yes, that is not a solution, just a slightly clearer (but still incorrect) error message.