jiebi/CodeConvo huggingface dataset:
Code change:
&self, obligation: &PredicateObligation<'tcx>, err: &mut DiagnosticBuilder<'_>, <del> trait_ref: &ty::Binder<'tcx, ty::TraitRef<'tcx>>, </del> <ins> poly_trait_ref: &ty::Binder<'tcx, ty::TraitRef<'tcx>>, </ins> has_custom_message: bool, ) -> bool { let span = obligation.cause.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. --When creating this I found that it did not error if the function was not called and it also seemed to require it to be a function not just an argument of type T or (from what I tested) a different impl Trait although it could be any Fn* trait <!-- 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. --: This appears to only happen on nightly while stable and beta generate useful error reports <!-- 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 --
label regression-from-stable-to-nightly
does not ICE but errors correctly while does ICE
glacier ""
searched nightlies: from nightly-2021-09-17 to nightly-2021-09-18 regressed nightly: nightly-2021-09-18 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: </detailsThat's , so cc
I've got this. claim Interestingly, this is precisely the kind of thing that is hopefully going to help harden against: "hidden" s when calling and such
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
Code change:
/// assert_eq!(err.kind(), ErrorKind::WriteZero); /// assert_eq!(recovered_writer.buffer(), b"t be actually written"); /// ``` <del> #[unstable(feature = "io_into_inner_error_parts", issue = "79704")] </del> <ins> #[stable(feature = "io_into_inner_error_parts", since = "1.55.0")] </ins> pub fn into_parts(self) -> (Error, W) { (self.1, self.0) }

Related discussion:
text: <!-- Thank you for creating a tracking issue! Tracking issues are for tracking a feature from implementation to stabilisation. Make sure to include the relevant RFC for the feature if it has one. Otherwise provide a short summary of the feature and link any relevant PRs or issues, and remove any sections that are not relevant to the feature. Remember to add team labels to the tracking issue. For a language team feature, this would e.g., be . Such a feature should also be labeled with e.g., . This label is used to associate issues (e.g., bugs and design questions) to the feature. --This is a tracking issue for and . The feature gate for the issue is . Tracking issues are used to record the overall progress of implementation. They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions. A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature. Instead, open a dedicated issue for the specific matter and add the relevant feature gate label. <!-- Include each step required to complete the feature. Typically this is a PR implementing a feature, followed by a PR that stabilises the feature. However for larger features an implementation could be broken up into multiple PRs. --- [x] Implement these methods - see [x] Adjust documentation [x] Stabilization PR ([see instructions on rustc-dev-guide][stabilization-guide]) [stabilization-guide]: https://rustc-dev- [doc-guide]: https://rustc-dev- <!-- Include any open questions that need to be answered before the feature can be stabilised. --These new methods are being introduced as an unstable feature to give time to validate their names, types, and documentation, before stabilisation. Implementation (with docs) is in , currently in review/rework.
fcp merge Check out recap of this API in
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!
Code change:
/// assert_eq!(err.kind(), ErrorKind::WriteZero); /// assert_eq!(recovered_writer.buffer(), b"t be actually written"); /// ``` <del> #[unstable(feature = "io_into_inner_error_parts", issue = "79704")] </del> <ins> #[stable(feature = "io_into_inner_error_parts", since = "1.55.0")] </ins> pub fn into_parts(self) -> (Error, W) { (self.1, self.0) }

Related discussion:
text: See for info about what commands tagged team members can give me.
: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. The RFC will be merged soon.
Code change:
StorageDead(_4);                 // scope 1 at $DIR/simple.rs:6:18: 6:19 StorageDead(_6);                 // scope 1 at $DIR/simple.rs:6:19: 6:20 StorageDead(_3);                 // scope 1 at $DIR/simple.rs:6:19: 6:20 <del> -         _0 = _2;                         // scope 1 at $DIR/simple.rs:7:5: 7:8 -         StorageDead(_2);                 // scope 0 at $DIR/simple.rs:8:1: 8:2 +         nop;                             // scope 1 at $DIR/simple.rs:7:5: 7:8 +         nop;                             // scope 0 at $DIR/simple.rs:8:1: 8:2 </del> <ins> _0 = _2;                         // scope 1 at $DIR/simple.rs:7:5: 7:8 StorageDead(_2);                 // scope 0 at $DIR/simple.rs:8:1: 8:2 </ins> return;                          // scope 0 at $DIR/simple.rs:8:2: 8:2 } }

Related discussion:
text: This little matrix processing code shows miscompilation if compiled with: But it compiles correctly with: With:
Hmm, on first glance the replacement it performs looks correct: It replaces local () with the return place . Previously the return place was only used in the block by a copy statement, so this transformation should be correct. Maybe this part of the diff causes a problem? We're using our return place as the return destination for the inner call. It's possible that there's an undocumented (and maybe unintended) assumption that the return place is not reused like this, either in other MIR optimizations or in codegen. Haven't looked too deeply yet though.
Ah, there's this bad call in LLVM IR: It passes a reference to as both the return pointer, and the second (immutable) argument.
we have this corresponding MIR, where we already incorrectly pass a reference to as an argument, while also assigning the call result to it: The destination propagation pass already has code that prevents merging a call destination with one of the arguments, but here we pass a reference instead. Curiously, the was produced by merging with , which is not really something the pass should be doing since a reference is taken to , and we avoid touching any local that has its address taken.
The propagation is disabled only if both locals have their address taken. Changing that to be more conservative does fix this issue. Minimized:
Oof, this should have been an , not an
Thanks
Opened with a fix
Code change:
<ins> #[derive(Debug)] struct Foo { #[cfg(all())] field: fn(($),), //~ ERROR expected pattern, found `$` //~^ ERROR expected pattern, found `$` } fn main() {} </ins>

Related discussion:
text: 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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Regression in nightly-2021-04-12 finding bors merge commits found 9 bors merge commits in the specified range commit[0] 2021-04-10: Auto merge of - Aaron1011:new-preexp-tests, r=petrochenkov commit[1] 2021-04-10: Auto merge of - Aaron1011:derive-invoc-order, r=petrochenkov commit[2] 2021-04-11: Auto merge of - RalfJung:liballoc-miri, r=Manishearth commit[3] 2021-04-11: Auto merge of - nagisa:nixos-patching-fix, r=Mark-Simulacrum commit[4] 2021-04-11: Auto merge of - JohnTitor:issue-, r=estebank commit[5] 2021-04-11: Auto merge of - Aaron1011:feature/final-preexp-tts, r=petrochenkov commit[6] 2021-04-11: Auto merge of - LingMan:patch-1, r=nagisa commit[7] 2021-04-11: Auto merge of - tweksteen:androidsetmessage, r=m-ou-se commit[8] 2021-04-11: Auto merge of - hyd-dev:uwtable, r=nagisa
claim
Reduced reproduction:
claim
Code change:
fn make_final_bounds( &self, ty_to_bounds: FxHashMap<Type, FxHashSet<GenericBound>>, <del> ty_to_fn: FxHashMap<Type, (Option<PolyTrait>, Option<Type>)>, </del> <ins> ty_to_fn: FxHashMap<Type, (PolyTrait, Option<Type>)>, </ins> lifetime_to_bounds: FxHashMap<Lifetime, FxHashSet<GenericBound>>, ) -> Vec<WherePredicate> { ty_to_bounds .into_iter() .flat_map(|(ty, mut bounds)| { <del> if let Some(data) = ty_to_fn.get(&ty) { let (poly_trait, output) = (data.0.as_ref().unwrap().clone(), data.1.as_ref().cloned().map(Box::new)); </del> <ins> if let Some((ref poly_trait, ref output)) = ty_to_fn.get(&ty) { </ins> let mut new_path = poly_trait.trait_.clone(); let last_segment = new_path.segments.pop().expect("segments were empty");

Related discussion:
text: No crash in stable 1.62.1, crashes with nightly 2022-07-24 and 2022-08-03 : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
label -E-needs-mcve
Was this at least on a project you can share the source to, or was it closed source? If it's a big project that you can't minimise, then it would be good to share/link to that, so someone else can do the minimisation. an example is better than no example, even if it's not minimal.
Managed to find something. The bound seems crucially important.
searched nightlies: from nightly-2022-01-01 to nightly-2022-08-02 regressed nightly: nightly-2022-06-23 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsLooks like
Code change:
<del> Subproject commit 50ef22af522f2545295090cc1ad3e4bd4aa8632c </del> <ins> Subproject commit b8f617897a66953b9026c02f7a8f93a2e9611f63 </ins>

Related discussion:
text: 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!
Code change:
"regex-syntax", "semver", "serde", <del> "smallvec 0.6.10", </del> <ins> "smallvec 1.0.0", </ins> "toml", "unicode-normalization", "url 2.1.0",

Related discussion:
text: Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool clippy-driver 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 nomination label.
Code change:
panic!("dist: Error calling canonicalize path `{}`: {}", llvm_dylib_path.display(), e); }); <del> builder.install(&llvm_dylib_path, &dst_libdir1, 0o644); builder.install(&llvm_dylib_path, &dst_libdir2, 0o644); </del> <ins> builder.install(&llvm_dylib_path, dst_libdir, 0o644); </ins> } } <ins> /// Maybe add libLLVM.so to the target lib-dir for linking. pub fn maybe_install_llvm_target(builder: &Builder<'_>, target: Interned<String>, sysroot: &Path) { let dst_libdir = sysroot.join("lib/rustlib").join(&*target).join("lib"); maybe_install_llvm(builder, target, &dst_libdir); } /// Maybe add libLLVM.so to the runtime lib-dir for rustc itself. pub fn maybe_install_llvm_runtime(builder: &Builder<'_>, target: Interned<String>, sysroot: &Path) { let dst_libdir = sysroot.join(builder.sysroot_libdir_relative(Compiler { stage: 1, host: target })); maybe_install_llvm(builder, target, &dst_libdir); } </ins> #[derive(Clone, Debug, Eq, Hash, PartialEq)] pub struct LlvmTools { pub target: Interned<String>,

Related discussion:
text: Like running the cross-compiled on a host without anything more than the component?
Hmm, I can't actually get cross-builds to work with . I this to : ... so it would pick that up from the sysroot. Trying to cross-compile i686, I get: I do have both i686 and x8664 builds of in the sysroot. I suspect the error is because the i686 build has different metadata than my host build, so it can't find the one it wants for the host. That may mean that is really tied to being used on the same host. It works if I just compile native x86_64 though. Then I tried removing the , and it gets essentially the same error as : AFAICS, building normal crates still works fine with that extra removed though. In short: Cross-compiling with seems broken -- maybe it should be shipped native-only. The only difference would be in the manifest created for rustup. Linking to crates will inherit , so that needs to be in the library path.
Ah, fascinating. What happens if you build such an executable and then remove the component entirely? Can it pick up the dylibs outside or does it hardcode the paths inside?
The final executable still isn't actually linked to LLVM, since it didn't need any of those symbols: I can run this with , which set , or even if I set that path myself. But doesn't work if we've removed that library, since needs itself.
Okay, it being dependent on makes sense. Overall, probably the safe thing to do would be to move the duplicate to , oh well.
Oh, also needs LLVM, and those binaries are installed in with RUNPATH . I guess they might be able to find the LLVM in anyway?
Code change:
h2, h3, h4 { border-bottom: 1px solid; } <del> .impl, .method, .type:not(.container-rustdoc), .associatedconstant, .associatedtype { </del> <ins> .impl, .impl-items .method, .impl-items .type, .impl-items .associatedconstant, .impl-items .associatedtype { </ins> flex-basis: 100%; font-weight: 600; margin-top: 16px;

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:
// integer literal, push to vector expression ast::LitIntUnsuffixed(v) => { if v > 0xFF { <del> cx.span_err(expr.span, "too large integer literal in bytes!") </del> <ins> cx.span_err(expr.span, "too large integer literal in bytes!"); err = true; </ins> } else if v < 0 { <del> cx.span_err(expr.span, "negative integer literal in bytes!") </del> <ins> cx.span_err(expr.span, "negative integer literal in bytes!"); err = true; </ins> } else { bytes.push(cx.expr_u8(expr.span, v as u8)); }

Related discussion:
text: With landed, the lifetime of is now problematic. Specifically, the following used to work and now fails: The lifetime of is now limited to that branch of the match, so it doesn't live long enough to be assigned to . I'm not sure if this means lifetimes need to change. The other option is that needs to return a . Unfortunately, the only way to do that right now is to make it equivalent to , which makes it no longer usable as the value of a constant (e.g. ). I'm thinking the right solution is to make it legal for me to say . I can type that right now, but the lifetime seems to be wholly ignored, as I get the exact same error with the following as I do with the example above: If becomes a valid expression with the lifetime, then could start evaluating to that and everything should work as expected. Furthermore, it would be nice (but perhaps not required) if , where all elements are compile-time constants, would implicitly be given the lifetime.
/cc
Yeah, this is kind of annoying. I worked around it in one specific case by having bytes! expand as follows: I certainly think one should be allowed to write a concrete lifetime as part of a slice or borrow expression, and ought to be legal -- we'll obviously have to impose more stringent constant-related rules. In the short term, we could adjust to expand in the pattern I showed above. What was unclear to me was whether this is sufficient workaround, or whether we'll want something more general. Interestingly, even if we used full inference, the expression you gave above would be illegal unless we introduce a special case for static byte strings, because it generates a conditional temporary (only on one arm of the match) and we can't handle the cleanup for such a case without zeroing, which we plan to remove (well, I guess we could also have a special case for temporary types [like ) that do not require drop glue, but I'd rather not).
Perhaps the simplest fix for now is to adjust the macro itself to expand to a static item as I showed. I should probably have done that more generally but I was ready to land that expletive branch already.
Won't that prevent from being able to expand to a static?
I already adjusted like that and is correct, it prevents , which is definitely already used in our codebase.
Ah, unfortunate.
Code change:
// integer literal, push to vector expression ast::LitIntUnsuffixed(v) => { if v > 0xFF { <del> cx.span_err(expr.span, "too large integer literal in bytes!") </del> <ins> cx.span_err(expr.span, "too large integer literal in bytes!"); err = true; </ins> } else if v < 0 { <del> cx.span_err(expr.span, "negative integer literal in bytes!") </del> <ins> cx.span_err(expr.span, "negative integer literal in bytes!"); err = true; </ins> } else { bytes.push(cx.expr_u8(expr.span, v as u8)); }

Related discussion:
text: (I actually think we should allow statics to include nested blocks with other statics, but I guess that's a separate bug) Well, I'm not sure what's the easiest fix in that case, I guess just to fix the semantics of so that it guarantees static data. I'm not 100% sure what's implied by such a fix: it doesn't seem too hard ;)
cc
Code change:
<ins> #![feature(const_generics)] #![allow(incomplete_features)] struct Test(); fn pass() { println!("Hello, world!"); } impl Test { pub fn call_me(&self) { self.test::<pass>(); } fn test<const FN: fn()>(&self) { //~^ ERROR: using function pointers as const generic parameters is forbidden FN(); } } fn main() { let x = Test(); x.call_me() } </ins>

Related discussion:
text: I've tried reducing this but wasn't really able to so far. I might try again some other time. The code below currently ICEs on Nightly (). When trying to reproduce locally for the backtrace, I had an older Nightly first () where this actually didn't crash the compiler, so it's apparently a regression. <details<summary<strongBacktrace</strong</summary<p</p</details
This is my first time using cargo-bisect-rustc and it's fantastic. It identified the regression as... searched nightlies: from nightly-2020-02-13 to nightly-2020-05-14 regressed nightly: nightly-2020-03-20 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.2</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
is a rollup commit. The only PR which was part of that and (to me) looks like it could have caused this issue is .
Triage: the feature was removed by and the ICE no longer occurs with the latest nightly.
Code change:
<ins> #![feature(const_generics)] #![allow(incomplete_features)] struct Test(); fn pass() { println!("Hello, world!"); } impl Test { pub fn call_me(&self) { self.test::<pass>(); } fn test<const FN: fn()>(&self) { //~^ ERROR: using function pointers as const generic parameters is forbidden FN(); } } fn main() { let x = Test(); x.call_me() } </ins>

Related discussion:
text: produces: <details</detailsIt should not be possible to access the type parameter in the type of the const parameter. cc Thanks to for .
Hi, I am new to rust compiler development and have decided to try to fix this issue to get started. If I understand the const-generics RFC correctly, type parameters can not be used in a const generic parameter because it cannot be ensured that the actual types have the "structural match" property. However, checking reveals that fn pointers (as well as raw pointers and empty arrays) always support structural matching, regardless of the types used within. My question is: is there another reason why const generic parameters are not allowed to use type parameters? If so, I think an additional check has to be to .
Actually, I think I may have interpreted. It looks like this example is intended to work to me. cc just to clarify.
Triage: the feature was removed by and the ICE no longer occurs with the latest nightly.
Code change:
<ins> #![feature(const_generics)] #![allow(incomplete_features)] struct Test(); fn pass() { println!("Hello, world!"); } impl Test { pub fn call_me(&self) { self.test::<pass>(); } fn test<const FN: fn()>(&self) { //~^ ERROR: using function pointers as const generic parameters is forbidden FN(); } } fn main() { let x = Test(); x.call_me() } </ins>

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. -- <!-- 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
Probably related to
Triage: the feature was removed by and the ICE no longer occurs with the latest nightly.
Code change:
<ins> #![feature(const_generics)] #![allow(incomplete_features)] struct Test(); fn pass() { println!("Hello, world!"); } impl Test { pub fn call_me(&self) { self.test::<pass>(); } fn test<const FN: fn()>(&self) { //~^ ERROR: using function pointers as const generic parameters is forbidden FN(); } } fn main() { let x = Test(); x.call_me() } </ins>

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. -- <!-- 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
Depends on const generics in type dependent paths afaict. See for more info. EDIT: Also depends on const generics with generic types. Merging does not close this issue
Triage: the feature was removed by and the ICE no longer occurs with the latest nightly.
Adding the following as a test might still be useful, even if it only errors with "using function pointers as const parameters is forbidden":