jiebi/CodeConvo huggingface dataset:
Code change:
let mut lifetime_to_bounds: FxHashMap<_, FxHashSet<_>> = Default::default(); let mut ty_to_traits: FxHashMap<Type, FxHashSet<Path>> = Default::default(); <del> let mut ty_to_fn: FxHashMap<Type, (Option<PolyTrait>, Option<Type>)> = Default::default(); </del> <ins> let mut ty_to_fn: FxHashMap<Type, (PolyTrait, Option<Type>)> = Default::default(); </ins> for p in clean_where_predicates { let (orig_p, p) = (p, p.clean(self.cx));

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:
if let mir::PlaceRef { base: &PlaceBase::Static(box Static { <del> kind: StaticKind::Promoted(promoted, _), </del> <ins> kind: StaticKind::Promoted(promoted, substs), </ins> ty, <del> def_id: _, </del> <ins> def_id, </ins> }), projection: &[], } = place.as_ref() { <del> let c = bx.tcx().const_eval_promoted(self.instance, promoted); </del> <ins> let c = bx.tcx().const_eval_promoted( Instance::new(def_id, self.monomorphize(&substs)), promoted, ); </ins> let (llval, ty) = self.simd_shuffle_indices( &bx, terminator.source_info.span,

Related discussion:
text: It should use . ( is the second field of .) While both instances are normally equal, they can differ after running the mir inliner. In that case the promoted will refer to the inlined function. modify labels: +A-mir +C-bug +requires-nightly <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
cc
Can I give this a go? claim
Do you have any specific tests in mind I should add to check for the correct behaviour?
should be a test if the mir inliner would to inline . Somehow it doesn't though.
You might be running into this unfortunate check Try moving below .
Wow, that's hilarious. With just the changes suggested, the inlining still doesn't work properly, but doesn't seem to break any existing stuff. But I've just tried this and yeah, putting ret_slice below main has made the MIR inliner work.
This does inline, but somehow no assertion fires with current rustc. The printed MIR doesn't seem to show the the def_id from which the promoted originates, so I don't know what the problem is.
Unless I'm misunderstanding something, isn't this the correct behaviour? Both of those assertions are true, and swapping and around in the assertions correctly triggers an assertion failure.
I forgot that this problem was only with .
I got a working test:
Ah, that's a good test case. Yeah, that's definitely not the expected behaviour. While messing about with your example, I also managed to come across an ICE with this slightly shorter version: causes an ICE currently due to an internal index out of range. The good news is that the changes you suggested fixes both of these test cases. Good spot :) I'm putting up the PR now.
Code change:
use crate::errors::OpaqueHiddenTypeDiag; use crate::infer::{DefiningAnchor, InferCtxt, InferOk}; use crate::traits; <ins> use hir::def::DefKind; </ins> use hir::def_id::{DefId, LocalDefId}; use hir::{HirId, OpaqueTyOrigin}; use rustc_data_structures::sync::Lrc;

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> struct RGB { g: f64, b: f64, } fn main() { let (r, alone_in_path, b): (f32, f32, f32) = (e.clone(), e.clone()); //~^ ERROR cannot find value `e` in this scope //~| ERROR cannot find value `e` in this scope //~| ERROR mismatched types let _ = RGB { r, g, b }; //~^ ERROR cannot find value `g` in this scope //~| ERROR struct `RGB` has no field named `r` //~| ERROR mismatched types } </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</details
Regression in
I think it's enough to change to be without .
Code change:
<ins> macro_rules! many_args { ([$($t:tt)*]#$($h:tt)*) => { many_args!{[$($t)*$($t)*]$($h)*} }; ([$($t:tt)*]) => { fn _f($($t: ()),*) {} //~ ERROR function can not have more than 65535 arguments } } many_args!{[_]########## ######} fn main() {} </ins>

Related discussion:
text: Obviously a corner case. This would never actually be used for anything, this is just testing the bounds of what the compiler is capable of. Running this Ruby method with numarguments or greater generates a Rust file which can be used to reproduce the output. (via ) : </p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
label +regression-from-stable-to-beta
Nothing that Ruby code can achieve that Rust macros couldn't do as well: ()
Haha, just tried out a different direction of “many arguments”. Apparently this results in a segfault, AFAICT It’s explicitly a stack overflow on stable (and AFAIK segfaults can happen on stack overflow in sound rust code, so maybe it isn’t some memory unsafety). <hrEdit: Opened this as a separate issue
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-low
Code change:
} item_mac(ref m) => { // FIXME #2888: we might actually want to do something here. <del> item_mac(copy *m) </del> <ins> // ... okay, we're doing something. It would probably be nicer // to add something to the ast_fold trait, but I'll defer // that work. item_mac(fold_mac_(m,fld)) </ins> } } }

Related discussion:
text: See the case in .
Not critical for 0.6; de-milestoning
-- does it make sense for the AST fold to visit macros? Or is the current code correct?
From my perspective: yes, definitely. In particular, I'm going to want ident-folds to hit the idents inside of macro invocations. Could it break code to add this traversal? Well, the only place you're going to see unexpanded macro invocations is prior to expansion, and the only thing inside of macro invocations is tokens, so it seems very unlikely. To summarize: yes, this fold should visit macro invocations.
In that case, nominating for milestone 5, production-ready
accepted for production-ready milestone
I've implemented this in a local branch, I expect to push it soon (next two days)
done, now. FIXME removed downstream.
Code change:
<ins> error: internal compiler error error: internal compiler error encountered ... with incompatible types: left-hand side has type: <IntFactory as Factory<T>>::Item right-hand side has type: usize --> $DIR/select-param-env-instead-of-blanket.rs:42:5 | LL |     let mut x: <IntFactory as Factory<T>>::Item = bar::<T>(); |                                                   ---------- in this inlined function call ... LL |     0usize |     ^^^^^^ | = note: delayed at compiler/rustc_const_eval/src/transform/validate.rs:128:36 thread 'rustc' panicked </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. --./src/test/ui/impl- or ./src/test/ui/impl-trait/issues/issue- <!-- 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</detailscc I believe this might be caused by
I'll look into it regardless
I was unable to reproduce same error perhaps it already fixed on stable channel try updating your rust compiler onto stable channel
the nightly that contains suspicious commit has not been released yet, there is no point in trying to reproduce this with nightly (or even stable). You'll need something that contains
This is the same issue that I identified in , but the bug identified and fixed in actually caused it to not be triggered until now. The issue here is a "trivial bound" () causing us to not select but in the MIR inliner. The caching bug actually caused the latter branch to happen everywhere, so when that bug was fixed, we started to normalize to in some places, causing this ICE. I bet I could trigger an ICE with a slight modification to this code using the inliner even with reverted. This is probably only triggered by the inliner, but the MIR inliner isn't enabled without being explicitly provided, right?
Code change:
<ins> error: internal compiler error error: internal compiler error encountered ... with incompatible types: left-hand side has type: <IntFactory as Factory<T>>::Item right-hand side has type: usize --> $DIR/select-param-env-instead-of-blanket.rs:42:5 | LL |     let mut x: <IntFactory as Factory<T>>::Item = bar::<T>(); |                                                   ---------- in this inlined function call ... LL |     0usize |     ^^^^^^ | = note: delayed at compiler/rustc_const_eval/src/transform/validate.rs:128:36 thread 'rustc' panicked </ins>

Related discussion:
text: Trying to emulate trivial bounds via generics & associated types panics on stable, beta and nightly. <!-- 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. --: Reproducible on beta and nightly <!-- 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 --
Bug is not present in 1.51 and appears in 1.52. More precisely, it appeared somewhere between and .
Seems like introduces the regression Probably is the culprit
It seems to affect only traits that are checked by . Changing to fixes the panic.
I wonder if this could be fixed by normalizing the caller-bounds when checking for trivial bounds in WF. Hmm.... might think about this issue later tonight.
I'm putting up a PR soon to fix a whole bunch of impossible-bounds related things. So I'll claim this for the time being. claim
Code change:
} } #[stable(feature = "rust1", since = "1.0.0")] <del> impl Write for File { </del> <ins> impl Write for &File { </ins> fn write(&mut self, buf: &[u8]) -> io::Result<usize> { self.inner.write(buf) }

Related discussion:
text: Some types ( and in particular) implement and on . If one of these types are wrapped in an (or ), there is no real reason why one shouldn't be able to call or methods on it. For example, this code should compile: I think this can be implemented pretty straightforwardly by adding the following impls to and : Are there good reasons for why impls like these shouldn't be ?
Closing because generic impls like proposed won't behave correctly, as described in .
Code change:
<ins> #![doc(html_logo_url = "https://raw.githubusercontent.com/sagebind/isahc/master/media/isahc.svg.png")] // Note: this test is paired with logo-class-default.rs. // @has logo_class/struct.SomeStruct.html '//*[@class="logo-container"]/img[@src="https://raw.githubusercontent.com/sagebind/isahc/master/media/isahc.svg.png"]' '' // @!has logo_class/struct.SomeStruct.html '//*[@class="logo-container"]/img[@class="rust-logo"]' '' // // @has logo_class/struct.SomeStruct.html '//*[@class="sub-logo-container"]/img[@src="https://raw.githubusercontent.com/sagebind/isahc/master/media/isahc.svg.png"]' '' // @!has logo_class/struct.SomeStruct.html '//*[@class="sub-logo-container"]/img[@class="rust-logo"]' '' pub struct SomeStruct; </ins>

Related discussion:
text: In RustCrypto crates we use which changes style depending on preferred theme using CSS rules. You can see the for an example which uses it. But the problem is how the logo gets rendered on dark themes: ! ! The reason for such horrible result is the white shadow filter applied to the logo. I understand why it was , but I think it's a wrong approach, especially for projects which aim to properly support dark themes in their media files.
There was a mention back when this was implemented about how it is not possible for a media query approach to work, when I look at the sha2 docs it looks like ! because I use a light theme generally in my browser, but have rustdoc explicitly set to a dark theme. I'm confused why the outline is being applied to these docs though, was meant to only apply it to the default rust logo, and I don't see any relevant newer PRs when searching for .
I believe I broke this in In we are supposed to apply the class only when the logo is the default one. In I missed that distinction and now the always gets the rust-logo class, even when it's a custom logo. I'll fix.
By the way, to confirm what said: the media query embedded in the SVG isn't really right. That gets the browser's preferred light/dark mode, but the user may have overridden that in rustdoc settings. As a concrete example, I'm using Chrome on Linux, which doesn't have a light/dark mode setting. I can select a dark theme in rustdoc settings, which will get me this for the Rust Crypto logo (with applied): ! That's still an improvement over the status quo, and overall I think it's fine. But if we really wanted to support theme-sensitive logos perfectly, I think we'd need to offer separate configuration options for a light logo and a dark logo.
I believe that the media query approach is a correct one in principle. But I agree that, unfortunately, the current state of browsers is far from ideal, e.g. it would be nice to have a way to switch preferred mode for a page using CSS or JS. I'm using Chrome on Linux, which doesn't have a light/dark mode setting Well, it kind of has. Try launching it with (I don't have Chrome installed, but I think it should work similarly).
Code change:
<ins> warning: the feature `non_lifetime_binders` is incomplete and may not be safe to use and/or cause compiler crashes --> $DIR/unifying-placeholders-in-query-response-2.rs:5:12 | LL | #![feature(non_lifetime_binders)] |            ^^^^^^^^^^^^^^^^^^^^ | = note: see issue #108185 <https://github.com/rust-lang/rust/issues/108185> for more information = note: `#[warn(incomplete_features)]` on by default warning: 1 warning emitted </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. --minimal project with full compiler output can be found here cargo 1.77.0-nightly ( 2024-01-09) : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Code change:
<del> // Copyright 2012-2014 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. </del> <ins> // The Computer Language Benchmarks Game // http://benchmarksgame.alioth.debian.org/ </ins> // <del> // 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. </del> <ins> // contributed by the Rust Project Developers // Copyright (c) 2012-2014 The Rust Project Developers // // All rights reserved. // // Redistribution and use in source and binary forms, with or without // modification, are permitted provided that the following conditions // are met: // // - Redistributions of source code must retain the above copyright //   notice, this list of conditions and the following disclaimer. // // - Redistributions in binary form must reproduce the above copyright //   notice, this list of conditions and the following disclaimer in //   the documentation and/or other materials provided with the //   distribution. // // - Neither the name of "The Computer Language Benchmarks Game" nor //   the name of "The Computer Language Shootout Benchmarks" nor the //   names of its contributors may be used to endorse or promote //   products derived from this software without specific prior //   written permission. // // THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS // "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT // LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS // FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE // COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, // INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES // (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR // SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) // HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, // STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) // ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED // OF THE POSSIBILITY OF SUCH DAMAGE. </ins> #![feature(phase)] #[phase(plugin)] extern crate green;

Related discussion:
text: See I propose to change the license of Non trivial contributors: OK OK OK Contributors appearing in git blame that are trivial (trivial update due to language changes): OK OK OK OK Contributors with removed and trivial contributions are not considered. For the persons that are not in "OK" state, please respond to this issue saying: Then, I'll propose the corresponding PR. Thanks.
I agree to relicense any previous contributions to according to the term of the Computer Language Benchmarks Game license ()
I agree to relicense any previous contributions to according to the term of the Computer Language Benchmarks Game license ()
Code change:
} } <ins> // See comments in `interpolated_to_tokenstream` for why we care about // *probably* equal here rather than actual equality // // This is otherwise the same as `eq_unspanned`, only recursing with a // different method. pub fn probably_equal_for_proc_macro(&self, other: &TokenTree) -> bool { match (self, other) { (&TokenTree::Token(_, ref tk), &TokenTree::Token(_, ref tk2)) => { tk.probably_equal_for_proc_macro(tk2) } (&TokenTree::Delimited(_, ref dl), &TokenTree::Delimited(_, ref dl2)) => { dl.delim == dl2.delim && dl.stream().probably_equal_for_proc_macro(&dl2.stream()) } (_, _) => false, } } </ins> /// Retrieve the TokenTree's span. pub fn span(&self) -> Span { match *self {

Related discussion:
text: This is minimized from the dramatic forum thread . The following code is fine in nightly-2018-04-12 but breaks with nightly-2018-04-15. Oddly, lots of minor perturbations make it succeed. For example remove the two characters and it works. Or remove the single quote in the string and it works.
Alrighty-roo. As everything these days with hygiene, there's a couple of bugs here. With this one though I think only two! Everything has to do here with basically. AKA anything that runs through that falls off The usual reasons we think you fall off the "happy path" are due to things like inner attributes, , macro expansion, etc. None of that's present here! It should be the case that above can be losslessly converted to a based on what we've cached. Turns out though had a bug in it (surprise surprise!). There we're using to compare the resulting two token streams which eventually bottoms out in . As it turns out this isn't quite what we want! The implementation is structural, but the token stream we get when stringifying is slightly different than what we parsed. Here in the example you're using the literal string , but rustc stringifies this token as . Similarly if you replaced the string with something like it'll be stringified as . This means that the tokens are not literally byte-for-byte equal, which means we fall off the happy path! tl;dr the token stream of is not equivalent to the token stream . This causes us to fall off the happy path and used a stringified token stream. OK so in the case above we're falling off the happy path when we didn't expect to, but even still there's some weird bad hygiene behavior when we're not on the happy path. There's still something to fix! It turns out that there's also a regression due to (found via bisection). Before that PR this example would compile just fine, afterwards though it's hitting this error. can you help diagnose this and see what's going on? The reduced test case I have right now is: (note the inner attribute on to force using a non-cached token stream)
I've posted a fix for the "happy path" at will actually fix example above.
Code change:
} } <ins> // See comments in `interpolated_to_tokenstream` for why we care about // *probably* equal here rather than actual equality // // This is otherwise the same as `eq_unspanned`, only recursing with a // different method. pub fn probably_equal_for_proc_macro(&self, other: &TokenTree) -> bool { match (self, other) { (&TokenTree::Token(_, ref tk), &TokenTree::Token(_, ref tk2)) => { tk.probably_equal_for_proc_macro(tk2) } (&TokenTree::Delimited(_, ref dl), &TokenTree::Delimited(_, ref dl2)) => { dl.delim == dl2.delim && dl.stream().probably_equal_for_proc_macro(&dl2.stream()) } (_, _) => false, } } </ins> /// Retrieve the TokenTree's span. pub fn span(&self) -> Span { match *self {

Related discussion:
text: That PR does not, however, fix the regression from which is still reproducible with the example I gisted.
Any idea why my repro case above is fixed if you remove the tokens? It seems like should fall off the happy path just as much.
If you remove the tokens we're still on the stringification path (aka not the happy path). For whatever reason though the hygiene bug goes away. That's likely caused from a subtelty introduced in (or at least so I'm hoping). I don't know much about , so I'm hoping will be able to look at this and know what's going on!
I don't know much about , so I'm hoping will be able to look at this and know what's going on! I'll investigate.
is the commit causing the regression. Further investigation is in progress.
An issue recently popped up on Rocket () that appears to be identical to this one and is not resolved in any recent nightly. It's possible that the root cause is , however.