jiebi/CodeConvo huggingface dataset:
Change:
counter_increment_sites: IndexVec::new(), bcb_counters: IndexVec::from_elem_n(None, num_bcbs), bcb_edge_counters: FxHashMap::default(), <del> bcb_has_incoming_edge_counters: BitSet::new_empty(num_bcbs), </del> expressions: IndexVec::new(), };

Discussion:
<!-- [31mICE[0m: Rustc '-Cinstrument-coverage -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'attempt to add a to a BCB target with existing incoming edge counters'', 'thread 'rustc' panicked at 'attempt to add a to a BCB target with existing incoming edge counters'' 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: [mirpromoted] promoting constants in MIR for [mirborrowck] borrow-checking [typeofopaque] computing type of opaque [typeof] computing type of [checkwellformed] checking that is well-formed [checkmodtypewf] checking that types are well-formed in top-level module [analysis] running analysis passes on this crate --
cc ^_^
Further reduced:
(Also note that even before this presumably would have still ICEd, because the only thing we did with that error was unwrap it.)
I think the assertion is just incorrect in this case. Normally a BCB will only have a physical counter if it has exactly one in-edge. If it has multiple in-edges, it will get an expression that sums up all of its in-edges, most of which will have physical counters. That's what the assertion is verifying. However, if a BCB has an out-edge back to itself (i.e. ), it gets a physical counter regardless. The assertion doesn't account for this, and fails. Perhaps the reason we haven't seen this before is that the other in-edge to the loop node usually happens to be the one chosen to get an expression, so the assertion never sees the two-counters case.
I tried to fix the assertion itself, but that ended up being pretty complicated. The information we'd need isn't readily available in the place that we need it, and there's also a related assertion in that has the same problem. Given that these assertions aren't load-bearing (the code should work fine even if it's violated), I'm inclined to just rip them out. They only exist as a holdover from the original implementation anyway.
Change:
// Test that rustdoc will properly load in a theme file and display it in the theme selector. <del> use run_make_support::{htmldocck, rustdoc, source_path, tmp_dir}; </del> <ins> use run_make_support::{htmldocck, rustdoc, source_root, tmp_dir}; </ins> fn main() { let out_dir = tmp_dir().join("rustdoc-themes"); let test_css = out_dir.join("test.css"); let no_script = <del> std::fs::read_to_string(source_path().join("src/librustdoc/html/static/css/noscript.css")) </del> <ins> std::fs::read_to_string(source_root().join("src/librustdoc/html/static/css/noscript.css")) </ins> .unwrap(); let mut test_content = String::new();

Discussion:
Some run-make tests refer to stdlib sources with which seems not ideal. suggested that we should introduce a helper to make this less fragile.
There is already the env var set by compiletest for the source root.
I'm actually dumb, we even already have in the support library:
That's a very descriptive environment variable name, lol
Change:
<ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. use std::thread; fn main() { thread::Thread::spawn(move || { // no need for -> () loop { println!("hello"); } }); } </ins>

Discussion:
$ rustc --version rustc 0.13.0-nightly ( 2015-01-01 15:51:08 +0000)
Replacing with spits out a warning to use loop instead but compiles and runs as expected.
This is largely because the has a type parameter indicating the return value of the closure. In the case of , the closure return value cannot be inferred (as the function never returns). In the case of the closure return value is because the compiler assumes all while loops eventually terminate. To use , you can invoke like so: Here the is a manual ascription of what the return type should be, and it can be to say that it's the "unit return value"
Actually, for diverging type variables (which is what a without a gets typeck'ed to) we normally fall back to . However, that happens at the very end of type checking and so the fall back will not be used for dispatch resolution. Maybe we should do it earlier, then.
Here's the same issue: As seen It took me a bit to realize the issue was actually regarding the channel type, as I thought it was referring to the thread's move fn itself with the error:
I'm stuck with the same-looking bug, but the loop is apparently not the cause: When I comment-out the line, I get no errors. When the line is there, I get the error. Unfortunately I don't yet know enough to figure out what's wrong with that line. However, the error message is extremely confusing.
My mistake was trying to use mutable state across threads. Using AtomicUsize solved the problem. To be clear: the only issue is that the message "unable to infer enough type information" is confusing because it has nothing to do with the real problem. The loop statement without break caused no problems for me.
I have the same issue event with the program in "A 30-minute Introduction to Rust": it has the same error:
Change:
// FIXME(conventions): implement shrink_to_fit. Awkward with the current design, but it should // be scrapped anyway. Defer to rewrite? <del> // FIXME(conventions): implement into_iter </del> /// `RingBuf` is a circular buffer that implements `Deque`. pub struct RingBuf<T> {

Discussion:
There's currently no method on . This might have been missed during collections reform, or was never implemented.
Change:
use rustc_ast as ast; use rustc_ast::ptr::P; use rustc_ast::tokenstream::TokenStream; <ins> use rustc_ast::visit::{self, Visitor}; </ins> use rustc_ast::{token, BlockCheckMode, UnsafeSource}; use rustc_data_structures::fx::{FxHashMap, FxHashSet}; use rustc_errors::{pluralize, Applicability, DiagnosticBuilder};

Discussion:
This has already tripped up some people which seem to get quite confused with this error message, so I'd rather we not regress here: I tried this code: I expected to see this happen: Code compiles fine: the type of is . Instead, this happened: The type of is not send, since the backing state-machine generator produced for it now captures part of the internals involving a reference to the , which is not . It most recently worked on: beta : modify labels: +regression-from-stable-to-nightly -regression-untriaged
Might be related to / ?
I was also suspecting one of those, although I have to admit not having looked into it any further
Does it work with btw ? That should completely disable drop range tracking. (I've launched a try build there so that we have artifacts ready for that soon). There were also recent changes in the formatting macros/machinery last week IIRC. That could be related as well. This should be easy enough to bisect, and make sure where the regression is coming from.
Answering my own questions: doesn't change this, my guess is that it's actually unrelated to initially landed as part of and that rollup's commit doesn't reproduce the issue the change I mentioned was and its commit does reproduce the issue. This PR seems to have caused it indeed.
Nice investigation
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high
Change:
passes_proc_macro_unsafe = proc macro functions may not be `unsafe` passes_skipping_const_checks = skipping const checks <ins> passes_invalid_macro_export_arguments = `{$name}` isn't a valid `#[macro_export]` argument passes_invalid_macro_export_arguments_too_many_items = `#[macro_export]` can only take 1 or 0 arguments </ins>

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. --I tried this code: I expected to see this happen: it shouldn't compile Instead, this happened: it compiles <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
For anyone who would like to work on this, the following code needs to be adjusted to check if the meta-item list is empty or if it only contains the identifier (i.e. only allowing the attribute to be or : Due to backward compatibility concerns, probably only a future-incompat warning should be issued if the verification fails. label T-compiler A-attributes
claim
First rust-lang/rust contribution I hope this goes well
Change:
// This simply repeats the same procedure but as right-aligned chunk instead // of a left-aligned one. The last byte must be exactly flush with the string end so // we don't miss a single byte or read out of bounds. <del> let i = haystack.len() - second_probe_offset - Block::LANES; </del> <ins> let i = haystack.len() - last_byte_offset - Block::LANES; </ins> let mask = test_chunk(i); if mask != 0 { result |= check_mask(i, mask, result);

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:
<ins> // When WF checking the hidden type in the ParamEnv of the opaque type, // one complication arises when the hidden type is a closure/generator: // the "parent_substs" of the type may reference lifetime parameters // not present in the opaque type. // These region parameters are not really useful in this check. // So here we ignore them and replace them with fresh region variables. // check-pass #![feature(type_alias_impl_trait)] #![allow(dead_code)] // Basic test mod test1 { // Hidden type = Closure['_#0r] type Opaque = impl Sized; fn define<'a: 'a>() -> Opaque { || {} } } // the region vars cannot both be equal to `'static` or `'empty` mod test2 { trait Trait {} // Hidden type = Closure['a, '_#0r, '_#1r] // Constraints = [('_#0r: 'a), ('a: '_#1r)] type Opaque<'a> where &'a (): Trait, = impl Sized + 'a; fn define<'a, 'x, 'y>() -> Opaque<'a> where &'a (): Trait, 'x: 'a, 'a: 'y, { || {} } } // the region var cannot be equal to `'a` or `'b` mod test3 { trait Trait {} // Hidden type = Closure['a, 'b, '_#0r] // Constraints = [('_#0r: 'a), ('_#0r: 'b)] type Opaque<'a, 'b> where (&'a (), &'b ()): Trait, = impl Sized + 'a + 'b; fn define<'a, 'b, 'x>() -> Opaque<'a, 'b> where (&'a (), &'b ()): Trait, 'x: 'a, 'x: 'b, { || {} } } fn main() {} </ins>

Discussion:
Since the nightly 2022-09-11, the following code doesn't compile anymore. <!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Minimized it a little
searched nightlies: from nightly-2022-01-01 to nightly-2022-09-30 regressed nightly: nightly-2022-09-11 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
cc
cc
I get the same ICE when using the current nightly in a complex Codebase. The works fine.
I think I minimized this to:

<!-- 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. --I tried this code: <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I found this error occurred by this commit through
Probably cc
Minimized: claim label F-typealiasimpl_trait T-compiler
This has caused crate and docs fail to build.
This just upgraded from bad diagnostics to ICE on latest nightly.
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. fn main() { let f = proc() {}; (proc() { f(); f(); //~^ ERROR: use of moved value: `f` })() } </ins>

Discussion:
compiles . Runs . Connection refused and segfault.
This is a bug in the treatment of captured variables. The line in question is: This is moving into the loop repeatedly when you should only be allowed to do it once. I think I've seen this bug before, but just in case, cc
thanks I've seen some reports of bugs like this before -- it's clear that we need to revisit the code used to check "once fns" -- it was as a temporary start towards support (under a -Z flag) and then pressed into full service, clearly not quite ready for prime time.
Nominating.
updated title to reflect the real issue at hand.
cc
Assigning 1.0, max(P-backcompat-lang, P-high). Gotta fix. edit: The use of above is sort of a joke: take the max of the two P-tag inputs. (Also, I originally wrote P-backcompat-libs, but I'm pretty sure that was a typo.)
Change:
help: use `Box::new()` instead | LL |     let _ = Box::new([5; 30]); <del> |             ~~~~~~~~~~~~~~~~~ </del> <ins> |             ~~~~~~~~~       + </ins> error: `box_syntax` has been removed --> $DIR/removed-syntax-box.rs:13:22

Discussion:
Found by grepping through the compiler via while reviewing an unrelated PR. File : File : : . or move source file . : . <details<summaryFull compiler output</summary</details:
Solution: Get rid of altogether and use a multi-part suggestion (, ).
Change:
| ObligationCauseCode::ObjectCastObligation(..) | ObligationCauseCode::OpaqueType ); <del> let expected_ty = data.term.ty().unwrap_or_else(|| self.tcx.ty_error()); </del> // constrain inference variables a bit more to nested obligations from normalize so // we can have more helpful errors.

Discussion:
thread panicked at 'called on a value', <details<summaryBacktrace</summary</detailsRegression in nightly-2022-12-04, in rollup , likely from (
Change:
<ins> error: generic parameters may not be used in const operations --> $DIR/issue-67945-3.rs:11:23 | LL |         let x: Option<S> = None; |                       ^ cannot perform const operation using `S` | = note: type parameters may not be used in const expressions = help: use `#![feature(generic_const_exprs)]` to allow generic const expressions error[E0392]: parameter `S` is never used --> $DIR/issue-67945-3.rs:9:12 | LL | struct Bug<S> { |            ^ unused parameter | = help: consider removing `S`, referring to it in a field, or using a marker such as `PhantomData` = help: if you intended `S` to be a const parameter, use `const S: usize` instead error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0392`. </ins>

Discussion:
The following ICE's on nightly and beta: <details<summaryBacktrace:</summary</details
Reduced: ICE most likely occurs in: I cannot seem to reproduce this without an , so cc
Reduced even more: (Please include all 3 variants thus far in a regression test.)
I looked into this briefly and found that on this line: has the value: Digging a bit deeper, the generics appear to be empty because of the following lines: I can confirm that adding makes this code compile, so I suspect that this is blocked on .
What would be the consequences of always returning the DefId?
It causes query cycle errors at the moment.
Discussed at T-compiler meeting. Due to all the known examples being compile-time errors, the ICE here does not seem so strong a hazard as to warrant weekly visits during triage. (Certainly failing more gracefully would be great. But its not something we're going to e.g. block a release on.) Downgrading priority to P-medium.
Some relevant examples. This gives an (incorrect) error on stable that does not hold: This ICEs on stable:
Is there a reason why we can't just disallow type parameters from appearing within constants during resolve, like we do for type parameters from outer functions? Obviously const generics/lazy normization willl loosen this rule.
good point, I imagine that might work.
Another variant on this bug:
Triage: The two examples that Centril posted ( and ) are no longer ICEs in the latest nightly. Possibly related to ?
Maybe we should just add tests then?
Sounds good! I'll do later.
Another variant (though likely the same): This gives a different to the original, despite being essentially the same code.
Triage: All the snippets including the original are no longer ICE with the latest nightly:
Change:
"regression-*", "perf-*", "AsyncAwait-OnDeck", <ins> "needs-triage", </ins> ] [glacier]

Discussion:
The GitHub issue for https://rust- so I can nominate it for the teams. I've noticed that we have many issues inside rust-lang/rust that are completely untriaged with no interactivity. I don't believe that this is due to lack of time, but simply due to lack of organization. I propose that every new issue gets the label. Then, members can see the issues with that label and triage them. That includes labeling the issues and maybe replying to them if there's a specific request, for example answering a question or asking for a reproduction. Ideally triage is done by someone with knowledge in the issue's area but that's of course not a hard requirement. The person can then just remove the label. The label can also be settable via rustbot so anyone can do this. I'm confident that we'd have enough time to triage all issues with that labeling system (I would certainly participate, as I've been doing for a while now). I'm not entirely sure about the best process for deciding this. The reception on Zulip was positive, but I want to make sure that everyone here is on aware and on board. Given the shared team ownership of this repo I'm going to nominate this issue for the three major teams, compiler, libs and rustdoc (rustdoc doesn't have a nomination label apparently, so I'll just here :D) . If they all agree with the change, we can implement it (by using the triagebot feature I : ).
cc
Sounds good. Libs team is on board.
:+1:
Discussed in T-compiler meeting on Zulip (): looks like a really good idea. label -I-compiler-nominated
it's working!
I think we shouldn't add <kbdneeds-triage</kbdif it's a tracking issue. What's your opinion? IIUC, this can be accomplished by
sounds good
Change:
<ins> trait Foo { fn method(&self) {} } fn call_method<T: std::fmt::Debug>(x: &T) { x.method() //~ ERROR E0599 } fn call_method_2<T>(x: T) { x.method() //~ ERROR E0599 } fn main() {} </ins>

Discussion:
I am working through this and is with such a challenge: So I tried it. : note: the method exists but the following trait bounds were not satisfied: help: items from traits can only be used if the trait is implemented and in scope; the following traits define an item , perhaps you need to implement one of them: help: candidate : help: candidate : help: candidate : The minimal code that produces the error message is The error message tells me that I need to implement a trait. Since I have already implemented it, I would be confused by the error message, and misled by it from the actual reason, failure to declare it in the signature. I think it would be better if the message is changed to note: the method exists but the following trait bounds were not satisfied: help: items from traits can only be used if the trait is implemented and in scope; the following traits define an item , perhaps you need to declare one of them for : help: candidate : help: candidate : help: candidate : On the other hand, if I actually drop the block , but declare in the signature, the error message is label: the trait is not implemented for note: required by which is straightforward enough.
Today, we suggest that the method exists, but we somehow fail to see that it exists on Minimum in the first note and then latter note it in the second note.
It still doesn't help a lot IMO... since the problem is the bound isn't declared in the signature, and nothing regarding declaration is mentioned. maybe change to
I think that can be easily fixed by checking if is not empty and using a different message in that case Do you have suggestion how the error should look like? Does that sound ok?
I don't think your error message communicates much more than the current one. I also think the error message is already straightforward enough. From my perspective, I think the problem is one of asymmetry in the help section. It mentioned "items from traits can only be used if the trait is implemented and in scope", but then went on to only suggest "perhaps you need to implement one of them". Excuse me for being insistent on this, but I believe the best way is to remind that to bring function into scope the trait bound needs to be declared as well as implemented.
LOL this is actually a duplicate of . There's even a .

I think we're talking about different cases (which may be another reason to split or reword the message). For methods the message says "method not found", but adds a note saying "the method exists", which I really don't like, because it's very easy to miss the nuance and interpret the message as nonsense "the method does not exist" "but it exists". I've explained more here:
With the output will be: