jiebi/CodeConvo huggingface dataset:
Change:
*local = self.to; } } <ins> fn visit_terminator_kind(&mut self, kind: &mut TerminatorKind<'tcx>, location: Location) { match kind { TerminatorKind::Return => { // Do not replace the implicit `_0` access here, as that's not possible. The // transform already handles `return` correctly. } _ => self.super_terminator_kind(kind, location), } } </ins> } struct DerefArgVisitor<'tcx> {

Discussion:
The terminator conceptually moves out of the return place , but this is not currently reflected by the visitor infrastructure. This can lead to incorrect dataflow solutions for . For example, reports that is dead before a , which is wrong (it must always be live there). These don't currently cause any harm, since use of is fairly limited, but they are an issue for destination propagation / NRVO, which can propagate to arbitrary places in the function and needs to have correct information to do so soundly. The simple fix of calling from within has the problem that the receives a , but the local reads from can not be changed. This can be caught with an assertion, but maybe there is a better solution for this? cc
I think any alternative will be more complex than that simple assertion. Conceptually the should contain a which is always , but then we'd need to have assertions keeping that in place, so you don't gain anything. I don't think we can generalize returning to allow using different places than , which is the only way we'd get around having to assert something somewhere.
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(step_trait)] use std::iter::Step; #[cfg(target_pointer_width = "16")] fn main() { assert!(Step::steps_between(&0u32, &::std::u32::MAX).is_none()); } #[cfg(any(target_pointer_width = "32", target_pointer_width = "64"))] fn main() { assert!(Step::steps_between(&0u32, &::std::u32::MAX).is_some()); } </ins>

Discussion:
is implemented for Range<T. TrustedLen that the upper bound of is None if the iterator produces more than elements. to produce its result. The of subtracts the lower from the upper value and casts it to usize. This is for u32. On 16bit platforms, the result of the subtraction of two u32 values may not fit inside , producing an invalid . This means, that e.g. collecting into a Vec using its allows writing beyond its reserved buffer. One such example input would be . Reference: /cc
Change:
rustc_path: opt_path(matches, "rustc-path"), rustdoc_path: matches.opt_str("rustdoc-path").map(PathBuf::from), rust_demangler_path: matches.opt_str("rust-demangler-path").map(PathBuf::from), <del> lldb_python: matches.opt_str("lldb-python").unwrap(), docck_python: matches.opt_str("docck-python").unwrap(), </del> <ins> python: matches.opt_str("python").unwrap(), </ins> jsondocck_path: matches.opt_str("jsondocck-path"), valgrind_path: matches.opt_str("valgrind-path"), force_valgrind: matches.opt_present("force-valgrind"),

Discussion:
Compiletest currently has two different arguments telling it which python to use. Since , both are always the same. We should change it to just one argument to simplify things. Mentoring instructions: Change to be a single argument, then change to use the updated arguments. are you interested in tackling this one too? :) label +A-rustbuild +A-testsuite +E-easy +E-mentor Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
Change:
(lhs, Some((true, rhs_ty, rhs_sp))) => one_side_err(rhs_sp, rhs_ty, lhs), _ => span_bug!(span, "Impossible, verified above."), } <ins> if (lhs, rhs).references_error() { err.downgrade_to_delayed_bug(); } </ins> if self.tcx.sess.teach(&err.get_code().unwrap()) { err.note( "In a match expression, only numbers and characters can be matched 

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: <!-- Please provide a link to --The current output is: We shouldn't show here. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
without
another one 
What ideal output would you suggest? Should we remove the suggestion line like:
Ideally we should be checking that the return type . If it's not suggestable, don't mention it.
claim
I actually believe that neither the E0029 nor the E0277 should have been emitted. I would check explicitly for and change the error to be (that way the error isn't printed out, but rustc will ICE if no other error is emitted, which should have happened).
The PR will prevent E0029 and E0277 from printing out after checking the type references.
Change:
<ins> // Regression test for #54901: immutable thread locals could be mutated. See: // https://github.com/rust-lang/rust/issues/29594#issuecomment-328177697 // https://github.com/rust-lang/rust/issues/54901 #![feature(thread_local)] #[thread_local] static S: &str = "before"; fn set_s() { S = "after"; //~ ERROR cannot assign to immutable } fn main() { println!("{}", S); set_s(); println!("{}", S); } </ins>

Discussion:
On rustc 1.31.0-nightly ( 2018-10-07) and x8664-unknown-linux-gnu, we see the following surprising behavior: In release mode it seems the write has not happened in the place that it should. Mentioning threadlocal tracking issue: .
Ah, apparently this is missing a . With the behavior is correct. We need to make sure mutating a thread_local static that does not have does not compile.
cc Did fix this by any chance?
It looks like this is fixed on nightly; I'm guessing is the reason. We probably should add some regression tests for the cases listed here.
Change:
<ins> error[E0412]: cannot find type `Missing` in this scope --> $DIR/ensure-rpitits-are-created-before-freezing.rs:8:19 | LL | impl Iterable for Missing { |                   ^^^^^^^ not found in this scope error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0412`. </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'still mutable'', 'thread 'rustc' panicked at 'still mutable'' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [associatedtypesforimpltraitsinassociatedfn] creating associated items for opaque types returned by [associateditemdefids] collecting associated items or fields of [associateditems] collecting associated items of [opaquetypesdefinedby] computing the opaque types defined by [typeck] type-checking [analysis] running analysis passes on this crate --
cc , also see for a similar regression fixed by nn
Not sure that was actually fixed. The PR seems entirely unrelated
on a nighty before , this errored with
Oh I think I see how that got "fixed". It bailed out of compilation early enough not to hit the ICE anymore by emitting stashed errors earlier. So it got hidden again, and now it's back againbecause of some subtle change in query ordering. We probably need to run this query explicitly for all traits and impls before the big def id freeze.
Change:
"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 };

Discussion:
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.
Change:
<del> // ignore-tidy-cr //@ check-pass // This file checks the spans of intra-link warnings in a file with CRLF line endings. The // .gitattributes file in this directory should enforce it. /// [error] pub struct A; //~^^ WARNING `error` /// /// docs [error1] //~^ WARNING `error1` /// docs [error2] /// pub struct B; //~^^^ WARNING `error2` /** * This is a multi-line comment. * * It also has an [error]. */ pub struct C; //~^^^ WARNING `error` </del> <ins> // ignore-tidy-cr //@ check-pass // This file checks the spans of intra-link warnings in a file with CRLF line endings. The // .gitattributes file in this directory should enforce it. /// [error] pub struct A; //~^^ WARNING `error` /// /// docs [error1] //~^ WARNING `error1` /// docs [error2] /// pub struct B; //~^^^ WARNING `error2` /** * This is a multi-line comment. * * It also has an [error]. */ pub struct C; //~^^^ WARNING `error` </ins>

Discussion:
Right now using to manage the rust-lang/rust repo locally causes to fail: This is a result of which is responsible for adding the character to the failing test. While I would love to get that support to jj upstream I'm assuming it is non-trivial and I'd like a better solution in the short term so I can continue to use while contributing to the compiler. suggested I use in the meantime which I'm fine with but I'd like a way to set this in my or some equivalent mechanism doesn't require manually adding this set of arguments to every invocation of I make.
note this is essentially the same as i actually would like an even more general solution, where the flags and configs are completely interchangable and you can specify either in either place, but a solution just for seems ok too. label T-bootstrap A-contributor-roadblock
So it turns out that won't work as a short term fix even because does not work with tidy atm. For now I'm going with but I expect this to break frequently and be a source of annoyance so I'll be looking towards fixing this soon if it does in fact end up being a problem.
re crlf, as a source control expert I'd recommend never using any kind of autoconversion -- it is a bit of a nightmare to work with in too many cases. Rather, I'd consider checking in the file with CRLFs, and disabling autoconversion so files are always checked out as-is. (Another option is to effectively treat the file as binary content, e.g. use some other means of encoding the file, such as base64 or putting it in a tarball. But I don't know how practical that is)
Change:
}; // do a naive search if the haystack is too small to fit <del> if haystack.len() < Block::LANES + second_probe_offset { </del> <ins> if haystack.len() < Block::LANES + last_byte_offset { </ins> return Some(haystack.windows(needle.len()).any(|c| c == needle)); }

Discussion:
PR a x8664 SIMD-based implementation of to optimize searching into strings when the needle is at most 32 bytes long. Unfortunately, that implementation doesn't seem to be sound. When compiling the standard library with debug assertions on, running UI tests excluding results in compiletest itself panicking before executing any test due to a in libcore: To reproduce the issue, use the following configuration file: run: cc
Tentatively opened a revert PR in
Ugh. I ran it under miri with quite a combinatorial test that I thought should cover all the edge-cases. It's not immediately obvious what's wrong, so it's fine to land the revert for now.
Last I checked (and a lot has happened since then so I could be working on outdated info -- might be able to confirm), miri can't catch failure in many cases I believe, since it's "just" library UB.
the memory will be accessed after the get_unchecked so it should still be an invalid memory access when it's out of bounds. Unless I'm just doing some shortening slicing and then extending it again so that it's valid within the same allocation but not correct slicing.
What says is correct. The error here is in a situation like Miri (without Stacked Borrows) will not complain about that since the index is in-bounds of the allocation. But the debug assertion will complain since you are causing library UB by going out-of-bounds of the slice. I don't quite understand your last comment,
It seems like the test is just insufficient. Even with debug asserts and overflow checks enabled it doesn't catch it. I'll have to reproduce it first to figure out what's missing.
Ooh, I was getting absolutely unexplainable compiler errors when building stage 1 libstd with a stage 0 rustc which was built with however, could this be the cause for this? :sweat_smile:
Possible, but it would also do incorrect things on x86-64 baseline
has a proper fix
Change:
let mut tool = tool::ErrorIndex::command(builder); tool.arg("markdown").arg(&output); <del> let _guard = </del> <ins> let guard = </ins> builder.msg(Kind::Test, compiler.stage, "error-index", compiler.host, compiler.host); let _time = util::timeit(&builder); builder.run_quiet(&mut tool); <ins> drop(guard); </ins> // The tests themselves need to link to std, so make sure it is // available. builder.ensure(compile::Std::new(compiler, compiler.host));

Discussion:
This is a regression from
in general the fix for this is usually to add before the line so that they don't overlap
we might want to consider changing to bypass the type-based cache so it catches ordering bugs like this cc
I don't understand how dry run is relevant here, isn't this a problem in all cases? Dry run and real should have roughly the same ensure graph to the extent possible and our tests rely on that... It also seems like based on the linked PR here this assertion is always guaranteed to show up at runtime pretty much constantly anytime someone accidentally adds additional nesting with a group? I could see that the right fix is to track the group and end + restart it so that there's no nesting and instead a linear non-nested list of groups...
dry-run and real have the same problems, yes. my idea was to do extra checks in dry-run so that without arguments would have caught this - the reason it only gets triggered with the filter is because normally, an earlier Step will happen to call , so the dynamic GHA check never gets run. correct. i was hoping that the check was eager enough they'd notice immediately and fix it in order to make CI pass, but this issue shows that it's non-trivial to do so because of the way it depends on the cache. this is how dry-run gets involved - when it's enabled, bypassing the cache is cheap and we can just do it unconditionally, which would have caught this bug before it got merged. hmm, that might handle our current cases ok, but it's not correct in general - consider something like that will split up the single message before and after, which doesn't seem quite right, although i suppose it might be better than panicking?
Ah, I see. I'm not convinced that we'd not stop catching other problems and/or introduce them by changing dry run. The split example you suggest feels right to me - in some sense more right - it means we are putting things in finest granularity groups. It also matches what we do for metrics emission, I believe... I will say that I don't really understand the value in the grouping, so perhaps that would change my thinking there.... At minimum, we might consider not panicking outside of GHA workloads, since the grouping doesn't matter then?
Change:
<ins> // Test that no help message is emitted that suggests renaming the // associated type from a non-local trait pub trait NewIter: Iterator { type Item; } impl<T> Clone for Box<dyn NewIter<Item = T>> { //~^ ERROR the value of the associated type `Item` in `Iterator` must be specified fn clone(&self) -> Self { unimplemented!(); } } pub fn main() {} </ins>

Discussion:
Given the following code: The current output is: is wrong, specifying another isn't going to fix the problem. Writing just has a suggestion where`, which is good, but the concrete syntax would be nice. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
We probably should modify E0191 to hint that an supertrait's associated type is shadowed. I think E0719 here is fine to keep as-is, imo.
I agree the message for E0719 is good as-is.
Is this issue fixed ? If not can I take this up, please. Also how exactly should E0191 be modified. Imo, I don't think E0191 should pop up in this case as E0719 conveys the message.
claim
claim
Ask for help How do I specify the association type of supertrait with the same name? In other words, is there an easy way to modify the code in the issue to make it pass compilation? Here's my clumsy way of creating a new trait.
Is this issue still open? If so I would like to take a crack at it.
If you can still reproduce it, then yes indeed. assign
Error: Parsing assign command in failed: ...'zyDutchman' ''... Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
I have now a hint about the shadowing: But I am not quite sure about what to do about the actual message. Do we want to suggest renaming to something else Or do we want to suggest the work-around by
If the trait is local, then we could suggest renaming it. It's not required to be super specific here--we could just note the conflict to make the user aware of it, for example.
I have updated the help message so that this case: gives this error message: The rename help message is emitted for both the super trait and the subtrait, if they are local. I think I am ready to make a merge request, or does somebody have something else to add?
I recommend you to just open a PR. Any further discussions can happen over there :)
Change:
Node::GenericParam(param) => param.name.ident().name, Node::Binding(&Pat { kind: PatKind::Binding(_, _, l, _), .. }) => l.name, Node::Ctor(..) => self.name(self.get_parent_item(id)), <del> _ => bug!("no name for {}", self.node_to_string(id)) </del> <ins> _ => return None, }) } pub fn name(&self, id: HirId) -> Name { match self.opt_name(id) { Some(name) => name, None => bug!("no name for {}", self.node_to_string(id)), </ins> } }

Discussion:
I wanted to quickly prototype a bit of code involving tokio and some shared state but ran into a rustc panic: I installed by running rustup update a few hours back. In my code (see below) there seems to be a mistake, having a lock living too long i suppose. The following code leads to the error (based on ) : Unfortunately I could not remove unnecessary parts of the code without making the panic go away. Might this has something to do with detecting the lock lifetimes?
ICE occurs in:
Error before: Regression in cc (I'm on a MCVE)
triage: P-high, removing nomination tag.
Here we go: So takes a type that is , but isn't . That's causing the ICE.
modify labels: -E-needs-mcve
Not sure how to express the for the MCVE here. You can of course use a new struct (like I did before with ), or use a . Interesting this works with as well, but not with other (custom) traits. Maybe because is an ?
Fixed output:
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(unsize, coerce_unsized)] #[repr(packed)] struct UnalignedPtr<'a, T: ?Sized> where T: 'a, { data: &'a T, } fn main() { impl<'a, T, U> std::ops::CoerceUnsized<UnalignedPtr<'a, U>> for UnalignedPtr<'a, T> where T: std::marker::Unsize<U> + ?Sized, U: ?Sized, { } let arr = [1, 2, 3]; let arr_unaligned: UnalignedPtr<[i32; 3]> = UnalignedPtr { data: &arr }; let arr_unaligned: UnalignedPtr<[i32]> = arr_unaligned; } </ins>

Discussion:
My code is about 500 lines long. I'm running up against an assignment deadline, so I don't have time right now to make a minimal demonstration. But if needed I can do so after Thursday, if someone hasn't gotten to it already. Sorry to dump and run. I normally try to be better about bug reports. :/ I expect this to be related to my copy paste error with repeated if clause: EDIT: Removed code, as there is a minimal example below.
Minimal example: Gives output:
I like to check back in on my issues from time to time to ensure that they haven't become invalid. I found that this issue still exists in the 2017/12/11 nightly ().

The following code ICEs on x8664 linux Suspect that it's this line (expecting that a struct with size 8 has 1 field) ICE message: cc
This isn't fixed, example should have had a or a attribute to make sure that the function is exported.
. CC
These "components" are not exactly struct fields, but rather hardware registers. The alignment padding probably triggers an edge case, I'll have to look deeper.

I found out that doesn't work, so I got a bit creative and tried this (reduced example): Which lead to this: It just prints an error on stable (1.17.0): And of course:
I ran into this with declarative macros on
Panics with the same error on 1.18.0 stable now:
Now this works, but it breaks proc-macro derives on the same item (parsing fails). Should I report that bug to a different location? It sort of feels like it's rustc's fault, as it's passing the proc-macro invalid syntax. I think it's odd that a macro can legally expand to invalid syntax...
That sounds a rust-lang/rust problem, yes. Have you filed an issue? I'd love to see a short example of the failure.
I've opened another issue for it:

$ RUST_BACKTRACE=1 rustc $ cat $ rustc --version --verbose
Looks like this was fixed. Output with current nightly as per playground:
Yeah, this was fixed. Marking as E-needstest.
Change:
// X to Y due to Rayon waiting and a true dependency from Y to X. The algorithm here // only considers the true dependency and won't detect a cycle. if !found_cycle { <del> if query_map.len() == 0 { panic!("deadlock detected without any query!") } else { panic!("deadlock detected! current query map:n{:#?}", query_map); } </del> <ins> panic!( "deadlock detected as we're unable to find a query cycle to breakn current query map:n{:#?}", query_map ); </ins> } // FIXME: Ensure this won't cause a deadlock before we return for waiter in wakelist.into_iter() { waiter.notify(registry); } <del> on_panic.disable(); </del> } #[inline(never)]

Discussion:
I noticed that when parallel rustc panics due to deadlock, it would say instead of . Is this intended?
Hm, I did recently land but I'm not sure if it would cause this issue. It should only affect threads that Rust doesn't create itself and in any case it switches the default name from (which gets rendered as ) to the OS thread name (if available). So if anything I'd have thought it would have the opposite effect. Though maybe there's something about parallel's deadlocks I'm missing.
I think you're good since the problem is older than your pr :D
Oh good! I mean bad, but I was dreading a very long debugging session
well, if you feel bored or something.... :upsidedownface:
Serial rustc creates a single thread called rustc. I assume parallel rustc just doesn't name its rayon threads, no debugging session ahead.
We create a new thread to look for query cycles, it's unnamed at the moment and that's where the panic happens.