jiebi/CodeConvo huggingface dataset:
Change:
use mem; use char; use clone::Clone; <ins> use cmp; </ins> use cmp::{Eq, TotalEq}; use container::Container; use default::Default; use iter::{Filter, Map, Iterator}; use iter::{Rev, DoubleEndedIterator, ExactSize}; <ins> use iter::range; </ins> use num::Saturating; use option::{None, Option, Some}; use raw::Repr; use slice::{ImmutableVector, Vector}; use slice; <ins> use uint; </ins> /* Section: Creating a string

Discussion:
The current implement of functions like are naive string searches, not using a more intelligent algorithm like Boyer-Moore (with a comment referring one to ). Unfortunately that means we're trounced when performing operations like that. e.g. glibc's : and A cursory search found which might be interesting to experiment with. came up on
This is for the case where the needle is a single character. In the case above the rust version is as fast or faster than the C version. Maybe there is a bug in the case for short needles.
Change:
ignore = "0.4.10" opener = "0.4" merge = "0.1.0" <ins> once_cell = "1.7.2" </ins> [target.'cfg(windows)'.dependencies.winapi] version = "0.3"

Discussion:
introduced some checks which execute 4 times. They run unconditionally when executing , even if it is just to run tidy. On my system the wall time exceeds that of running tidy itself. I'll look into whether the checks themselves can be made be less wasteful. But if there are suggestions how to completely eliminate them or defer them while preserving their original purpose that would be great too. ! CC can you explain the purpose of running this in rather than erroring in ?
To know beforehand if the test should unconditionally be run or not. If the test is run and the npm package isn't installed, we panic. To be noted that we could make it go down to 2 by switching the order of : currently we check both "local" and "global". Switching the two of them will divide the number of calls by two. cc
I don't have installed, so it'll fail and no short-circuiting will happen regardless of order.
In case you don't have it it'll check 4 times indeed.
Hm, this does seem annoying. It's possible we could add some lazily-evaluated default condition so that this never runs if we're not considering default-on steps (if defaults are on, then these npm lists are likely quite fast in comparison to the rest of the logic).
Change:
<del> warning: unnecessary parentheses around function argument --> $DIR/issue-47775-nested-macro-unnecessary-parens-arg.rs:22:83 | LL |         #[allow(dead_code)] fn the_night_for_the_morrow() -> Option<isize> { Some((2)) } |                                                                                   ^^^ help: remove these parentheses ... LL | and_the_heavens_reject_not!(); | ------------------------------ in this macro invocation | note: lint level defined here --> $DIR/issue-47775-nested-macro-unnecessary-parens-arg.rs:3:9 | LL | #![warn(unused_parens)] |         ^^^^^^^^^^^^^ </del>

Discussion:
The latest beta contains a new? l lint that triggers on macro by example code. This does not necessarily make sense because macros could be used to construct nearly arbitrary custom syntax for example something requiring to wrap a single element into a parenthesis. The strange thing here is that seems to only happen on beta, not on nightly, not on current stable. Found via Error message: rustc version:
My head can't come up with an example that requires parentheses. macros are hygenic, so there should be no problem in omitting the parentheses and just writing will be fine. Can you give me a counter example?
A real world example is the diesel  macro. Somewhere in the inner it does some clever things to support plain types and tuples by just saying where is some repeated type variable. Depending on the number of actual types there this will result in which is a single type or which is a tuple. It's probably possible to rewrite that code doing the same stuff but that would involve a lot of duplication (Because than you would need to have a special case for a single type everywhere).
So somehing like this: You're right. The question is: should we remove the lint for all macros? Only for macros that contain repetitive expansions? (Is that even possible to detect?)
modify labels: A-lint T-compiler
Would be great to get that fixed till it is part of the next stable release.
This seems to occur first on nightly-2019-11-02
nominating for discussing at T-compiler + T-lang meeting, namely to take peoples' temperature with respect to the idea of just not linting this case when the flagged code appears as part of a macro definition.
also, marking as P-high w.r.t. answer the question(s) posed here. (I personally don't think the severity of the actual impact is likely to be worth a P-high rating; the priority is likely just temporary until the discussion happens.)
The language team discussed this last week. The general consensus was that we can stop linting when the redundant parens are inside the macro (as opposed to e.g. where the spans are from the outside). We believe this is fine as the lint is mostly a style thing which does not protect from anything correctness or performance related.
I've played a bit around with this issue today.

Seems like conditions need to be adjusted to also check if we are in macro expanded code. I've tried something like but that does remove more warnings that we want.
I think the questions have been basically answered in terms of what path we see best going forward. Self-assigning, removing I-nominated.
Change:
[The Embedded Rust Book] is targeted at developers familiar with embedded development and familiar with Rust, but have not used Rust for embedded development. [The Embedded Rust Book]: embedded-book/index.html <ins> [Rust project]: https://www.rust-lang.org </ins>

Discussion:
We have no link from to , and it is not good in terms of usability. I guess this is because is a verbatim copy of the raw output from . See how Python documents are organized: ! I think this is the relevant functionality of the Sphinx documentation tool for Python: We should aim for the same level of usability standard and should be flexible enough to achieve it.
Generally, people come to from But that might be a good thing to add it.
Also, I don't think this can be a rustdoc thing, because many, many rustdoc outputs are not hosted on rust-
(Rustdoc already lets you choose where the logo links to, iiirc, but it's usually the docs rather than another site.)
I'm not saying rustdoc should hard-code a link to If you write a Rust library and publicize its documentation, you might want a backlink from the generated HTML to I'm claiming there should be a general mechanism to realize such designs. Thankfully rustdoc supports these command line options which seem promising: I'll try see how they fit my proposal.
now links to , many times
Oh wait, this is the inverse issue, sorry for the noise! There hasn't been any change here.
Triage: may fix this, but there's been no change
redirects to today, but I think we probably want these links from e.g. as well so leaving open.
Triage: this would be pretty easily fixed by modifying the index page for
Change:
<ins> // check-pass #![feature(inherent_associated_types)] #![allow(incomplete_features)] struct Foo<T>(T); impl<'a> Foo<fn(&'a ())> { type Assoc = &'a (); } fn bar(_: for<'a> fn(Foo<fn(Foo<fn(&'static ())>::Assoc)>::Assoc)) {} fn main() {} </ins>

Discussion:
<!-- 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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Ow, my bad! claim
Change:
&& let [segment] = &attr_kind.item.path.segments[..] && segment.ident.name == sym::cfg && let Some(args_span) = attr_kind.item.args.span() <del> && let Ok(next_attr) = snapshot.parse_attribute(InnerAttrPolicy::Forbidden(None)) </del> <ins> && let next_attr = match snapshot.parse_attribute(InnerAttrPolicy::Forbidden(None)) { Ok(next_attr) => next_attr, Err(inner_err) => { err.cancel(); inner_err.cancel(); return; } } </ins> && let ast::AttrKind::Normal(next_attr_kind) = next_attr.kind && let Some(next_attr_args_span) = next_attr_kind.item.args.span() && let [next_segment] = &next_attr_kind.item.path.segments[..] && segment.ident.name == sym::cfg <del> && let Ok(next_expr) = snapshot.parse_expr() </del> { <ins> let next_expr = match snapshot.parse_expr() { Ok(next_expr) => next_expr, Err(inner_err) => { err.cancel(); inner_err.cancel(); return; } }; </ins> // We have for sure // #[cfg(..)] // expr

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: the following error was constructed but not emitted', 'error: internal compiler error: the following error was constructed but not emitted' File: --snippet: Version information but still crashes with ` 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: --
Reduced further: searched nightlies: from nightly-2023-11-17 to nightly-2023-12-02 regressed nightly: nightly-2023-11-21 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.7</summaryHost triple: x86_64-pc-windows-msvc Reproduce with: </detailsLooks like
This might be a duplicate of , now that I've taken another look at it
When I checked, was already fixed but this one wasn't
You're right-- doesn't reproduce with the latest nightly, but this one does, which I find strange since I thought they have the same root cause, which should address. (Hence also why I closed --it almost exactly duplicated the work in .)
Can be further reduced to

<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: the following error was constructed but not emitted', 'error: internal compiler error: the following error was constructed but not emitted' File: --snippet: 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: --
Regression in nightly-2023-11-21 ping
I found that the code snippet does not cause ICE anymore. Meta: Output:
Change:
} } <del> impl Encodable for Fingerprint { #[inline] fn encode<S: Encoder>(&self, s: &mut S) -> Result<(), S::Error> { s.emit_u64(self.0.to_le())?; s.emit_u64(self.1.to_le()) } } impl Decodable for Fingerprint { #[inline] fn decode<D: Decoder>(d: &mut D) -> Result<Fingerprint, D::Error> { let _0 = u64::from_le(d.read_u64()?); let _1 = u64::from_le(d.read_u64()?); Ok(Fingerprint(_0, _1)) } } </del> impl ::std::fmt::Display for Fingerprint { fn fmt(&self, formatter: &mut ::std::fmt::Formatter) -> Result<(), ::std::fmt::Error> { write!(formatter, "{:x}-{:x}", self.0, self.1)

Discussion:
Attempting to compile this example program using a nightly compiler: On a native mips big endian machine gives me this: If I compile to an object and dump the symbols, I see that the hash for is different between the object and the rlib file: After some debugging, I managed to work out that the value of for passed to the in is byteswapped when run natively compared to running on an x86 -mips cross compiler. I couldn't work out where this value originally comes from, but hopefully someone here knows. :) I also tried using a stable compiler, but it failed with the issue before getting to this stage.
cc
I don't have a MIPS machine right here, but it certainly looks that should be returning a , which should be endianness-correct (i.e. return the same 2 u64s) -
Does beta work, btw?
It looks like affects beta as well. I get the same error as on stable - this is with:
Change:
let message = if let Some(name) = last_generator .and_then(|generator_did| self.tcx.parent(generator_did)) .and_then(|parent_did| self.tcx.hir().as_local_hir_id(parent_did)) <del> .map(|parent_hir_id| self.tcx.hir().name(parent_hir_id)) </del> <ins> .and_then(|parent_hir_id| self.tcx.hir().opt_name(parent_hir_id)) </ins> { format!("future returned by `{}` is not {}", name, trait_name) } else {

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> fn main() { let x: i32 = 1; println!("{:?}", x.count()); //~ ERROR is not an iterator } </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. 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: The current output is: <!-- The following is not always necessary. --Ideally the output should look like: For some reason, this doesn't happen for all traits in . Eg Just gives Version: 1.53.0-nightly (2021-04-22 ) <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. 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. The output might also be different depending on the Edition. --
Some discussion on Discord suggests that might be a culprit. Trying with the variant produces as expected. So it looks like the trait bound is being honored for the search for the method, which is defined in the block, but not for the search for the method, which is defined in definition.
I suggest retitling this to "Compiler incorrectly (and inconsistently) finds methods on ".
I'd also like to suggest adding D-newcomer-roadblock because I've seen several other newcomers on Discord run into this confusing diagnostic.
I tried to replicate the incorrect diagnostic with a more minimal case than . It looks like it depends on the borrow mode of the receiver. This code : produces these errors: is a required trait method that takes a ref to , similar to (the doesn't seem necessary to exhibit these diagnostics). is a default trait method that moves , similar to most of the methods. It seems like a default trait method that moves is necessary to trigger this incorrect diagnostic. is a default trait method that takes a ref to , similar to . I've built a debugging version of the compiler and I'm trying to understand the debug logs for the trait and typechecking systems.
To elaborate on my prior comment: newcomers seem likely to encounter and be confused by this diagnostic. I ran into it myself by trying to call methods directly on , and I've seen several others be confused by that.

I think I've also seen newcomers be confused by trying to call methods directly on arrays. label +D-newcomer-roadblock
Change:
Codegen { query codegen_fulfill_obligation( key: (ty::ParamEnv<'tcx>, ty::PolyTraitRef<'tcx>) <del> ) -> Vtable<'tcx, ()> { </del> <ins> ) -> Option<Vtable<'tcx, ()>> { </ins> no_force cache_on_disk_if { true } desc { |tcx|

Discussion:
I'm seeing an internal compiler error on the following input (found by ): The error happens on stable, beta, and nightly.
This regressed in .
cc
triage: already has fix in pipeline. P-high. removing nomination label.
Change:
builder.info(&msg); let mut cargo = Command::from(cargo); <del> let is_expected = builder.try_run_quiet(&mut cargo); </del> <ins> let is_expected = builder.try_run(&mut cargo); </ins> builder.save_toolstate( tool,

Discussion:
When running for example, x.py would previously show the build (cargo) output when building cargo during , but that is no longer the case. Is that intentional? `
It's not intentional AFAIK, but I don't see a recent PR that could have broken this off the top of my head. Do you have a commit/timeframe where this worked correctly?
Hmm I would guess it still worked last weekend?
Are you sure cargo is actually being built? makes me think it's using cached stage 2 artifacts.
Might be
Yes, I can see rustc building cargo and its deps in htop while x.py does not print any updates :sweat_smile:
oh lol that would do it cc
Sounds like we do need there? I'll put it back then!
Is there not a way of doing things?
Yes, there's a try_run, that would be best.
Change:
/// `0`. fn from_variant( def: Def<'tcx>, <del> tag: Option<ScalarInt>, </del> <ins> tag: Option<(ScalarInt, VariantIdx, TagEncoding<VariantIdx>)>, </ins> (ty, layout): (Ty<'tcx>, Layout<'tcx>), total_size: Size, cx: LayoutCx<'tcx, TyCtxt<'tcx>>,

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'Size::sub: 0 - 1 would result in negative size'', 'thread 'rustc' panicked at 'Size::sub: 0 - 1 would result in negative size'' File: --auto-reduced (treereduce-rust): &lt;details&lt;summary&lt;strongoriginal code&lt;/strong&lt;/summary&lt;poriginal: </p</detailsVersion 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: [evaluateobligation] evaluating trait selection obligation [typeck] type-checking [analysis] running analysis passes on this crate --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
cc
On it! Thanks for the report.
Further minimized:
The cause here is neat. here is niche optimizable, with its second variant being subject to niche optimization. Typically, a niche-optimized enum has one tagless variant, and zero or more tagged variants laid out in the usual manner: the tag is placed, and then the rest of the fields follow. But reveals that's not what happens here. Because is a ZST, is placed at offset , rather than (following the tag). In other words: the tag is co-located with the field. This produces an ICE, because our assumption that fields follow tag is violated (a checked sub panics).
claim
Change:
// where `X` is the `impl Iterator<Item=T>` itself, // stored in `predicates_of`, not in the `Ty` itself. <del> self.check(item.id, self.inner_visibility).predicates(); </del> <ins> self.check(item.id, item_visibility).predicates(); </ins> } // Subitems of these items have inherited publicity hir::ItemConst(..) | hir::ItemStatic(..) | hir::ItemFn(..) |

Discussion:
Works on beta, but not on nightly. This breaks miri.
That was probably me. I'll have a look
Change:
<ins> error[E0425]: cannot find value `bar` in this scope --> $DIR/issue-104700-inner_scope.rs:7:8 | LL |     if bar == 2 { |        ^^^ | help: the binding `bar` is available in a different scope in the same function --> $DIR/issue-104700-inner_scope.rs:4:13 | LL |         let bar = 2; |             ^^^ error[E0425]: cannot find function `test_func` in this scope --> $DIR/issue-104700-inner_scope.rs:10:5 | LL |     test_func(1); |     ^^^^^^^^^ not found in this scope error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0425`. </ins>

Discussion:
When the error should mention bindings that are outside of the scope but within the same item <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Do you think we should suggest in this scenario? My local dev branch will suggest:
I removed it.
Change:
raw: self.first_bucket_raw(), hashes_end: unsafe { self.hashes.offset(self.capacity as int) <del> } </del> <ins> }, marker: marker::ContravariantLifetime, </ins> } }

Discussion:
Sorry, I'm not sure how to describe this very well in a sentence. I am able to mutably borrow the innermost values of a , delete the values, then reference them after they were deleted. This code compiles, runs, and barfs out strange numbers.
Little bit shorter example, without mutable borrows. But still fails to freeze :
nominating for 1.0 P-backcompat-lang
though this may be a library issue
weird This code is also valid: This is because the hashmap iterator just wraps the rawtable iterator, which just defers to the RawBuckets iterator, which is just a wrapper around two *mut's. That is, literally none of these iterators actually borrows the hashmap. Presumably this is fixable by taking a useless reference somewhere. The other thing I'm seeing is that there's , but the signature for Hashmap's iterator function is . How is this lifetime being elided? Is it doing the same thing as , or is something else happening? CC
Yep, it's eliding !
So there's two bugs here: the iterator doesn't borrow the map, and the references are being yielded as .
Assigning P-backcompat-libs, 1.0
thanks for fixing this! Great job!
Change:
= warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release! = note: for more information, see issue #64266 <https://github.com/rust-lang/rust/issues/64266> <del> error: aborting due to previous error </del> <ins> error: use of unstable library feature 'test': `bench` is a part of custom test frameworks which are unstable --> $DIR/bench.rs:7:5 | LL | use bench as _; |     ^^^^^ | = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release! = note: for more information, see issue #64266 <https://github.com/rust-lang/rust/issues/64266> error: aborting due to 2 previous errors </ins>

Discussion:
Hi there, I'm updating rust-sgx-sdk (solving rust-sgx-sdk ) to use latest rust nightly compiler to help the error info more ergonomic by the help of . However, the compiler always panics. Your help would be very much helpful. The current code is at . To reproduce this bug, please checkout branch and build sgxtstd as follows: And the reproducible failure info is: : rustc 1.40.0-nightly ( 2019-10-03) binary: rustc commit-hash: commit-date: 2019-10-03 host: x8664-unknown-linux-gnu release: 1.40.0-nightly LLVM version: 9.0 Backtrace:
It'd be helpful to have a more minimal example here I suspect -- for example, at least reducing to a single crate. cc since this deals with diagnostic machinery
It seems like this was introduced a month ago in , CC
I think I find the solution on my side: the removal of .
A working branch is baidu/rust-sgx-sdk : test-2019-10. Failing branch is librustc-bug-report. After I enable , the compiler starts to fail.
The minimum sample is as follows: and compile by
Fixed in
Cool!