jiebi/CodeConvo huggingface dataset:
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. //! Unordered containers, implemented as hash-tables pub use self::map::HashMap; pub use self::map::Entries; pub use self::map::MutEntries; pub use self::map::MoveEntries; pub use self::map::Keys; pub use self::map::Values; pub use self::map::INITIAL_CAPACITY; pub use self::set::HashSet; pub use self::set::SetItems; pub use self::set::SetMoveItems; pub use self::set::SetAlgebraItems; mod bench; mod map; mod set; mod table; </ins>

Discussion:
The recent attempts to improve hashmap seem to have exposed a bug in regionck where it fails to link the lifetimes of ref bindings in some situations. A mostly minimized test case is here: This test fails to compile but (I believe) should succeed. The problem is that the lifetime of the binding inside the callback from is not "linked" (in regionck terminology) to the lifetime , and hence region inference infers a lifetime for that is too small. It was not immediately obvious what the best way is to fix this -- the code around handling ref bindings seems a bit ... off in regionck, so I need to think about it some. Perturbing the code in various ways can workaround the issue, which is bad for making minimized test cases but good for landing the hasmap patch in the meantime!
I've run into (I think) another manifestation of this issue that forces the destructuring of a reference to a tuple from the arguments to the closure body: This works, but this does not
I think this is the original problem, updated to current syntax: error: Actually, maybe this should be using something other than Box... ugh old closures.
If you use a boxed closure, remember to box it: This runs on modern rustc.
Ah duh. Thanks!
Change:
/// Determines whether the type `ty` is known to meet `bound` and /// returns true if so. Returns false if `ty` either does not meet <del> /// `bound` or is not known to meet bound. </del> <ins> /// `bound` or is not known to meet bound (note that this is /// conservative towards *no impl*, which is the opposite of the /// `evaluate` methods). </ins> pub fn type_known_to_meet_bound_modulo_regions<'tcx>( infcx: &InferCtxt<'tcx>, param_env: ty::ParamEnv<'tcx>,

Discussion:
https://crater- This seems like a potential recurrence of , which was fixed in but lacked a test case.
searched nightlies: from nightly-2024-02-01 to nightly-2024-02-29 regressed nightly: nightly-2024-02-20 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.8</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsRegressed in -- cc
WG-prioritization assigning priority (). label -I-prioritize +P-high
can revert the change from which caused this 2 weeks before this hits stable. We dshould really get a minimization of this issue though :/
(the cause should be this commit )
Interestingly, this builds on nightly. It seems to me that has fixed, or hid, the ICE .
Probably hidden; that's why we need an MCVE. If it has to do w/ a field not in a struct tail, a simple reordering of fields may trigger this bug again.
I'm not sure how small we can make it, but I've reduced this to a more reasonable size. I've ran out of steam on this if someone wants to help it cross the finish line if needed. It's still very convoluted, and more layers could be removed. It's quite fiddly though, removing a bound here or there makes the ICE disappear like a frightened turtle. The ICE is still present on nightly, but I lost track of the actual source while reducing : it used to happen in the collector but now a bit later. I hope it's fine, it's still in codegen and bisects to as well. <details<summaryThis is not a place of honor</summary</details
Reopening to track beta backport.
Backported in .
Change:
fn bar(_: fn(Foo<for<'b> fn(Foo<fn(&'b ())>::Assoc)>::Assoc)) {} //~^ ERROR higher-ranked subtype error <ins> //~| ERROR higher-ranked subtype error </ins> fn main() {}

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:
<ins> // Don't ICE when trying to annotate signature and we see `&()` fn f<'a, T>(_: &'static &'a (), x: &'a T) -> &'static T { x } trait W<'a> { fn g<T>(self, x: &'a T) -> &'static T; } // Frankly this error message is impossible to parse, but :shrug:. impl<'a> W<'a> for &'static () { fn g<T>(self, x: &'a T) -> &'static T { f(&self, x) //~^ ERROR borrowed data escapes outside of method //~| ERROR `self` does not live long enough } } fn main() {} </ins>

Discussion:
I'll even accept that this is probably UB if I somehow make it work but crashing on is probably not the way. Replacing some with , or with a second lifetime parameter correctly rejects the code. : <details<summary<strongBacktrace</strong</summary<p</p</details
Regression in nightly-2022-06-08 fetching (via remote github) commits from max(, 2022-06-05) to ending github query because we found starting sha: getcommitsbetween returning commits, len: 7 commit[0] 2022-06-06: Auto merge of - flip1995:clippyup, r=Manishearth commit[1] 2022-06-06: Auto merge of - matthiaskrgr:rollup-ajyvjd3, r=matthiaskrgr commit[2] 2022-06-07: Auto merge of - RalfJung:miri, r=RalfJung commit[3] 2022-06-07: Auto merge of - jackh726:remove-borrowck-mode, r=nikomatsakis commit[4] 2022-06-07: Auto merge of - scottmcm:add-coldcc, r=nagisa,lcnr commit[5] 2022-06-07: Auto merge of - Dylan-DPC:rollup-ya51k1k, r=Dylan-DPC commit[6] 2022-06-07: Auto merge of - Dylan-DPC:rollup-0ae3pwp, r=Dylan-DPC
Likely .
Change:
<ins> // Copyright 2017 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. #![crate_type="rlib"] #[derive(Debug, PartialEq)] pub struct RemoteC(pub u32); #[derive(Debug, PartialEq)] pub struct RemoteG<T>(pub T); </ins>

Discussion:
Not on 1.15. cc
Fun note: another bug fixed on my shimmir branch. Not that I really want to merge it to 1.16/1.17.
Minified: I think we should just have the first commit of shimmir to fix this.
triage: P-high
Change:
help: the bound will not be checked when the type alias is used, and should be removed | LL | type WVec<'b, T> = (&'b u32, Vec<T>); <del> |           --  -- </del> <ins> |               -- </ins> warning: where clauses are not enforced in type aliases --> $DIR/type-alias-bounds.rs:16:25

Discussion:
Hi, i have made some changes for a crate to support a generic type that implements from , but suddenly the code can't compile because it runs out of memory with 6, 8, 10 GB. This is the code i'm trying to compile: if changed the type for or it then compiles and runs fine. Source: It fails to compile on x86_64-unknown-linux-gnu with , . I'm attaching the Heaptrack files for further analysis.
It seems a problem with utilized in the , unfortunately memory report is strange, the execution time tracked is wrong besides the graph shows up the memory grow. I'm thinking ways to better troubleshoot, but the side effects of the issue is hard.
It'd be helpful to try and simplify the code, ideally to something that doesn't have dependencies (beyond std or so), or at least as few dependencies as possible. As a start putting up a github repository with a and as simple a crate as possible would be helpful for reproducing on our side (i.e., extracting the file you've linked from that crate -- or, if the crate is really necessary, then indicating as such). The heaptrack profile looks pretty useless unfortunately -- rustc on linux is shipped with jemalloc as the allocator which likely makes heaptrack tracking not really work too well.
Thank you, sorry for the late response (working) but i get it working on playground. I'm now trying to minimize them to focus on the issue.
Got it down to 18 lines. Still produces the same error. I have not tested if this goes out-of-memory. But receiving a would signal that. EDIT: After taking some more time, I got rid of Tokio and reduced it to 6 lines: Additionally, I advise to rename this issue to something like to make it very clear and concise.
One liner: . Strangely, this no longer crashes if you remove any of , , , or .

There's nothing special about Send or Sync, this also crashes: Even weirder, this does not crash: (I didn't come up with the one-liner, that was
I stopped rustc (SIGSTOP) and got a backtrace with gdb, it looks like it's trying to generate infinite errors: <details<summarybacktrace</summary</details
It looks like this is a problem with the error reporter itself: it's affected by the length of the name (!!) OOM: No OOM:
I figured out the issue has to do with how the error printer places the annotations, adding a newline after the trait names and before the plus solves the issue.
Probably caused by some code in here:
Change:
<ins> <span class="kw">pub</span> <span class="kw">fn</span> <span class="ident">foo</span>() { <span class="macro">println</span><span class="macro">!</span>(<span class="string">&quot;foo&quot;</span>); } </ins>

Discussion:
I tried to document and publish my Windows crate to github pages. Things went pretty smooth until I opened the source code view. As you can see below, a newline is appended to each line doc comment, also no line number for each line: ! Here the render page on gh-pages: Beware that it has no version control for the generated doc. But the link here may work for a limited time before github purge the cache: Also here the the CI script I used: The same code published on is normal: : x86_64-pc-windows-msvc rustc 1.48.0-nightly ( 2020-09-04) modify labels: T-rustdoc
Could be related to normalization depending on the git checkout settings of the runner.
I set before , maybe this is my misconfigure somehow.
Try adding and possibly to make those files end with the right character.
Thanks Andy, I tried as you told but still the issue remains.
Oh, I meant for the source files, you might need to reconfigure git before checking out the source (and that's likely just a workaround, this seems likely to be a bug in rustdoc's handling of in source files).
Thank you, problem is solved in . I am pretty sure this issue is a duplicate of another, but I cannot find it. You could close this issue if you see fit.
(keywords cause I keep failing to search for this: dos line endings)
This is a recent regression, it was introduced sometime between and . I suspect is related, cc
The issue is that is being marked as a doc-comment:
I guess this means is being marked as a ? I don't see why it would.
My test was wrong.
This is not actually correct - it was a blank line in the original source code. The issue is that rustdoc used to strip in newlines, but no longer does. Here's 1.47: and 1.48:
Change:
// Create the module and add all methods. match ty.node { TyPath(ref path, _, _) if path.segments.len() == 1 => { <ins> // FIXME(18446) we should distinguish between the name of // a trait and the name of an impl of that trait. </ins> let mod_name = path.segments.last().unwrap().identifier.name; let parent_opt = parent.module().children.borrow()

Discussion:
This code: generates this error: I couldn't find any existing issue on this, but this is expected to work, right?
cc
Was this in an RFC?
DST was pre-RFC (the design anyway), so no, it was not.
It as a good question whether this is supposed to work or not. Since traits are types now, just unsized, I would say "yes". But since an impl for a trait is no different to just providing default methods, perhaps we want to avoid that overlap. Shouldn't be hard to fix if we all agree on "yes", but cc to check he agrees.
As I understand it, an for a trait would be quite different than providing default methods: Even when a trait object is formed, there's no dynamic dispatch (vtable entries) for these methods. The methods cannot be overridden in an . The methods may also exist on the trait, in which case (according to our dispatch rules) the inherent versions would take precedence. I think the closer correspondence is to creating an extension trait with a blanket -- and given that inherent s are in some sense supposed to be equivalent to "anonymous", always-in-scope extension traits, I think that makes sense. My guess is that this was an intended, but implicit part of the DST proposal, but can speak more directly to that.
These subtle differences make me want it less. But the blanket impl-like use case seems legitimate. I agree with the intended but implicit assessment - I vaguely remember this coming up as a use case at some point
I've always assumed this would work but I'm curious was there a specific point in the libraries that required it?
IIRC this came out of playing around with the method definitions, which are currently all provided by extension traits. Not a huge deal if we can't do this for 1.0.
I started looking at this, but the hard bits seem to be some adjustment to method selection, so I'll wait on landing before doing this
I think there is some serious utility in providing this, especially for things like Any. I will try to dig up some other use-cases. Note that since is currently marked adding this later would mean deprecations etc.
Change:
let (span, e) = self.interpolated_or_expr_span(e)?; (lo.to(span), ExprKind::Box(e)) } <del> _ => return self.parse_dot_or_call_expr(Some(attrs)) </del> <ins> token::Ident(..) if self.token.is_ident_named("not") => { // `not` is just an ordinary identifier in Rust-the-language, // but as `rustc`-the-compiler, we can issue clever diagnostics // for confused users who really want to say `!` let token_cannot_continue_expr = |t: &token::Token| match *t { // These tokens can start an expression after `!`, but // can't continue an expression after an ident token::Ident(ident, is_raw) => token::ident_can_begin_expr(ident, is_raw), token::Literal(..) | token::Pound => true, token::Interpolated(ref nt) => match nt.0 { token::NtIdent(..) | token::NtExpr(..) | token::NtBlock(..) | token::NtPath(..) => true, _ => false, }, _ => false }; let cannot_continue_expr = self.look_ahead(1, token_cannot_continue_expr); if cannot_continue_expr { self.bump(); // Emit the error ... let mut err = self.diagnostic() .struct_span_err(self.span, &format!("unexpected {} after identifier", self.this_token_descr())); // span the `not` plus trailing whitespace to avoid // trailing whitespace after the `!` in our suggestion let to_replace = self.sess.codemap() .span_until_non_whitespace(lo.to(self.span)); err.span_suggestion_short(to_replace, "use `!` to perform logical negation", "!".to_owned()); err.emit(); // —and recover! (just as if we were in the block // for the `token::Not` arm) let e = self.parse_prefix_expr(None); let (span, e) = self.interpolated_or_expr_span(e)?; (lo.to(span), self.mk_unary(UnOp::Not, e)) } else { return self.parse_dot_or_call_expr(Some(attrs)); } } _ => { return self.parse_dot_or_call_expr(Some(attrs)); } </ins> }; return Ok(self.mk_expr(lo.to(hi), ex, attrs)); }

Discussion:
this code currently emmits Could we detect explicitly if there are 2 unchained (via && or ) "variables" after an "if" and if the first one is "not" and explicitly suggest using "!" instead of "not" instead? meta: `
Change:
}; e_flags } <del> Architecture::Riscv64 if sess.target.options.features.contains("+d") => { // copied from `riscv64-linux-gnu-gcc foo.c -c`, note though // that the `+d` target feature represents whether the double // float abi is enabled. let e_flags = elf::EF_RISCV_RVC | elf::EF_RISCV_FLOAT_ABI_DOUBLE; </del> <ins> Architecture::Riscv32 | Architecture::Riscv64 => { // Source: https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/079772828bd10933d34121117a222b4cc0ee2200/riscv-elf.adoc let mut e_flags: u32 = 0x0; let features = &sess.target.options.features; // Check if compressed is enabled if features.contains("+c") { e_flags |= elf::EF_RISCV_RVC; } // Select the appropriate floating-point ABI if features.contains("+d") { e_flags |= elf::EF_RISCV_FLOAT_ABI_DOUBLE; } else if features.contains("+f") { e_flags |= elf::EF_RISCV_FLOAT_ABI_SINGLE; } else { e_flags |= elf::EF_RISCV_FLOAT_ABI_SOFT; } </ins> e_flags } _ => 0,

Discussion:
I tried this code: I expected to see this happen: Successful compilation (because this would succeed for the target ) Instead, this happened: <!-- 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. --: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
The relevant code is It should probably be applied to riscv32 too
Doesn't seem like anyone else has picked this up yet, if it's as simple a fix as it seems I would be happy to make the PR.
claim
The mismatch still occurs if extra features are specified by (e.g., ).
Sorry about the delayed response. I just tested it, but I'm not seeing the error. Could you test again as well? I was running the following command: Here is the version I'm on:
Hm, I actually encountered the issue in a more complicated setup () with bare-metal targets and assumed from the symptom that it was caused by a similar underlying problem. I'll look into it again and open a separate issue after getting a better idea.
Change:
] [[package]] <ins> name = "annotate-snippets" version = "0.6.1" source = "registry+https://github.com/rust-lang/crates.io-index" [[package]] </ins> name = "ansi_term" version = "0.11.0" source = "registry+https://github.com/rust-lang/crates.io-index"

Discussion:
Part of To support lines in the first column of UI test output, we have to make use of the flag and update the library. Relevant : The relevant PR in the annotate-snippet library and a new version needs to be released. Once that's done, we have to pass as a second argument to . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
modify labels: A-diagnostics E-help-wanted
claim
Change:
<ins> // build-pass trait Foo {} struct Bar { bytes: &'static [u8], func: fn(&Box<dyn Foo>), } fn example(_: &Box<dyn Foo>) {} const BARS: &[Bar] = &[ Bar { bytes: "0".as_bytes(), func: example, }, Bar { bytes: "0".as_bytes(), func: example, }, ]; fn main() { let x = todo!(); for bar in BARS { (bar.func)(&x); } } </ins>

Discussion:
Hi! I tried to compile my code and got a compiler crash. , stable, problem is present: , beta, problem still present: , nightly, problem still present: <details<summary<strongBacktrace</strong</summary<p</p</details
Seems to be a duplicate of according to the error message itself, but I can't see a const generic expression anywhere. Maybe in the serialport crate. I try to minimize this one.
MCVE:
It seems to be const related because of . If I replace it with this won't panic anymore and is const Regression in nightly-2019-11-29 between ... stable versions: 1.40.0 and 1.41.0 So, this one is different to the linked issue, therefore let's ping it to the people modify labels: regression-from-stable-to-stable
Is this blocking an update of the compiler on existing code or is it just experimentation?
This is just something I ran into yesterday while coding. With finding that replacing with , I can continue with my code. :) Does that answer your question? I don't totally understand it. :(
Assigning priority as discussed as part of the and removing . thanks for the feedback, don't worry, we simply wanted to clarify if the suggested workaround allows you to move on (which you confirmed) or if the issue was blocking. label -I-prioritize +P-medium
I also had this issue happen to me () and I was able to reproduce it with this: I think it's worth noting that the error goes away if we either: we remove the field from (or just remove the from the function signature and replace the with just ); we substitute both calls to in second 's field initialization with a literal (e.g. for example);
This is no longer ICE with the latest nightly, I think is the fix. Marking as .
Hi, I've made a PR that adds a test for this, pretty much copy/pastes 's MCVE
Change:
// This is more complicated than just checking type equality, as arguments could be coerced // This version writes those types back so further type checking uses the narrowed types let demand_compatible = |idx, final_arg_types: &mut Vec<Option<(Ty<'tcx>, Ty<'tcx>)>>| { <del> // Do not check argument compatibility if the number of args do not match if arg_count_error.is_some() { return; } </del> let formal_input_ty: Ty<'tcx> = formal_input_tys[idx]; let expected_input_ty: Ty<'tcx> = expected_input_tys[idx]; let provided_arg = &provided_args[idx];

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. --code from <!-- 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 --
searched toolchains through Regression in probably cc
I can look into this claim