jiebi/CodeConvo huggingface dataset:
Code change:
} } <ins> function getSearchLoadingText() { return "Loading search results..."; } </ins> if (search_input) { search_input.onfocus = function() { putBackSearch(this);

Related discussion:
text: Enable "Directly go to item in search if there is only one result" option on Settings ! Search an unique item in search box generated by rustdoc, it will lead you to the doc of that item. Click the go back button in browser, the page will change to previous search result and go forward to the doc of the searched item. How to reproduce the issue: Go to std doc: Search for "PhantomData" Click the go back button in browser. : 1.47.0-nightly ( 2020-08-20) cc
Well, you can but since there is only one result, it puts you back haha. (Ok, we can consider it as bug, but it's a funny one)
The single search result page can be elided using the to disappear it, leaving the back button to take you to before the search. I believe this would be the desired behavior?
What about detecting the key release to check if there's a single item and redirect, instead of redirecting after calculating the results?
Code change:
} impl FileType { <del> /// Test whether this file type represents a directory. </del> <ins> /// Test whether this file type represents a directory. The /// result is mutually exclusive to the results of /// [`is_file`] and [`is_symlink`]; only zero or one of these /// tests may pass. /// /// [`is_file`]: struct.FileType.html#method.is_file /// [`is_symlink`]: struct.FileType.html#method.is_symlink </ins> /// /// # Examples ///

Related discussion:
text: should document that , , and are all mutually exclusive. (and that it may also be the case that none of them are true) Why? Because returns true for both files and symlinks to files, and this tends to make me paranoid that a will share similar characteristics and perhaps claim that both and . The only way to convince myself that FileType's behavior is indeed sane is to write a little test program---again. Surely I can't be alone in this.
is calling not (and equivalent on Windows), so if the path is a symlink, then it returns the results based on what the symlink points to, not the symlink itself. So respects the same mutual exclusivity rules as . But yes, this ought to be documented, especially given that the mutually exclusive behavior may be surprising to Windows developers.
Similar goes for , which should document that these are always false for a obtained by calling on a symlink.
Well you can always call on something that is not a symlink, in which case or could be true.
Code change:
test(); } <ins> fn test_62350() { use std::ptr; unsafe { let null = ptr::null(); let q = QuadFloats { a: 10.2, b: 20.3, c: 30.4, d: 40.5 }; assert_eq!( get_c_exhaust_sysv64_ints(null, null, null, null, null, null, null, q), q.c, ); } } pub fn issue_62350() { test_62350(); } </ins> fn test1() { unsafe { let q = Quad { a: 0xaaaa_aaaa_aaaa_aaaa,

Related discussion:
text: We encountered this with WebRender, where we exposed a method in Rust to the Gecko, and the last parameters supplied appeared random on the Rust side. I made a reduced test case adapted from it that you can grab at: It is a very simple test case where the C++ program puts all the parameters on the stack, prints the expected values of some of them, and calls the Rust method. The Rust method prints the values it received. We have enough parameters to fill up the registers used in the calling convention, and once we get to pushing things on the stack, it goes wrong. You can see from the output that they mismatch. ./build- && ./run- outputs c++ expect width=7 height=8 c++ expect slice=9 10 11 12 c++ expect outset=13. 13. 13. 13. c++ expect repeat h=0 v=0 got rust image 6 width 7 height 8 got rust slice SideOffsets { top: 9, right: 10, bottom: 11, left: 12 } got rust outset LayoutGeometry { top: 0.0, left: 0.0, width: 0.0, height: 0.0 } got rust repeat h=26 v=58 Note that the earlier parameters are correct, but the last 3 (outset, repeat h and repeat v) are all incorrect.
Is there an upstream issue in WebRender you can link? What platform is this happening on?
The Gecko side integrating with WebRender was disabled, and I have been working to re-enable this in You can find the code in question at: I intend to just work around this using structs for the moment as part of the aforementioned bug.
We're seeing this on all of our x64 platforms (win, mac, linux; all using clang). It looks like a pretty clear bug in our sysv callee ABI for x64 when there are lots of arguments.
<details<summaryrustc callee llvm-ir </summary</details<details<summaryclang caller llvm-ir </summary</detailsJust the signatures:
Note to self: can go negative from scalar integer arguments after the 6 integer registers have been exhausted and then is always true. Will try to fix soon (also I wonder if this is a stable-to-stable regression from years ago?).
Code change:
test(); } <ins> fn test_62350() { use std::ptr; unsafe { let null = ptr::null(); let q = QuadFloats { a: 10.2, b: 20.3, c: 30.4, d: 40.5 }; assert_eq!( get_c_exhaust_sysv64_ints(null, null, null, null, null, null, null, q), q.c, ); } } pub fn issue_62350() { test_62350(); } </ins> fn test1() { unsafe { let q = Quad { a: 0xaaaa_aaaa_aaaa_aaaa,

Related discussion:
text: Looks like this was working circa 1.0, but has been broken at least since 1.12. Oof.
Do you need this fixed on beta as well, btw?
it would certainly be great if you uplifted this, but we have to work around it for the next few weeks anyway
Code change:
#[inline] fn next_back(&mut self) -> Option<$elem> { // could be implemented with slices, but this avoids bounds checks <del> if self.end == self.ptr { None } else { unsafe { </del> <ins> unsafe { if mem::size_of::<T>() != 0 { assume(!self.ptr.is_null()); assume(!self.end.is_null()); } if self.end == self.ptr { None } else { </ins> self.end = slice_offset!(self.end, -1); <del> if mem::size_of::<T>() != 0 { ::intrinsics::assume(!self.ptr.is_null()); ::intrinsics::assume(!self.end.is_null()); } </del> Some(slice_ref!(self.end)) } }

Related discussion:
text: time: 58.110 LLVM passes vs time: 785.935 LLVM passes running on hyper Full output at
cc (There's a slight suspicion that this may be caused by , since that's touching trans/codegen.)
ran with , got
cc
Could you provide files for before and after? Hopefully should work now.
Looks like this is caused by -- the assume intrinsics no longer get simplified into nonnull metadata on load instructions and cause massive slowdowns.
Code change:
} fn expr_field_access(&self, sp: Span, expr: P<ast::Expr>, ident: ast::Ident) -> P<ast::Expr> { <del> let field_span = Span { lo: sp.lo - Pos::from_usize(ident.name.as_str().len()), hi: sp.hi, expn_id: sp.expn_id, }; let id = Spanned { node: ident, span: field_span }; </del> <ins> let id = Spanned { node: ident, span: sp }; </ins> self.expr(sp, ast::ExprKind::Field(expr, id)) } fn expr_tup_field_access(&self, sp: Span, expr: P<ast::Expr>, idx: usize) -> P<ast::Expr> { <del> let field_span = Span { lo: sp.lo - Pos::from_usize(idx.to_string().len()), hi: sp.hi, expn_id: sp.expn_id, }; let id = Spanned { node: idx, span: field_span }; </del> <ins> let id = Spanned { node: idx, span: sp }; </ins> self.expr(sp, ast::ExprKind::TupField(expr, id)) } fn expr_addr_of(&self, sp: Span, e: P<ast::Expr>) -> P<ast::Expr> {

Related discussion:
text: cc , There are no guarantees that the two spans used to create the new one come from the same place or are even valid.
Code change:
view_path.map(|Spanned {node, span}| Spanned { node: match node { ViewPathSimple(ident, path) => { <del> ViewPathSimple(ident, fld.fold_path(path)) </del> <ins> ViewPathSimple(fld.fold_ident(ident), fld.fold_path(path)) </ins> } ViewPathGlob(path) => { ViewPathGlob(fld.fold_path(path)) } ViewPathList(path, path_list_idents) => { <del> ViewPathList(fld.fold_path(path), path_list_idents.move_map(|path_list_ident| { Spanned { node: PathListItem_ { id: fld.new_id(path_list_ident.node.id), rename: path_list_ident.node.rename, name: path_list_ident.node.name, }, span: fld.new_span(path_list_ident.span) } })) </del> <ins> let path = fld.fold_path(path); let path_list_idents = path_list_idents.move_map(|path_list_ident| Spanned { node: PathListItem_ { id: fld.new_id(path_list_ident.node.id), rename: path_list_ident.node.rename.map(|ident| fld.fold_ident(ident)), name: fld.fold_ident(path_list_ident.node.name), }, span: fld.new_span(path_list_ident.span) }); ViewPathList(path, path_list_idents) </ins> } }, span: fld.new_span(span)

Related discussion:
text: Test case: Compiles successfully on , causes an ICE on . Diff contains only , CC Found while trying to minimize , but filed separately since the error message is different and this one has a small test case.
Do you have a backtrace?
Yes of course. Sorry I forgot to include it: rust error: internal compiler error: attempted .defid() on invalid def: Err note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: note: run with for a backtrace thread 'rustc' panicked at 'Box<Any',
Code change:
view_path.map(|Spanned {node, span}| Spanned { node: match node { ViewPathSimple(ident, path) => { <del> ViewPathSimple(ident, fld.fold_path(path)) </del> <ins> ViewPathSimple(fld.fold_ident(ident), fld.fold_path(path)) </ins> } ViewPathGlob(path) => { ViewPathGlob(fld.fold_path(path)) } ViewPathList(path, path_list_idents) => { <del> ViewPathList(fld.fold_path(path), path_list_idents.move_map(|path_list_ident| { Spanned { node: PathListItem_ { id: fld.new_id(path_list_ident.node.id), rename: path_list_ident.node.rename, name: path_list_ident.node.name, }, span: fld.new_span(path_list_ident.span) } })) </del> <ins> let path = fld.fold_path(path); let path_list_idents = path_list_idents.move_map(|path_list_ident| Spanned { node: PathListItem_ { id: fld.new_id(path_list_ident.node.id), rename: path_list_ident.node.rename.map(|ident| fld.fold_ident(ident)), name: fld.fold_ident(path_list_ident.node.name), }, span: fld.new_span(path_list_ident.span) }); ViewPathList(path, path_list_idents) </ins> } }, span: fld.new_span(span)

Related discussion:
text: stack backtrace: 1: 0x7fc35e73fdf3 - std::sys::imp::backtrace::tracing::imp::write::hdfa3e34b856f69a3 2: 0x7fc35e74e5dd - std::panicking::defaulthook::{{closure}}::h20f8c1082e0ce86e 3: 0x7fc35e74e17b - std::panicking::defaulthook::hd31552ac08c2a241 4: 0x7fc35e74ea68 - std::panicking::rustpanicwithhook::h73969d230a072c1a 5: 0x7fc357eda667 - std::panicking::beginpanic::hb89a2261f4776ce3 6: 0x7fc357eef99f - rustcerrors::Handler::bug::h13b3b29154320abd 7: 0x7fc35bab053a - rustc::session::optspanbugfmt::{{closure}}::hfea18dd68f59976d 8: 0x7fc35baafff7 - rustc::session::optspanbugfmt::h7d370a0810dbdbbd 9: 0x7fc35baafce2 - rustc::session::bugfmt::hcde5f50c54004a4f 10: 0x7fc35b984552 - rustc::hir::def::Def::defid::h728c22aafbe84efc 11: 0x7fc35c6ddb3a - rustcprivacy::ObsoleteVisiblePrivateTypesVisitor::pathisprivatetype::h24756a49a68d1da9 12: 0x7fc35c6d53db - rustc::hir::intravisit::walkty::h64b13c0c45b7a09a 13: 0x7fc35c6d49ba - rustc::hir::intravisit::Visitor::visitfn::ha8ad665c42b1d643 14: 0x7fc35c6de7cf - <rustcprivacy::ObsoleteVisiblePrivateTypesVisitor<'a,
Code change:
view_path.map(|Spanned {node, span}| Spanned { node: match node { ViewPathSimple(ident, path) => { <del> ViewPathSimple(ident, fld.fold_path(path)) </del> <ins> ViewPathSimple(fld.fold_ident(ident), fld.fold_path(path)) </ins> } ViewPathGlob(path) => { ViewPathGlob(fld.fold_path(path)) } ViewPathList(path, path_list_idents) => { <del> ViewPathList(fld.fold_path(path), path_list_idents.move_map(|path_list_ident| { Spanned { node: PathListItem_ { id: fld.new_id(path_list_ident.node.id), rename: path_list_ident.node.rename, name: path_list_ident.node.name, }, span: fld.new_span(path_list_ident.span) } })) </del> <ins> let path = fld.fold_path(path); let path_list_idents = path_list_idents.move_map(|path_list_ident| Spanned { node: PathListItem_ { id: fld.new_id(path_list_ident.node.id), rename: path_list_ident.node.rename.map(|ident| fld.fold_ident(ident)), name: fld.fold_ident(path_list_ident.node.name), }, span: fld.new_span(path_list_ident.span) }); ViewPathList(path, path_list_idents) </ins> } }, span: fld.new_span(span)

Related discussion:
text: 'tcxas rustc::hir::intravisit::Visitor<'tcx::visititem::hae9f32c7942ccca1 15: 0x7fc35c6deab5 - <rustcprivacy::ObsoleteVisiblePrivateTypesVisitor<'a, 'tcxas rustc::hir::intravisit::Visitor<'tcx::visititem::hae9f32c7942ccca1 16: 0x7fc35c6e1b7a - rustcprivacy::checkcrate::h5ba75e3c4ebe0690 17: 0x7fc35eaef747 - rustcdriver::driver::phase3runanalysispasses::{{closure}}::h388b9236cf305089 18: 0x7fc35ead66d6 - rustcdriver::driver::phase3runanalysispasses::h080c1a734c4f2909 19: 0x7fc35eac5425 - rustcdriver::driver::compileinput::hab55539b85c4ceed 20: 0x7fc35eb0ea51 - rustcdriver::runcompiler::h128b89b79f649304 21: 0x7fc35ea236fb - std::panicking::try::docall::h15bca94dda232804 22: 0x7fc35e757b06 - rustmaybecatchpanic 23: 0x7fc35ea44d01 - <F as alloc::boxed::FnBox<A::callbox::h8832766c4bda585b 24: 0x7fc35e74d470 - std::sys::imp::thread::Thread::new::threadstart::h7d03d727f96da002 25: 0x7fc357684453 - startthread 26: 0x7fc35e4147de - GI__clone 27: 0x0 - <unknown
triage: P-high Seems bad. Assigning to based on bisection.
Fixed in .
Code change:
view_path.map(|Spanned {node, span}| Spanned { node: match node { ViewPathSimple(ident, path) => { <del> ViewPathSimple(ident, fld.fold_path(path)) </del> <ins> ViewPathSimple(fld.fold_ident(ident), fld.fold_path(path)) </ins> } ViewPathGlob(path) => { ViewPathGlob(fld.fold_path(path)) } ViewPathList(path, path_list_idents) => { <del> ViewPathList(fld.fold_path(path), path_list_idents.move_map(|path_list_ident| { Spanned { node: PathListItem_ { id: fld.new_id(path_list_ident.node.id), rename: path_list_ident.node.rename, name: path_list_ident.node.name, }, span: fld.new_span(path_list_ident.span) } })) </del> <ins> let path = fld.fold_path(path); let path_list_idents = path_list_idents.move_map(|path_list_ident| Spanned { node: PathListItem_ { id: fld.new_id(path_list_ident.node.id), rename: path_list_ident.node.rename.map(|ident| fld.fold_ident(ident)), name: fld.fold_ident(path_list_ident.node.name), }, span: fld.new_span(path_list_ident.span) }); ViewPathList(path, path_list_idents) </ins> } }, span: fld.new_span(span)

Related discussion:
text: Servo compiles with rustc 2016-12-18, but not with 2016-12-21. Diff: The crate fails to build with: The method being called here is: Its return type is which is . This call is in another impl of the same method of the same trait: Adding an explicit type annotation works around this error, but only to uncover another very similar one, then another. The third one was in code generated by serde’s , so I gave up that approach. So far I haven’t managed to reduce a test case smaller than "most of Servo", sorry. I’m suspicious of (which is part of ) because it’s commit message mentions inference. I’m not building a compiler to confirm.
CC
Also fails in , so is not to blame. New diff: I don’t have another guess, and doing a full bisect would take a very long time…
I can't find the cause in that range, at least nothing changed in the compiler AFAICT. Can you try (the commit before larger rollup)?
Expanding the macro: (Even simplifying it, this is not using ) gives:
Alright, that matches what I've seen from What about a couple more steps of bisecting? Or maybe compiling this crate with the "servo" feature off (which, AFAICT, turns off all the macros 1.1 - they might be responsible).
Swapping the order of the two arms: Changing the pattern to : Hacking to not use the stable version of the compiler (so effectively disabling the feature and enabling the one) also gives the same error.
New range, based on manual bisect: good, bad. Diff: , which leaves only in-between. CC Also found more clues. More context for the code where the error happens: is a module generated by a macro, that contains re-exports of other modules: If I add a similar not in a macro: or if I change the original code to use the real path without going through a , this seems to work around this issue completely. … only to uncover another one:
Found another ICE, I don’t know if it’s related: .
Code change:
view_path.map(|Spanned {node, span}| Spanned { node: match node { ViewPathSimple(ident, path) => { <del> ViewPathSimple(ident, fld.fold_path(path)) </del> <ins> ViewPathSimple(fld.fold_ident(ident), fld.fold_path(path)) </ins> } ViewPathGlob(path) => { ViewPathGlob(fld.fold_path(path)) } ViewPathList(path, path_list_idents) => { <del> ViewPathList(fld.fold_path(path), path_list_idents.move_map(|path_list_ident| { Spanned { node: PathListItem_ { id: fld.new_id(path_list_ident.node.id), rename: path_list_ident.node.rename, name: path_list_ident.node.name, }, span: fld.new_span(path_list_ident.span) } })) </del> <ins> let path = fld.fold_path(path); let path_list_idents = path_list_idents.move_map(|path_list_ident| Spanned { node: PathListItem_ { id: fld.new_id(path_list_ident.node.id), rename: path_list_ident.node.rename.map(|ident| fld.fold_ident(ident)), name: fld.fold_ident(path_list_ident.node.name), }, span: fld.new_span(path_list_ident.span) }); ViewPathList(path, path_list_idents) </ins> } }, span: fld.new_span(span)

Related discussion:
text: Found a smaller test case for the inference issue: rust fn main() {} pub mod a { pub struct FontFamily; impl FontFamily { pub fn tocss(&self) -::std::fmt::Result { Ok(()) } } } macrorules! reexport { () ={ mod b { pub use a; } } } reexport!(); pub mod c { use b::a::FontFamily; struct FontFace { family: FontFamily } impl FontFace { pub fn tocss(&self) -::std::fmt::Result { try!(()); Ok(()) } } }
That "other ICE" is actually a direct observation of the bug, whereas this inference issue is some weird side-effect of the way we handle errors that don't stop compilation.
never mind, apparently it fails locally
triage: P-high Seems bad. Assigning to based on bisection.
Does this affect beta ()?
At the moment the latest successful nightly build is 3 days old. I don’t know how often playpen’s nigthly is updated. merged 2 days ago. (This is the rollup PR that merged , which introduced this issue if I did my manual bisecting correctly.) As far as I can tell no, is not reachable from and so beta is not affected.
Fixed in .
Code change:
<ins> // known-bug // build-fail // failure-status: 101 // compile-flags:--crate-type=lib -Zmir-opt-level=3 // rustc-env:RUST_BACKTRACE=0 // normalize-stderr-test "thread 'rustc' panicked.*" -> "thread 'rustc' panicked" // normalize-stderr-test "note:.*RUST_BACKTRACE=1.*n" -> "" // normalize-stderr-test "error: internal compiler error.*" -> "error: internal compiler error" // normalize-stderr-test "encountered.*with incompatible types:" "encountered ... with incompatible types:" // normalize-stderr-test "note:.*unexpectedly panicked.*nn" -> "" // normalize-stderr-test "note: we would appreciate a bug report.*nn" -> "" // normalize-stderr-test "note: compiler flags.*nn" -> "" // normalize-stderr-test "note: rustc.*running on.*nn" -> "" // normalize-stderr-test "query stack during panic:n" -> "" // normalize-stderr-test "we're just showing a limited slice of the query stackn" -> "" // normalize-stderr-test "end of query stackn" -> "" // normalize-stderr-test "#.*n" -> "" // This is a known bug that @compiler-errors tried to fix in #94238, // but the solution was probably not correct. pub trait Factory<T> { type Item; } pub struct IntFactory; impl<T> Factory<T> for IntFactory { type Item = usize; } pub fn foo<T>() where IntFactory: Factory<T>, { let mut x: <IntFactory as Factory<T>>::Item = bar::<T>(); } #[inline] pub fn bar<T>() -> <IntFactory as Factory<T>>::Item { 0usize } </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> // known-bug // build-fail // failure-status: 101 // compile-flags:--crate-type=lib -Zmir-opt-level=3 // rustc-env:RUST_BACKTRACE=0 // normalize-stderr-test "thread 'rustc' panicked.*" -> "thread 'rustc' panicked" // normalize-stderr-test "note:.*RUST_BACKTRACE=1.*n" -> "" // normalize-stderr-test "error: internal compiler error.*" -> "error: internal compiler error" // normalize-stderr-test "encountered.*with incompatible types:" "encountered ... with incompatible types:" // normalize-stderr-test "note:.*unexpectedly panicked.*nn" -> "" // normalize-stderr-test "note: we would appreciate a bug report.*nn" -> "" // normalize-stderr-test "note: compiler flags.*nn" -> "" // normalize-stderr-test "note: rustc.*running on.*nn" -> "" // normalize-stderr-test "query stack during panic:n" -> "" // normalize-stderr-test "we're just showing a limited slice of the query stackn" -> "" // normalize-stderr-test "end of query stackn" -> "" // normalize-stderr-test "#.*n" -> "" // This is a known bug that @compiler-errors tried to fix in #94238, // but the solution was probably not correct. pub trait Factory<T> { type Item; } pub struct IntFactory; impl<T> Factory<T> for IntFactory { type Item = usize; } pub fn foo<T>() where IntFactory: Factory<T>, { let mut x: <IntFactory as Factory<T>>::Item = bar::<T>(); } #[inline] pub fn bar<T>() -> <IntFactory as Factory<T>>::Item { 0usize } </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