jiebi/CodeConvo huggingface dataset:
Code change:
<ins> //@ edition:2021 fn main() { async { use std::ops::Add; let _ = 1.add(3); }.await //~^ ERROR `await` is only allowed inside `async` functions and blocks } </ins>

Related discussion:
text: <!-- [31mICE[0m: Rustc '--edition=2021 -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'no entry found for key'', 'thread 'rustc' panicked at 'no entry found for key'' 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: [hirownerparent] getting HIR parent of [checkunused_traits] checking unused trait imports in crate [analysis] running analysis passes on this crate --
cc
Minimal:
Code change:
/// } /// ``` #[stable(feature = "io_error_inner", since = "1.3.0")] <ins> #[inline] </ins> pub fn get_ref(&self) -> Option<&(dyn error::Error + Send + Sync + 'static)> { match self.repr { Repr::Os(..) => None,

Related discussion:
text: I am facing a problem while reading different kinds of binary formats. If you are going to read primitives like too often, then performance degrades. This is mainly due to the fact that returns box. Also it does boxing TWICE! doc link: I wrote simple bench to show pref problem. Use to get it We can clearly see that performance is degrading. The more calls it takes to read, the worse the results will be. The first very popular crate that comes to mind is . It mainly depends on the data format. But what if you need to receive data over the network? The attacker may abuse wrong data to make ton of pointless memory allocations. stdlib is also use often enough. Let's run a simple bash to make sure of this In many cases, you will see that it is used . stdlib sometimes create with macro, however it doesn't happen very often. Consider adding a new static method such as and new internal member of that's enum. How about using something like , but with static lifetime? : Update 07.03.2021: Benchmarks have been improved as per the comment. This should show the problem better.
The "std_err" bench is still pretty slow though
Yes, I probably made a mistake while copying the code for the benchmark of . It should be . However, this shows that not zero-cost.
This is fixed by
Turns out it was three times, if you also count the that the is copied into.
Running your benchmark (thanks!): Before: After: Looks like it isn't completely solved yet. Adding to now... :)
That fixed it.
Code change:
<ins> #![allow(incomplete_features)] #![feature(return_position_impl_trait_in_trait)] use std::ops::Deref; pub trait Foo { fn lol(&self) -> impl Deref<Target = String> { //~^ type mismatch resolving `<&i32 as Deref>::Target == String` &1i32 } } fn main() {} </ins>

Related discussion:
text: Here's a MVCE: I expected to see this happen: compilation fails because I'm clearly returning an instead of a Instead, this happened: bad codegen ("async fn resumed after completion") :
This is specifically a bug with default body in traits, this doesn't happen in s. I'll check it out, it's probably a very simple fix.
Code change:
<ins> // aux-build:issue-92755.rs // build-pass // Thank you @tmiasko for providing the content of this test! extern crate issue_92755; fn main() { issue_92755::ctx().a.b.f(); } </ins>

Related discussion:
text: EDIT (ehuss) Reproduction: Clone <!-- 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 --
We are seeing this too on rustc 1.60.0-nightly ( 2022-01-10) running on aarch64-apple-darwin
label +I-prioritize
cc This seems to have regressed starting with .
I'm taking a look
I can reproduce and I did find some differences in the access level table. seems to be missing when it's supposed to be Reachable in the good version. I'll investigate further Updates: Actually, the whole Impl seems to be missing. It should be marked as Reachable but is not even there. claim
Marking as , as .
Same on Mac, on x86_64-apple-darwin as well, same toolchain version (rustc 1.60.0-nightly ( 2022-01-10))
As an update for those watching: currently, the best workaround is to use an older nightly. The good news is that a fix PR is open (), with people working on getting it in shape to be merged.
Code change:
PatternKind::Variant { adt_def, substs, variant_index, ref subpatterns } => { let irrefutable = adt_def.variants.iter_enumerated().all(|(i, v)| { i == variant_index || { <del> self.hir.tcx().features().never_type && </del> self.hir.tcx().features().exhaustive_patterns && !v.uninhabited_from(self.hir.tcx(), substs, adt_def.adt_kind()).is_empty() }

Related discussion:
text: This compiles successfully with . It's possible that this regressed when the two features were separated. It's also possible that stabilizing never_type first will make this issue moot.
I'm very surprised that this is still open. can you add the I-nomiated flag please, if you think it's appropriate here? modify labels: T-compiler C-Bug
This only seems to occur with nightly features enabled, so I'm not sure it's supposed to be nominated. I'll mention it in the tracking issue though.
Code change:
} } <ins> /// For rustdoc. pub fn get_partial_res(&self, node_id: NodeId) -> Option<PartialRes> { self.partial_res_map.get(&node_id).copied() } </ins> /// Retrieves the span of the given `DefId` if `DefId` is in the local crate. #[inline] pub fn opt_span(&self, def_id: DefId) -> Option<Span> {

Related discussion:
text: <!-- 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. --Nightly 2022-08-11 worked fine, trying to upgrade from it. : <details<summary<strongBacktrace</strong</summary<p</p</details
, same rustc version
label E-needs-mcve -T-compiler +T-rustdoc
Error: Label needs-mcve can only be set by Rust team members Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
I don't have a MCVE but the same problem on the same nightly version happens with a dependency of . Sounds awfully similar to also involving deps, but that one's definitely fixed.
Pinging since they're the last one who worked on this. Maybe you have an idea?
Somewhat minimal example: Removing the impl avoids the bug.
This happens with beta too:
Fixed in
Code change:
<ins> error[E0582]: binding for associated type `Assoc` references lifetime `'a`, which does not appear in the trait input types --> $DIR/ice-wf-missing-span-in-error-130012.rs:9:28 | LL | trait MyTrait: for<'a> Fun<Assoc = &'a ()> {} |                            ^^^^^^^^^^^^^^ error[E0582]: binding for associated type `Assoc` references lifetime `'a`, which does not appear in the trait input types --> $DIR/ice-wf-missing-span-in-error-130012.rs:9:28 | LL | trait MyTrait: for<'a> Fun<Assoc = &'a ()> {} |                            ^^^^^^^^^^^^^^ | = note: duplicate diagnostic emitted due to `-Z deduplicate-diagnostics=no` error[E0582]: binding for associated type `Assoc` references lifetime `'a`, which does not appear in the trait input types --> $DIR/ice-wf-missing-span-in-error-130012.rs:9:28 | LL | trait MyTrait: for<'a> Fun<Assoc = &'a ()> {} |                            ^^^^^^^^^^^^^^ | = note: duplicate diagnostic emitted due to `-Z deduplicate-diagnostics=no` error[E0582]: binding for associated type `Assoc` references lifetime `'b`, which does not appear in the trait input types --> $DIR/ice-wf-missing-span-in-error-130012.rs:14:21 | LL | impl<F: for<'b> Fun<Assoc = &'b ()>> MyTrait for F {} |                     ^^^^^^^^^^^^^^ error[E0308]: mismatched types --> $DIR/ice-wf-missing-span-in-error-130012.rs:14:50 | LL | impl<F: for<'b> Fun<Assoc = &'b ()>> MyTrait for F {} |                                                  ^ lifetime mismatch | = note: expected reference `&()` found reference `&'b ()` error: aborting due to 5 previous errors Some errors have detailed explanations: E0308, E0582. For more information about an error, try `rustc --explain E0308`. </ins>

Related discussion:
text: : current nightly <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
This did not used to ICE prior to The PR is in nightly-2024-05-12 and Rust 1.80. The diagnostic from nightly-2024-05-11 before that PR is:
Code change:
writeln!(&mut writer, "{}, {}!", "hello", "world").unwrap(); assert_eq!(writer.get_ref().events, [RecordedEvent::Write("hello, world!n".to_string())]); } <ins> #[test] fn bufreader_full_initialize() { struct OneByteReader; impl Read for OneByteReader { fn read(&mut self, buf: &mut [u8]) -> crate::io::Result<usize> { if buf.len() > 0 { buf[0] = 0; Ok(1) } else { Ok(0) } } } let mut reader = BufReader::new(OneByteReader); // Nothing is initialized yet. assert_eq!(reader.initialized(), 0); let buf = reader.fill_buf().unwrap(); // We read one byte... assert_eq!(buf.len(), 1); // But we initialized the whole buffer! assert_eq!(reader.initialized(), reader.capacity()); } </ins>

Related discussion:
text: I tried this code: I expected to see this happen: Instead, this happened: The problem doesn't occur with optimization enabled. It most recently worked on: Also fails on: modify labels: +regression-from-stable-to-stable -regression-untriaged <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Thanks for reporting this! This is an issue with a debug build so it's unlikely to be prioritized high but I'm interested in helping out because this is very goofy. The slow code here is the Iterator impl on slices. I think in the last stable release we switched the implementation of BufReader to eventually use ReadBuf, and the slow code is ReadBuf initializing the remaining uninitialized capacity. It does this by iterating over a slice, and that iteration is the slow bit. What I don't get here is why we need to initialize at all. That doesn't seem right.
WG-prioritization assigning highest priority since this looks a pretty visible runtime perf. regression (). If the assessment should be revised, please feel free to comment. label -I-prioritize +P-critical i-slow
I've tried bisecting with and feeding this command: . Regression seems to be in and confirm <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
:joy: I was so sure this wasn't my fault. More fool me for not bisecting it myself.
(This probably shows an opportunity to add a benchmark to the newly-established "runtime benchmarks" (rather than the compilation-time benchmarks that has classically focused on...)
After sleeping on this, I realized that there's no real reason to expect the worlds-worst-memset code which is the source of the slowdown to be totally optimized out with . And of course it isn't. This is also a substantial regression with optimizations.
Code change:
writeln!(&mut writer, "{}, {}!", "hello", "world").unwrap(); assert_eq!(writer.get_ref().events, [RecordedEvent::Write("hello, world!n".to_string())]); } <ins> #[test] fn bufreader_full_initialize() { struct OneByteReader; impl Read for OneByteReader { fn read(&mut self, buf: &mut [u8]) -> crate::io::Result<usize> { if buf.len() > 0 { buf[0] = 0; Ok(1) } else { Ok(0) } } } let mut reader = BufReader::new(OneByteReader); // Nothing is initialized yet. assert_eq!(reader.initialized(), 0); let buf = reader.fill_buf().unwrap(); // We read one byte... assert_eq!(buf.len(), 1); // But we initialized the whole buffer! assert_eq!(reader.initialized(), reader.capacity()); } </ins>

Related discussion:
text: Here's a version of the original program that's touched up a bit: On 1.63 I see runtime ~0.43 s, and on 1.64 ~4.8 s. So we have a slowdown of around 10x, though I suspect that number could be ratcheted up higher.
claim
Awesome, thanks for the really quick fix!
Code change:
<ins> // Issue #86448: test for cross-crate `doc(hidden)` #![crate_name = "foo"] // aux-build:cross-crate-hidden-impl-parameter.rs extern crate cross_crate_hidden_impl_parameter; pub use ::cross_crate_hidden_impl_parameter::{HiddenType, HiddenTrait}; // OK, not re-exported pub enum MyLibType {} // @!has foo/enum.MyLibType.html '//*[@id="impl-From%3CHiddenType%3E"]' 'impl From<HiddenType> for MyLibType' impl From<HiddenType> for MyLibType { fn from(it: HiddenType) -> MyLibType { match it {} } } pub struct T<T>(T); // @!has foo/enum.MyLibType.html '//*[@id="impl-From%3CT%3CT%3CT%3CT%3CHiddenType%3E%3E%3E%3E%3E"]' 'impl From<T<T<T<T<HiddenType>>>>> for MyLibType' impl From<T<T<T<T<HiddenType>>>>> for MyLibType { fn from(it: T<T<T<T<HiddenType>>>>) -> MyLibType { todo!() } } // @!has foo/enum.MyLibType.html '//*[@id="impl-HiddenTrait"]' 'impl HiddenTrait for MyLibType' impl HiddenTrait for MyLibType {} // @!has foo/struct.T.html '//*[@id="impl-From%3CMyLibType%3E"]' 'impl From<MyLibType> for T<T<T<T<HiddenType>>>>' impl From<MyLibType> for T<T<T<T<HiddenType>>>> { fn from(it: MyLibType) -> T<T<T<T<HiddenType>>>> { match it {} } } </ins>

Related discussion:
text: Last line yields several occurrences of in the generated file. ## Expected behavior No occurrences of anywhere since it was label C-bug T-rustdoc cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I expect the fix is to check for just after
claim
cc I checked for doc(hidden) like this: But it doesn't seem to work, as my test would fail. I also tried using the same way to check for but it also failed. I noticed that the issue involves so I might need to iterate over generic parameters, I cannot find any function that does that in , so can someone point me in the right direction? Thanks :)
You can look at how the pass works:
am I right in understanding this only happens for cross-crate traits, and impls for hidden traits in the same crate are still hidden? In other words, just makes the cross-crate case consistent?
I believe so, yes: the pass was already taking care of such cases for local types. FWIW, the thing that motivated this discussion was noticing a leaking on the docs for , but not on the ones for
Code change:
} } <del> include!(concat!(env!("OUT_DIR"), "/error_codes.rs")); </del> <ins> fn register_all() -> Vec<(&'static str, Option<&'static str>)> { let mut long_codes: Vec<(&'static str, Option<&'static str>)> = Vec::new(); macro_rules! register_diagnostics { ($($ecode:ident: $message:expr,)*) => ( register_diagnostics!{$($ecode:$message,)* ;} ); ($($ecode:ident: $message:expr,)* ; $($code:ident,)*) => ( $( {long_codes.extend([ (stringify!($ecode), Some($message)), ].iter());} )* $( {long_codes.extend([ stringify!($code), ].iter().cloned().map(|s| (s, None)).collect::<Vec<_>>());} )* ) } include!(concat!(env!("OUT_DIR"), "/all_error_codes.rs")); long_codes } </ins>

Related discussion:
text: Steps: Checkout commit Have in . In particular, this implies Run Output (on the second run):
cc
For what it’s worth is just what I happened to get after running today. I mentioned it in case something changes later, it’s a coincidence that that commit happens to be related to downloading LLVM from Rust CI.
I think this is a duplicate of
That issue is closed, and its final comment points to this issue.
I just hit this on the following sequence. Do a fresh clone of Run Select option (b) "compiler: Contribute to the compiler itself" Run The build finished like so:
IMO the proper fix for this is to remove error-index's dependency on rustdoc, either by moving the relevant code out into a library that doesn't use rustc_private, or by duplicating the code altogether. There are other ways to solve this but they'll be more complicated and take longer to compile for no real benefit.
by making it invoke rustdoc-the-binary (through ), rather than using rustdoc-the-library.
you should be able to work around this by adding --stage 2 I think.
Thanks, that worked
I think you're right that the binary will be easier - parsing the markdown requires parsing doctests so that it can generate the "Run" button, and parsing doctests requires all of .
Code change:
let (a, b) = ($a, $b); if a != b { let (a, b) = if a > b {(a, b)} else {(b, a)}; <del> assert!(a - Duration::new(0, 1) <= b); </del> <ins> assert!(a - Duration::new(0, 100) <= b); </ins> } }) }

Related discussion:
text: Windows 8.1 64-bit / MSYS2 / MinGW-w64 cc
Interesting! This is testing the property that the duration between two instants plus the first is the same as the second. Unfortunately this isn't true on Windows due to the +/- one problem on multiple cores. Have to think about what's the best course of action here.
This still fails, btw
Code change:
return Some(LexicalScopeBinding::Item(binding)); } } self.early_resolve_ident_in_lexical_scope( orig_ident, ScopeSet::Late(ns, module, record_used_id),

Related discussion:
text: The following code... the following error and warning: The warning says that is not used but it clearly is, just not properly. This error is normally easier to spot when using the proper casing for constants, but that might not always be the case. Perhaps in this instance, we should look for other items with the exact same name and point out that the user is trying to use a constant as a type. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Every single one of these errors should point at similarly named things of the wrong namespace.
Do you know where in the code this is coming from?
running the following will tell you where the error is being emitted: From there the place you might want to start looking at is , which is a bit hard to follow at the moment (I'm doing a slight clean up of that method at the moment), but should be reasonably straight forward to add another check for this case to that pile :)
claim
Can I take this issue?
Yes feel free to take it, I removed my assignment.
I’m going to be tied up until May, feel free to take this issue:pray:
Hey I'm looking to get to know the Rust codebase better and contribute to the project - would love to take a crack at this issue!
claim
Code change:
assert: (".sidebar-elems > .crate > ul > li > a.current", "lib2") // We now go to the "foobar" function page. assert: (".sidebar-elems > .items > ul > li:nth-child(1)", "Modules") <del> assert: (".sidebar-elems > .items > ul > li:nth-child(2)", "Functions") </del> <ins> assert: (".sidebar-elems > .items > ul > li:nth-child(2)", "Structs") assert: (".sidebar-elems > .items > ul > li:nth-child(3)", "Traits") assert: (".sidebar-elems > .items > ul > li:nth-child(4)", "Functions") assert: (".sidebar-elems > .items > ul > li:nth-child(5)", "Type Definitions") </ins> assert:	("#functions + table td > a", "foobar") click: "#functions + table td > a"

Related discussion:
text: It looks like a CSS rule is being applied incorrectly. It also looks weird if you click through to the type alias's page (). ! !
I'm not really sure, could that be slipped in ?
It turns out it was actually much more recent. The PR causing the regression was , cc searched nightlies: from nightly-2021-05-01 to nightly-2021-06-12 regressed nightly: nightly-2021-06-04 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-apple-darwin Reproduce with: </details
The culprit CSS rule is here: It also caused which was fixed by .
Ah, I have missed this one. Sending a fix.
Assigning priority as in the prioritization working group. label: +P-medium -I-prioritize
The fix should be merged in less than 3 hours. ;)
I know, but we had already agreed on a priority :)
Oh I see. Thanks for taking care of that then! :)
Code change:
} PathResult::Failed { is_error_from_last_segment: true, span, label, suggestion } => { if no_ambiguity { <del> assert!(import.imported_module.get().is_none()); </del> let err = match self.make_path_suggestion( span, import.module_path.clone(),

Related discussion:
text: I tried this code: I expected to see this happen: Compilation error. This shadows one (glob-imported) with another . As far as I know, this should be forbidden. Instead, this happened: this code successfully compiled. : c.c. c.c.
Shadowing a glob import with a specific item is allowed and will unambiguously resolve to the specific one. This is also how the prelude works. The following compiles fine as well: .
To clarify, the problem is not shadowing, but time travel. We shadow identifier which have been already used to resolve another import, so we end up with meaning two things at the same time in the same scope.
This is a change from Rust 1.44, in Rust 1.43 this is an ICE "inconsistent resolution for an import". Possibly a consequence of
I'm not sure this is a bug. When resolving we are looking at all names in scope except for the names introduced by itself. Otherwise we'd have cycles even in trivial cases like where is a name from extern prelude. If you take this detail into consideration, then all paths seem to be resolved correctly.
cc (somewhat related)
I think, the difference with is that doesn't replace one resolution with another. We already have a name in the scope that is resolved to a particular extern crate. In my example, uses name from the scope, and then rebinds this name to another item. I can complicate my example a bit. What this program prints, "111" or "222"? It'd say, it depends on imports resolution order, but looks like it always prints "111".
It'd say, it depends on imports resolution order The intent for the resolution results is to never depend on internal resolution order. (cc , order-dependence can probably happen in practice due to the current not very principled implementation, but hopefully still can be eliminated in backward-compatible-in-practice way by rewriting the main resolution/expansion loop more carefully.) but looks like it always prints "111" That's what I'd expect. resolves to in resolves to (because non-globs shadow globs) first in resolves to (which the only in scope after excluding itself)
I'd still be ok with replacing the former ICE with an error though, since that's a more conservative choice.
Code change:
} PathResult::Failed { is_error_from_last_segment: true, span, label, suggestion } => { if no_ambiguity { <del> assert!(import.imported_module.get().is_none()); </del> let err = match self.make_path_suggestion( span, import.module_path.clone(),

Related discussion:
text: Actually enabling the property "name resolve to the same thing whether some items were excluded during its resolution to avoid cycles or not" may be useful for using something like "inference variables" for unresolved imports and making import resolution more like unification in type inference. That's an idea I had for quite some, but I hadn't realized that merging went against it.
Sigh, the issue already affects three stable releases - from 1.44 to 1.46. I'll try to prioritize it.
Addressed in
Assigning so this isn't lost. See the .
The fix caused some regressions -
The code in the issue produce no errors using Rust 1.67.1. Should we re-open the issue or is it not considered a bug now?
The fix was reverted due to breakage () and the current behavior is considered by design since then.
(Also it's not exactly a time travel - )