jiebi/CodeConvo huggingface dataset:
Change:
let context = &gcc_module.context; let mut compressed = rustc_metadata::METADATA_HEADER.to_vec(); <del> FrameEncoder::new(&mut compressed).write_all(&metadata.raw_data).unwrap(); </del> <ins> FrameEncoder::new(&mut compressed).write_all(&metadata.raw_data()).unwrap(); </ins> let name = exported_symbols::metadata_symbol_name(tcx); let typ = context.new_array_type(None, context.new_type::<u8>(), compressed.len() as i32);

Discussion:
The following code from the manual fails with rustboot .
How embarrassing. Thanks for the report, I'll look into it.
Fix mem op= mem bug in (via not terribly good fix). Closed by .
Change:
return false; } } <ins> if let hir::ExprKind::Call(path, args) = &expr.node { if let ( hir::ExprKind::Path(hir::QPath::TypeRelative(base_ty, path_segment)), 1, ) = (&path.node, args.len()) { // `expr` is a conversion like `u32::from(val)`, do not suggest anything (#63697). if let ( hir::TyKind::Path(hir::QPath::Resolved(None, base_ty_path)), sym::from, ) = (&base_ty.node, path_segment.ident.name) { if let Some(ident) = &base_ty_path.segments.iter().map(|s| s.ident).next() { match ident.name { sym::i128 | sym::i64 | sym::i32 | sym::i16 | sym::i8 | sym::u128 | sym::u64 | sym::u32 | sym::u16 | sym::u8 | sym::isize | sym::usize if base_ty_path.segments.len() == 1 => { return false; } _ => {} } } } } } </ins> let msg = format!("you can convert an `{}` to `{}`", checked_ty, expected_ty); let cast_msg = format!("you can cast an `{} to `{}`", checked_ty, expected_ty);

Discussion:
I updated a dependency and the type of a struct field changed from an to a . I am assigning a value to this struct field. Before, I was calling to convert the to an . With the upgrade this is unnecessary since the field and the value are both . The rust compiler suggests this fix: But it should really suggest removing the and using the directly. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I am using Rust 1.37.0.
cc
Similarly, this code should suggest replacing with .
For the case where we have and an was expected, what should be the correct behavior? I believe simply suggesting is appropriate, if funny looking, because the could_ be coming from outside a macro, and the error be inside of one. Thoughts?
that sounds good to me
claim
Which of these options makes more sense? Check if the new (suggested) conversion is infallible always (doesn't make sense in the 1st case?) only in the 2nd case (if the new conversion is fallible, I presume we fall back to other suggestions and should be suggested, which makes a bit of sense, since it highlights the possible panic?) never (if is detected, always suggest to replace with ) Seems like the user already opted in for panicking if the conversion fails, so conversion was fallible and will stay so:The conversion is infallible but will become fallible if the suggestion is applied:
release-assignment
sorry, didn't see your claim before I pushed my PR :-|
Change:
<ins> #[derive(Debug)] </ins> pub enum EntryPointType { None, MainNamed,

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. --Not minimal, but possibly helpful, 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 --
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-low
This appears to have been caused by
claim
~A potential duplicate~
No that's a completely different error
Sorry I misread the error message, It is probably a duplicate of
Yep, that looks very similar
Change:
<ins> struct Wrapper<'a, T>(&'a T) where T: 'a; impl<'a, T> Drop for Wrapper<'a, T> where T: 'static, //~^ error: `Drop` impl requires `T: 'static` but the struct it is implemented for does not { fn drop(&mut self) {} } fn main() {} </ins>

Discussion:
Looks like it's possible to for a stricter lifetime than the one used in the type: ... which allows to essentially transmute from to , leading to unsoundness: On my machine, it prints:
oops...
Looks like this regressed in 1.56.0.
introduced this
Re-opening to track beta/stable backport.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-critical
(I'm investigating making a more limited version of this PR for backporting to beta/stable.)
we ended up backporting itself to the 1.57 release. So this is now closed.
Change:
<ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. pub mod B; pub mod C; pub use self::C::T; </ins>

Discussion:
This code compiles: However, splitting the code into files causes compilation to fail: I am not sure whether or use is correct; regardless, replacing the latter with the former in produces a similar error:
cc
This appears to work now.
Change:
match self.at(&self.misc(span), self.param_env).sup(impl_ty, self_ty) { Ok(ok) => self.register_infer_ok_obligations(ok), Err(_) => { <del> span_bug!(span, </del> <ins> self.tcx.sess.delay_span_bug(span, &format!( </ins> "instantiate_value_path: (UFCS) {:?} was a subtype of {:?} but now is not?", self_ty, <del> impl_ty); </del> <ins> impl_ty, )); </ins> } } }

Discussion:
I got this pretty weird ICE while in the middle of a refactor. I don't know how to turn this into a minimal example, so here's the offending code that reproduces this error:
What version of the compiler are you using?

I made a struct , and made two blocks for and ( and are unit structs.) Each block has a method with same name but different argument count. I accidentally made those methods private. [Link to the playground][playground] [playground]: I expected to get error about privacy, but with that, the compiler panicked. Backtrace: <details</details
A more minimal repro:
Interesting point: in this code, doesn't have method but the compiler reports that it exists but is private. However, with , the compiler reports error correctly.
CC , .
Change:
# If this file is modified, then llvm will be (optionally) cleaned and then rebuilt. # The actual contents of this file do not matter, but to trigger a change on the # build bots then the contents should be changed so git updates the mtime. <del> 2018-03-06 </del> <ins> 2018-03-10 </ins>

Discussion:
E.g.: (and this results in a 8MB file, etc). Note that this works:
Looking at LLVM IR: It looks like that the padding is troublesome.
So I'm not sure what to do here. This is clearly also an LLVM issue, but with LLVM being supported down to 3.7, fixing just LLVM doesn't seem enough.
If it's indeed an LLVM bug, fixing LLVM and cherry-picking the patch into may be the best we can do. This is often the case with LLVM issues, even with blatant miscompiles (e.g., ).
I tagged this as in a sense that it generates an executable that is suboptimal (i.e. what is the spirit of the tag).
Relevant thread on llvm-dev: (well, not a thread just yet)
Still reproduces on 1.20 and (). Did the patch ever happen?
I have a . It's been accepted, so now it just needs to be merged and then we should be able to cherry-pick it.
This has now been merged in. Should be ready for cherry-picking!
Yay! Thanks If someone wants to drive this to the finish line the backporting process looks like this: Fork rust-lang/llvm. Make a new branch -- base it off the branch. Cherry pick the changes (). Send a PR to rust-lang/llvm (target branch is ).Once that PR is merged, fork rust-lang/rust. Make a new branch -- base it off the master branch. Update the src/llvm submodule to point to the new HEAD of the branch. Send a PR with the updated submodule to rust-lang/rust (target branch is master).Cross your fingers and hope that bors likes the changes :slightlysmilingface: Feel free to cc me on those PRs. I can only r+ the rust-lang/rust PR, though.
thanks for laying out the steps! I always meant to follow up here, but never got around to it (and wasn't sure what the process was on the rust/llvm end). I've followed the first steps: hopefully we can soon get this fix in for good! :)
Change:
use std::process::Command; #[cfg(not(feature = "bootstrap-self-test"))] <ins> use crate::builder::Builder; #[cfg(not(feature = "bootstrap-self-test"))] use crate::core::build_steps::tool; #[cfg(not(feature = "bootstrap-self-test"))] </ins> use std::collections::HashSet; use crate::builder::Kind;

Discussion:
Spawned off of I'm not 100% sure what would be involved in such a check here, but it seems like a good thing to investigate, because the nature of the resulting bootstrap failures is super frustrating. (I'll admit, I don't know if the right thing would be to hard error out of all uses of download-ci-llvm for potentially-incompatible libstdc++, or only to hard error out for defaulting uses... but a warning seems warranted in any such cases.
I guess the problem here is that we're compiling the locally and linking that against the downloaded toolchain. A check like suggested here makes sense to me in the meantime, but I suppose long-term the "right" fix here is to get rid of any C++ code we need to separately compile by upstreaming C bindings into LLVM proper, and then we can just call those on the Rust side without any ABI issues. (FWIW, I was initially confused since we explicitly statically link in the stdcpp in the distributed I guess maybe we could also fix this by skipping linking to a local stdcpp while compiling the Rust wrapper code? Not sure if that works out.)
This is the particular line which leads to failure with download-ci-llvm when there is an ABI mismatch. In my experiment removing it resulted in linking errors on rustcdriver. I agree, this solves the problem completely without applying hacks (in my opinion, there is no simple or clean way of comparing ABI or libstd versions) on bootstrap. Maybe, for now, we should just print a warning when downloading ci llvm?
You mean always print a warning? I don't think that's a good idea, it's noisy and we generally expect that people are happy using download CI LLVM. I don't think a warning is helpful here if we can't scope it down to where it matters (in which case it can probably be an error).
Not always, only once while downloading it.
I think that falls in the same "not particularly helpful" case. Most users will miss the message, and even if they don't it's not clear how they should respond. I at least don't know how to check whether my machine has everything setup right. If we could check then we could limit the warning, in which case I'm broadly in favor of making it perhaps even a hard error.
Change:
<del> Subproject commit fccb2398248802a268fcda544ff3945247ef2119 </del> <ins> Subproject commit d9ae0285169e52050416fb3618f05b5fdf582b6b </ins>

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and nominating for compiler team prioritization.
triage: P-medium. Removing I-nominated.
Change:
} }, _ => { <del> if enum_path.segments.len() == 1 { </del> <ins> if !enum_path.global && enum_path.segments.len() == 1 { </ins> // it could still be either an enum // or an identifier pattern, resolve // will sort it out:

Discussion:
That is, it's not obeying the global part of the path and instead just creating a variable with the name .
cc
Oh, and moving the out of to makes compile without warning, so I guess the global boolean is just being ignored somewhere.
Change:
/// This conversion does not allocate on the heap and happens in place. /// /// This is also available via [`From`]. <del> #[unstable(feature = "box_into_pin", issue = "62370")] </del> <ins> /// /// # Notes /// /// It's not recommended that crates add an impl like `From<Box<T>> for Pin<T>`, /// as it'll introduce an ambiguity when calling `Pin::from`. /// A demonstration of such a poor impl is shown below. /// /// ```compile_fail /// # use std::pin::Pin; /// struct Foo; // A type defined in this crate. /// impl From<Box<()>> for Pin<Foo> { ///     fn from(_: Box<()>) -> Pin<Foo> { ///         Pin::new(Foo) ///     } /// } /// /// let foo = Box::new(()); /// let bar = Pin::from(foo); /// ``` #[stable(feature = "box_into_pin", since = "1.63.0")] </ins> #[rustc_const_unstable(feature = "const_box", issue = "92521")] pub const fn into_pin(boxed: Self) -> Pin<Self> where A: 'static, { // It's not possible to move or replace the insides of a `Pin<Box<T>>` <del> // when `T: !Unpin`,  so it's safe to pin it directly without any </del> <ins> // when `T: !Unpin`, so it's safe to pin it directly without any </ins> // additional requirements. unsafe { Pin::new_unchecked(boxed) } }

Discussion:
This is a tracking issue for implemented in
There are currently 2 unambiguous stable ways to convert a into a without additional inference constraints Also, at the moment works because there is only one trait implementation that can satisfy that call, but because and are it's possible for an external library to add an additional implementation that makes that ambiguous (). In a lot of cases where you need to convert into a you're likely to have inference available to guide the call as well, but not always.
Well there's also [] right? []:
Mmh but that takes a and wraps it into . I think with that context makes a lot of sense.
Shall we stabilize ? merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [x] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
It seems like this is something that should be mentioned in the docs of , specifically as something that differentiates it from .
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. This will be merged soon.
Change:
<ins> error[E0283]: type annotations needed --> $DIR/argument-with-unnecessary-method-call.rs:8:13 | LL |     qux(Bar.into()); |     ---     ^^^^ |     | |     required by a bound introduced by this call | = note: cannot satisfy `_: From<Bar>` note: required by a bound in `qux` --> $DIR/argument-with-unnecessary-method-call.rs:6:16 | LL | fn qux(_: impl From<Bar>) {} |                ^^^^^^^^^ required by this bound in `qux` help: try using a fully qualified path to specify the expected types | LL |     qux(<Bar as Into<T>>::into(Bar)); |         +++++++++++++++++++++++   ~ help: consider removing this method call, as the receiver has type `Bar` and `Bar: From<Bar>` trivially holds | LL -     qux(Bar.into()); LL +     qux(Bar); | error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0283`. </ins>

Discussion:
When calling in a fn that expects we currently emit: We should check whether and suggest the removal of the call. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
feel free to reach out either on this ticket or on a PR, but be warned that this has the potential to be quite involved. It is a great introduction to how some parts of fit together though.
I've been looking into this for a while now, and my idea was to: Check if there a .into() call, check if the type of self was T and finally check if the argument of the function was Into<T. However I cannot figure how to get the type of Self. As far as my understanding goes, rustc hasn't yet inferred the type.
You can query the in-progress type table with the for the expression. You're gonna have an with a . From the first argument in that variant you can take the first element and get the expression for in . Then you can use the for that expression to do I do not know if we will have populated 's type by then, but if we have, then that will give you the type of . Then, if you're in an you can use to see if the inferred type for can be coerced to in the original example. I know this is a bit vague, but for this is inherently exploratory work :)
Hi, are you still working on this issue
No, feel free to claim it if you want
release-assignment
Change:
visitor.visit_body(&body); let parent = self.tcx.hir().get_parent_node(seg1.hir_id); <del> if let Some(Node::Expr(call_expr)) = self.tcx.hir().find(parent) && let Some(expr) = visitor.result { let self_ty = self.node_ty(expr.hir_id); </del> <ins> if let Some(Node::Expr(call_expr)) = self.tcx.hir().find(parent) && let Some(expr) = visitor.result && let Some(self_ty) = self.node_ty_opt(expr.hir_id) { </ins> let probe = self.lookup_probe( seg2.ident, self_ty,

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. --This is new, introduced between (older) and (newer) src/tools/miri/tests/pass- <!-- 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
prioritize
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
); } else if matches!( meta_item.name_or_empty(), <del> sym::C | sym::simd | sym::transparent </del> <ins> sym::Rust | sym::C | sym::simd | sym::transparent </ins> ) || int_type_of_word(meta_item.name_or_empty()).is_some() { recognised = true;

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: unrecognized representation hint', 'error: internal compiler error: unrecognized representation hint' 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-08-26
Change:
except tarfile.CompressionError: return False <del> def get(base, url, path, checksums, verbose=False, do_verify=True, help_on_error=None): </del> <ins> def get(base, url, path, checksums, verbose=False, do_verify=True): </ins> with tempfile.NamedTemporaryFile(delete=False) as temp_file: temp_path = temp_file.name

Discussion:
I accidentally missed this when porting it to rustbuild: It would be nice to add it back. Mentoring instructions: Add a new parameter to and pass it down from : This code moved around in so you may want to base your changes off that PR until it lands. label +E-easy +E-mentor +A-rustbuild <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Please also remove the dead code from at the same time:
claim
Change:
<ins> - // MIR for `fn0` before GVN + // MIR for `fn0` after GVN fn fn0() -> () { let mut _0: (); let mut _1: usize; let mut _2: [u128; 6]; let mut _3: ([u128; 6],); let mut _4: ([u128; 6],); let mut _5: (); bb0: { _1 = const 1_usize; _2 = [const 42_u128; 6]; -         _2[_1] = const 1_u128; +         _2[1 of 2] = const 1_u128; _3 = (_2,); _4 = _3; -         _5 = fn1(move (_3.0: [u128; 6]), _4) -> [return: bb1, unwind unreachable]; +         _5 = fn1((_3.0: [u128; 6]), _3) -> [return: bb1, unwind unreachable]; } bb1: { return; } } </ins>

Discussion:
Right: Wrong: The first argument to is partially moved. GVN causes the second argument to use the partially moved value:
I can't provoke the miscompilation on beta using this example (just had to replace with to make it build), so I don't think there's any need to rush to fix this. (Some part of GVN is used in the beta that's about to become stable, but it looks like it doesn't have this bug in it)
Cc
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
} function runChecks(testFile, loaded, index) { <del> var loadedFile = loadContent( readFile(testFile) + 'exports.QUERY = QUERY;exports.EXPECTED = EXPECTED;'); </del> <ins> var testFileContent = readFile(testFile) + 'exports.QUERY = QUERY;exports.EXPECTED = EXPECTED;'; if (testFileContent.indexOf("FILTER_CRATE") !== -1) { testFileContent += "exports.FILTER_CRATE = FILTER_CRATE;"; } var loadedFile = loadContent(testFileContent); </ins> const expected = loadedFile.EXPECTED; const query = loadedFile.QUERY;

Discussion:
I loaded the std doc at Firefox 77.0.1, then I typed fast for the word "true" (or click this link: ). I expected to see this happen: The search result appears and includes the "true" keyword link. Instead, this happened: No search result was shown. Also in the Firefox console, this was printed after typing the word "true": Version of std docs: 1.46.0-nightly ( 2020-06-21) cc in case you interest.
The type error happened along this line:
It looks like it fails when you have a crate filter selected. Almost certainly caused by (cc
yeah, that's right. I forgot about that detail.
should fix this.
Change:
<ins> error: generic `Self` types are currently not permitted in anonymous constants --> $DIR/ice-68875.rs:4:20 | LL |     data: &'a [u8; Self::SIZE], |                    ^^^^ error: aborting due to previous error </ins>

Discussion:
Attempting to build this code generates an ICE (): The error message, on my machine: Looks like it's related to , but the construction that triggers it is different enough that it seems worth posting.
Source: <details<summaryStack trace</summary<p</p</detailsWith regression in nightly-2019-07-31 <details<summaryBisect output</summary<p</p</detailsdddb7fca09d Auto merge of - Xanewok:update-rls, r=Xanewok Auto merge of - alexcrichton:stabilize-pipelined-compilation, r=oli-obk Auto merge of - Centril:rollup-onohtqt, r=Centril
Triage: This is no longer ICE even with the feature flag: