jiebi/CodeConvo huggingface dataset:
Change:
/// This property cannot be checked by the compiler, and therefore `Eq` implies /// `PartialEq`, and has no extra methods. /// <del> /// This trait can be used with `#[derive]`. </del> <ins> /// ## Derivable /// /// This trait can be used with `#[derive]`. When `derive`d, because `Eq` has /// no extra methods, it is only informing the compiler that this is an /// equivalence relation rather than a partial equivalence relation. Note that /// the `derive` strategy requires all fields are `PartialEq`, which isn't /// always desired. /// /// ## How can I implement `Eq`? /// /// If you cannot use the `derive` strategy, specify that your type implements /// `Eq`, which has no methods: /// /// ``` /// enum BookFormat { Paperback, Hardback, Ebook } /// struct Book { ///     isbn: i32, ///     format: BookFormat, /// } /// impl PartialEq for Book { ///     fn eq(&self, other: &Self) -> bool { ///         self.isbn == other.isbn ///     } /// } /// impl Eq for Book {} /// ``` </ins> #[stable(feature = "rust1", since = "1.0.0")] pub trait Eq: PartialEq<Self> { // FIXME #13101: this method is used solely by #[deriving] to

Discussion:
I'm using s as keys in a BtreeMap. I have to look up the map ~15 million times per second (10G ethernet line rate). Ipv4Addr cmp() compiles to this on my system (linux x86-64, rustc 1.10.0-nightly ( 2016-05-21)) Which seems kinda inefficient for a thing which is basically u32. I guess part of the reason is the which converts it to an array(!) first. I copied the definition and implemented Ord like this: It's about 10 times faster on my .
Nice find! Want to send a PR for this? Looks like something that'd be more than welcome :)
Change:
"env_logger 0.4.3 (registry+https://github.com/rust-lang/crates.io-index)", "html-diff 0.0.4 (registry+https://github.com/rust-lang/crates.io-index)", "log 0.3.8 (registry+https://github.com/rust-lang/crates.io-index)", <del> "pulldown-cmark 0.0.14 (registry+https://github.com/rust-lang/crates.io-index)", </del> <ins> "pulldown-cmark 0.1.0 (registry+https://github.com/rust-lang/crates.io-index)", </ins> ] [[package]]

Discussion:
generates different HTML under and not. Not only does this trigger what's effectively a spurious warning, but it doesn't render correctly either. cc , marking this as p-high
This was fixed by google/pulldown-cmark rustdoc just needs to update its version of pulldown-cmark.
The thread in that issue says it was released in 0.0.15. we're pulling in 0.0.14 for rustdoc, but also 0.1.0 for mdbook. I'll see if i can update the dependency for rustdoc and pull it in.
updates Pulldown for rustdoc and fixes this.
I am not sure this actually fixes the warnings, as they use different IDs and such. I'm testing this locally right now though; expect an update in ~20 minutes
Change:
<ins> // check-pass #![feature(const_generics)] //~^ WARN the feature `const_generics` is incomplete and may cause the compiler to crash struct Const<const N: usize>; impl<const C: usize> Const<{C}> { fn successor() -> Const<{C + 1}> { Const } } fn main() { let _x: Const::<2> = Const::<1>::successor(); } </ins>

Discussion:
This code (): results in an ICE:
Isn't that a close cousin of
Not really, this is an associated function rather than an inner function.
I'm investigating this. Still repros on . With : <details<summaryBacktrace </summary</details
After investigating, the current ICE is caused by the () inside of not being able to locate the generic parameter it is trying to substitute for. The code at fault is: Which should try and find based on the (), but the current code only handles the situation like .
No longer ICEs, I believe down to Looking at the backtrace on nightly-2019-12-05 this seems related to and also
This no longer ICEs OR errors, at least for me. What backtrace do you mean? AFAICT this can be closed.
Whoops, wrote the wrong date down. I meant the nightly when it did ICE, it was 2019-12-01 or thereabouts. Yeah it can be closed once there's a regression test
Change:
<ins> // check-pass #![feature(const_generics)] //~^ WARN the feature `const_generics` is incomplete and may cause the compiler to crash struct Const<const N: usize>; impl<const C: usize> Const<{C}> { fn successor() -> Const<{C + 1}> { Const } } fn main() { let _x: Const::<2> = Const::<1>::successor(); } </ins>

Discussion:
paniked when I tried to use GAT, I didn't know does not support it then. Anyway I think it is not supposed to panic. I have confirmed with version 1.39 on Windows, my PC version 1.36 on Linux. It said,
Seems a duplicate of , I did not noticed it when I was opening this issue, sorry. There is also a small difference that I did not turn on
cc &
This should be fixed in the next nightly

This is a toy example I made in order to later make tests which run for with . This is the error I get: Error notes: - compiler flags: I don't know if this kind of pattern is intended as part of the feature or in its future, but if not, I think it can be satisfied by using a procedural macro so that's probably alright. The point of the pattern, as I mentioned at the beginning of the post, is to be able to test a particular generic type's implementation up to an arbitrary range of numeric constants. While implementing another project to help test the feature, I stumbled upon the problem of wanting to test hundreds of different constants, but having no way of doing so with say, a loop over a range of constants. This is one way I thought of making it work. Am I making the right decisions here? How should I go about testing hundreds of constants? Thanks :)
Note: another example that also panics. I know, yes, expressions aren't yet supported as const parameters. But it has the same panic, which is WEIRD! When I wrote this one, I thought "okay maybe inside a statement, the compiler won't try things like because the case when is is already covered... and with exhaustiveness check it should know that N = 0 won't enter the second branch". But I must be wrong there, or otherwise how did it panic? Error:
Minified: I'm pretty sure that I saw this ICE before, but I can't find it ;/
This is just a result of having an expression () as a const generic argument. I don't actually think there's a canonical issue, though many of the issues are essentially the same. is the best tracking issue.
No longer ICEs on the latest nightly
Oh, the new output is interesting. It probably needs to be monomorphized so that the compiler detects the infinite recursion. And then we could also write one that doesn't have infinite recursion :3 In order to force an error, a test function should suffice right?
What do you mean?
I mean that I imagined it might detect that the function recurses infinitely onto itself. But I guess it reads it lazily, and lets monomorphization do the job of recursing the function? which would make a lot of sense to me.
Change:
}; match loc { Some(root) => { <del> try!(write!(f, "<a href='{}{}/primitive.{}.html'>", </del> <ins> try!(write!(f, "<a class='primitive' href='{}{}/primitive.{}.html'>", </ins> root, path.0.first().unwrap(), prim.to_url_str()));

Discussion:
links should have colors to highlight that they are links: ! Some find it difficult to know which items are links. [EDIT] Removed sidebar circles. Never thought they needed changing.
has the same issue: ! [EDIT] Removed sidebar circles. Never thought they needed changing.
Totally agree. Also, instead of colors, we could use dashed underlines to indicate links while still keeping the same feel. (I disagree about the sidebar as well, I think its normal to expect those to be links, because they're in a sidebar without any text)
Sidebar is fine, thats a pretty normal convention to have those as links. At first glance I didn't realize most of the text in the main doc area was clickable however, I really like the idea of having the dashed underlines. +1
Didn't think sidebar necessarily should change. Was just highlighting black links. Edited pictures to removed sidebar circles.
Really quick mockup:  It doesn't show in the screenshot, but the last bool has the mouse over it, so it's darker.
code is and maybe some sort of style so it doesn't show up on the [src] link
CC: Don't have a branch but this is probably a straightforward fix if you decide on a style. Or if you like nightpool's suggestion.
I like that style, I think. I am bad at looks, though.
If there are any other decent styles worth pursuing (different brown variant, solid underline, combo, red...I'm just guess here), a quick mockup of them would allow easy compare and contrast. It would allow an easier/faster decision.
+1 from me
I'm currently playing with rustdoc. I may try to implement this once the docs are built.
Change:
|                  ^ recursive `async fn` | = note: a recursive `async fn` must be rewritten to return a boxed `dyn Future` <ins> = note: consider using the `async_recursion` crate: https://crates.io/crates/async_recursion </ins> error[E0733]: recursion in an `async fn` requires boxing --> $DIR/mutually-recursive-async-impl-trait-type.rs:9:18

Discussion:
We should suggest the use of when writing :
Is there any precedent for the compiler suggesting an external crate?
Yes, for async traits the compiler suggests to use :
As pointed out, we do for . We normally wouldn't recommend one crate over another ("don't play favorites"), but for small, single use, specialized crates that fill a common language "hole" that we might be working towards "plugging", I think it is a much better experience to immediately unblock newcomers than send them to a user forum to ask how to get around the limitation. The current error gives some idea of how to fix this, but not nearly enough for an even moderately knowledgeable Rust user to fix the problem without some searching. That being said, thanks for double checking and mildly pushing back on a potentially controversial and "uncommon" request. That is important for the health of the project.
Change:
<ins> //~ ERROR overflow evaluating the requirement `T: Trait<_>` #![feature(specialization)] #![allow(incomplete_features)] pub trait Trait<T> {} default impl<T, U> Trait<T> for U {} impl<T> Trait<<T as Iterator>::Item> for T {} fn main() {} </ins>

Discussion:
The following code () produces
Triage: still ICEs
This ICEs since modify labels: +regression-from-stable-to-stable
Change:
<ins> #![deny(rustdoc::broken_intra_doc_links)] //~^NOTE the lint level is defined here /// [`Foo::bar`] /// [`Foo::bar()`] //~^ERROR incompatible link kind for `Foo::bar` //~|HELP to link to the field, remove the disambiguator //~|NOTE this link resolved to a field, which is not a function pub struct Foo { pub bar: u8 } </ins>

Discussion:
Unfortunately I don't have an easy-to-repro case. This happened while working on Rocket's docs. I renamed a method which made a previously valid link invalid and I got this ICE. Fixing the doc link fixes the error. Backtrace from rustc 1.54.0-nightly ( 2021-05-21) follows: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
If someone can compile a build of rustdoc that comments out this line: you should get a much better error message that says exactly what went wrong (it will start with "incompatible link kind"), and that should give an idea of where the bug is.
can you link to the exact commit of Rocket that caused the ICE?
This is the current tip, You may be able to replicate this by referencing in the struct's docs in and then changing the method's name to something else. If this fails, I will try to create a reproducible case.
MCVE: label -E-needs-mcve
claim
Error: Parsing relabel command in failed: ...'needs-MCVE' '): rs'... Please let know if you're having trouble with this bot.
Error: Parsing relabel command in failed: ...'needs-mcve' '): rs'... Please let know if you're having trouble with this bot.
Change:
[[package]] name = "rustix" <del> version = "0.38.14" </del> <ins> version = "0.38.19" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" <del> checksum = "747c788e9ce8e92b12cd485c49ddf90723550b654b32508f979b71a7b1ecda4f" </del> <ins> checksum = "745ecfa778e66b2b63c88a61cb36e0eea109e803b0b86bf9879fbc77c70e86ed" </ins> dependencies = [ "bitflags 2.4.0", "errno",

Discussion:
IIRC we agreed upon the notion of a "slot", which is a simple way to create a mutable interior value. This lets us abstract over the mutable and immutable vectors without the subtyping relation that "mutable?" introduces, which is painful (and which we never got right in the presence of generics). So you could construct a slot using, say, , and that creates a mutable pseudo-box that is interior. Slots have no representation at the IR level; they're purely a way to help us enforce immutability restrictions. would become , would become , etc. This may be appropriate for the first milestone, depending on how serious we consider the type soundness hole with generics to be for 0.1.
So taking the value of a slot in a non-lvalue context would be an error?
Actually thinking through this more, slots have several weird issues relating to autoderef and generic functions. Talked this over with Dave and I think it makes sense to keep , but to fix the issue with covariance/invariance and rename it to something a little less gross ( maybe?)
Dupe of issue .
Change:
<ins> // issue rust-lang/rust#121463 // ICE non-ADT in struct pattern #![feature(box_patterns)] fn main() { let mut a = E::StructVar { boxed: Box::new(5_i32) }; //~^ ERROR failed to resolve: use of undeclared type `E` match a { E::StructVar { box boxed } => { } //~^ ERROR failed to resolve: use of undeclared type `E` } } </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

<!-- [31mICE[0m: Rustc '-Zcrate-attr=feature(constrefstostatic) -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: expected wide pointer extra data (e.g. slice length or trait object vtable)', 'error: internal compiler error: expected wide pointer extra data (e.g. slice length or trait object vtable)' File: --auto-reduced (treereduce-rust): &lt;details&lt;summary&lt;strongoriginal code&lt;/strong&lt;/summary&lt;poriginal: </p</detailsVersion information Command: &lt;!-- Include a backtrace in the code block by setting in your environment. E.g. . --&lt;details&lt;summary&lt;strongProgram output&lt;/strong&lt;/summary&lt;p&lt;/p&lt;/details&lt;!-- query stack: [evaltoallocationraw] const-evaluating + checking [evaltoconstvalueraw] simplifying constant for the type system [analysis] running analysis passes on this crate --
cc
You can add to get this kind of stacktrace:
Change:
<ins> // check-pass #![feature(return_position_impl_trait_in_trait)] #![allow(incomplete_features)] trait Foo<T> { fn foo<F2: Foo<T>>(self) -> impl Foo<T>; } struct Bar; impl Foo<u8> for Bar { fn foo<F2: Foo<u8>>(self) -> impl Foo<u8> { self } } fn main() {} </ins>

Discussion:
While working on an experimental runtime and using a couple of experimental features I found that the compiler while in resolving the async call on a trait crash badly. This is a minimal reproducible example and this is the stacktrace generated N.B: I guess this happens with any runtime? BTW also if happens only with rio the compiler should not crash, but I do not think this is related to a specific runtime, but I guess instead, the runtime triggers the resolution of the futures <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label +A-async-await +T-compiler
In the meanwhile, I will try to swim inside the codebase to catch the problem! claim
this is fixed by .
Minimized so it doesn't depend on rio:
Cool great work :)

gives happens with either rustc 1.66.0-dev () 66.0-nightly (2022-09-25 )
label +F-asyncfnin_traits
label +T-compiler +C-bug +I-ICE +requires-nightly Please use the ICE issue template for subsequent ICE issues. Thanks.
This is fixed by

I tried this code: I expected this to compile without error, since it is implementing the trait correctly. Instead, the following error was shown: It suggests replacing the code with the code I already have, which doesn't make much sense, as well as complaining that two things which appear identical are not. . : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label +T-compiler +requires-nightly +F-returnpositionimpltraitin_trait +D-invalid-suggestion
claim
Change:
Ok(s) if s.is_empty() => return, Ok(_) => {} } <ins> let color_logs = match std::env::var(String::from(env) + "_COLOR") { Ok(value) => match value.as_ref() { "always" => true, "never" => false, "auto" => stdout_isatty(), _ => early_error( ErrorOutputType::default(), &format!( "invalid log color value '{}': expected one of always, never, or auto", value ), ), }, Err(std::env::VarError::NotPresent) => stdout_isatty(), Err(std::env::VarError::NotUnicode(_value)) => early_error( ErrorOutputType::default(), "non-Unicode log color value: expected one of always, never, or auto", ), }; </ins> let filter = tracing_subscriber::EnvFilter::from_env(env); let layer = tracing_tree::HierarchicalLayer::default() .with_indent_lines(true) <del> .with_ansi(true) </del> <ins> .with_ansi(color_logs) </ins> .with_targets(true) .with_thread_ids(true) .with_thread_names(true)

Discussion:
When debugging a large Miri trace, I like to put the trace into a file that I can analyze and search through in an editor. Unfortunately, since the recent logging changes, that leads to a lot of garbage in the file: Looks like the color escape sequences are printed even when redirecting to a file. This makes working with the logfile much harder than it was before. Is there a way to fix that? Cc
This is the fault of I should be checking for whether the terminal supports colors before activating colors
A workaround until then is to use
How can I run miri from the rust repo? (i.e. built using )
You can run the test suite with , but that's not what you were asking... that's not supported yet unfortunately:
Until then, . Some of the commands might need adjusting though as changed.
Ah, thanks! I forgot about that part of the docs :)
Hmm, I'm getting this error: I'm using the latest master rustc and the latest miri. Is miri broken right now? EDIT: Oh, I think I need .
Yeah looks like you are using the wrong stage or so. The docs are from back when stage 2 was the default...
I'm afraid the problem was not solved by that PR. When I run Miri like this locally I still get all the ANSI codes in that logfile, which makes the file very hard to work with.
Looks like the code tests , but logging goes to stderr so this is the wrong test.
Hmm, I guess I didn't notice any issues because I always redirect stderr to stdout and then view that.
Working on a fix.
Yeah, for now using to redirect both to the logfile is an okay work-around.
FYI you can view the original color with , which prints them directly to the terminal. That doesn't work in an editor, though.
Change:
LL |     x.a = 1;  //~ ERROR |     ^^^^^^^ use of possibly uninitialized `x` <del> error: aborting due to previous error </del> <ins> error[E0594]: cannot assign to `x.b`, as `x` is not declared as mutable --> $DIR/reassignment_immutable_fields_overlapping.rs:23:5 | LL |     let x: Foo; |         - help: consider changing this to be mutable: `mut x` LL |     x.a = 1;  //~ ERROR LL |     x.b = 22; //~ ERROR |     ^^^^^^^^ cannot assign error: aborting due to 2 previous errors </ins> <del> For more information about this error, try `rustc --explain E0381`. </del> <ins> Some errors occurred: E0381, E0594. For more information about an error, try `rustc --explain E0381`. </ins>

Discussion:
review comments:
triage: P-medium. (We should look into this, but even if its wrong, I'm not going to push to a backport its hypothetical bug fix.)

review comments: For the record, here's the relevant part of the test in question ():
This should be NLL-complete, not NLL-sound, right?
Yeah, it should. My bad.
triage: P-high, not not Release milestone. This issue is bad enough for fix quickly, but there's no reason to beta-backport (as I explained on the PR itself here )
Change:
// run-fail <del> // error-pattern:assertion failed: `(left == right)` // error-pattern: left: `14` // error-pattern:right: `15` </del> <ins> // error-pattern:assertion `left == right` failed // error-pattern:  left: 14 // error-pattern: right: 15 </ins> // ignore-emscripten no processes fn main() {

Discussion:
The custom message in macro is shown right after the . This is hard to read because the value strings could be very long. I think it is better to print the custom message (if available) on a separate line. The above (playground) prints this: Note that custom message and the location in source are still on the same line <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I will try it. claim
Note that the linked PR, , has a lot of review comments. I think rebasing that PR and addressing the comments would already be very close to landing this change.
(taking over due to inactivity) claim
:tada: Horray! It only took 548 days (1.5+ years) since I created on Feb 14th, 2022. Numerous commits. Tens of people. 4 PRs... 100s of files. All to change a few lines of output :) Special thanks to for all the support!
Change:
} /// Parses inline const expressions. <del> fn parse_const_expr(&mut self, span: Span) -> PResult<'a, P<Expr>> { </del> <ins> fn parse_const_block(&mut self, span: Span) -> PResult<'a, P<Expr>> { </ins> self.sess.gated_spans.gate(sym::inline_const, span); self.eat_keyword(kw::Const); let blk = self.parse_block()?;

Discussion:
As soon as I've seen the new inline_const feature, I've tried to find some use cases for it in my code, and I did find only very few of them, unfortunately, and one of the two uses cases could be reduced to this: That gives errors: So I am not sure if this is a bug report or an enhancement request.
Note that this does work in expressions ():
Support for ranges in patterns ( or ) needs to be separately, to and respectively.
Ohh I've just realized that we had this issue opened, I've fixed this in Going to adjust description of the PR accordingly so it closes this issue when merged.
Change:
- name: x86_64-msvc-ext env: SCRIPT: python x.py --stage 2 test src/tools/cargotest src/tools/cargo && src/ci/docker/host-x86_64/x86_64-gnu-tools/checktools.sh x.py /tmp/toolstate/toolstates.json windows <ins> HOST_TARGET: x86_64-pc-windows-msvc </ins> RUST_CONFIGURE_ARGS: --build=x86_64-pc-windows-msvc --enable-lld --save-toolstates=/tmp/toolstate/toolstates.json DEPLOY_TOOLSTATES_JSON: toolstates-windows.json <<: *job-windows-8c

Discussion:
We currently run Miri on tests a few select targets: However, that's not all tier 1 targets, so e.g. x8664-apple-darwin is not covered, and today's nightly contains a Miri where some APIs are broken on x8664-apple-darwin. It'd be great if we could run (some) Miri tests on all tier 1 targets. Note that Miri tests can be run on any host so this does not require running on more hosts. However we'd probably not want to test all targets on all hosts, so we need some way in to determine which host we are on, and spread the test jobs across the hosts. Also, depending on how tight our time budget is here, we might want to not run all tests -- just running the "pass" tests should generally be sufficient and can save a bunch of time. Cc -- in particular, (a) how can I check for the host in , and (b) how tight is our time budget for the "tools" builders?