jiebi/CodeConvo huggingface dataset:
Change:
// search for relevant arguments. let mut arguments = Vec::new(); for (index, argument) in sig.inputs().skip_binder().iter().enumerate() { <del> if let ty::Ref(argument_region, _, _) = argument.kind() { if argument_region == return_region { // Need to use the `rustc_middle::ty` types to compare against the // `return_region`. Then use the `rustc_hir` type to get only // the lifetime span. if let hir::TyKind::Ref(lifetime, _) = &fn_decl.inputs[index].kind { </del> <ins> if let ty::Ref(argument_region, _, _) = argument.kind() && argument_region == return_region { // Need to use the `rustc_middle::ty` types to compare against the // `return_region`. Then use the `rustc_hir` type to get only // the lifetime span. match &fn_decl.inputs[index].kind { hir::TyKind::Ref(lifetime, _) => { </ins> // With access to the lifetime, we can get // the span of it. arguments.push((*argument, lifetime.ident.span)); <del> } else { bug!("ty type is a ref but hir type is not"); </del> <ins> } // Resolve `self` whose self type is `&T`. hir::TyKind::Path(hir::QPath::Resolved(None, path)) => { if let Res::SelfTyAlias { alias_to, .. } = path.res && let Some(alias_to) = alias_to.as_local() && let hir::Impl { self_ty, .. } = self .infcx .tcx .hir_node_by_def_id(alias_to) .expect_item() .expect_impl() && let hir::TyKind::Ref(lifetime, _) = self_ty.kind { arguments.push((*argument, lifetime.ident.span)); } } _ => { // Don't ICE though. It might be a type alias. </ins> } } }

Discussion:
I'll even accept that this is probably UB if I somehow make it work but crashing on is probably not the way. Replacing some with , or with a second lifetime parameter correctly rejects the code. : <details<summary<strongBacktrace</strong</summary<p</p</details
Regression in nightly-2022-06-08 fetching (via remote github) commits from max(, 2022-06-05) to ending github query because we found starting sha: getcommitsbetween returning commits, len: 7 commit[0] 2022-06-06: Auto merge of - flip1995:clippyup, r=Manishearth commit[1] 2022-06-06: Auto merge of - matthiaskrgr:rollup-ajyvjd3, r=matthiaskrgr commit[2] 2022-06-07: Auto merge of - RalfJung:miri, r=RalfJung commit[3] 2022-06-07: Auto merge of - jackh726:remove-borrowck-mode, r=nikomatsakis commit[4] 2022-06-07: Auto merge of - scottmcm:add-coldcc, r=nagisa,lcnr commit[5] 2022-06-07: Auto merge of - Dylan-DPC:rollup-ya51k1k, r=Dylan-DPC commit[6] 2022-06-07: Auto merge of - Dylan-DPC:rollup-0ae3pwp, r=Dylan-DPC
Likely .
Change:
Node::Visibility(&Spanned { node: hir::VisibilityKind::Restricted { ref path, .. }, .. }) => path.def, <del> Node::PathSegment(seg) => match seg.def { Some(def) => def, None => HirDef::Err, </del> <ins> Node::PathSegment(seg) => { match seg.def { Some(def) if def != HirDef::Err => def, _ => self.get_path_def(self.tcx.hir().get_parent_node(id)), } </ins> }, Node::Expr(&hir::Expr { node: hir::ExprKind::Struct(ref qpath, ..),

Discussion:
Here's a small testcase: If you run this through and look at the save-analysis JSON file, you'll see that there is no entry for the part of . This seems like a bug.
/cc
According to the expression is a where the part would be a with two s. This seems to be processed in . Not obvious to me why it would fail, since the at the end looks like it should deal with the first path segment.
cc me
I'm taking a look at this, fwiw. does nothing with the segment, looks like it should.
Oh, it's a bit more subtle, but I see what's going on now.
I got a fix, testing to see if I can remove hacks to existing code now.
Fix is at , but it's unclear to me how to add a test for this. Any doc I could look at?
Change:
argument_scope: region::Scope, ast_body: &'tcx hir::Expr<'tcx>, ) -> BlockAnd<()> { <del> let tcx = self.hir.tcx(); let attrs = tcx.codegen_fn_attrs(fn_def_id); let naked = attrs.flags.contains(CodegenFnAttrFlags::NAKED); </del> // Allocate locals for the function arguments for &ArgInfo(ty, _, arg_opt, _) in arguments.iter() { let source_info = SourceInfo::outermost(arg_opt.map_or(self.fn_span, |arg| arg.pat.span)); let arg_local = self.local_decls.push(LocalDecl::with_source_info(ty, source_info)); <del> // Emit function argument debuginfo only for non-naked functions. // See: https://github.com/rust-lang/rust/issues/42779 if naked { continue; } </del> // If this is a simple binding pattern, give debuginfo a nice name. if let Some(arg) = arg_opt { if let Some(ident) = arg.pat.simple_ident() {

Discussion:
When compiling () The generated assembly includes a prologue with unexpected 's (as well as a trailing , already reported in ) Expected behaviour would be to have no prologue (and prevent compilation of a function that is not as this would require implementing an undefined ABI, contrarily to what seems to happen ). This is treacherous, as it dereferences some memory locations that may not be accessible, as happened to me and led to hours of debugging to finally figure out the compiled function was not the one defined. cc
IIRC this is invalid and rustc should reject such a function, naked functions can't take arguments and the compiler should probably enforce that.
Hmm, my understanding of the RFC (“The following variant is not an error because the C calling convention is well-defined and it is thus possible for the programmer to write a conforming function”, even if the example is not with an argument) would mean that if the function is declared , then the function can actually respect the said ABI, thus should be well-formed?
Is there an update on this? I was hit by this issue as well. I hit the problem when compiling a tock app (baremetal-ish and jumped to by the tock OS) A naked function with arguments would produce this prolog (RV32): Which would result in an invalid access as s0 would be 0. Removing the arguments would remove the prologue and fix the problem. Removing the naked cfg would also work as teh stack pointer was already setup by the OS and result in this. If arguments with naked functions aren't supported rustc should generate an error as this is a difficult problem to debug.
This is an LLVM bug. Has it been reported upstream?
Change:
<ins> #![feature(generic_const_exprs)] //~^ WARN the feature `generic_const_exprs` is incomplete #![feature(non_lifetime_binders)] //~^ WARN the feature `non_lifetime_binders` is incomplete // Test for <https://github.com/rust-lang/rust/issues/115497>, // which originally relied on associated_type_bounds, but was // minimized away from that. trait TraitA { type AsA; } trait TraitB { type AsB; } trait TraitC {} fn foo<T>() where for<const N: u8 = { T::A }> T: TraitA<AsA = impl TraitB<AsB = impl TraitC>>, //~^ ERROR defaults for generic parameters are not allowed in `for<...>` binders //~| ERROR `impl Trait` is not allowed in bounds { } fn main() {} </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'assertion failed: expect 1 RPITITs in call to '', 'thread 'rustc' panicked at 'assertion failed: expect 1 RPITITs in call to '' File: --auto-reduced (treereduce-rust): original: Version information ` <!-- query stack: [collectreturnpositionimpltraitintraittys] comparing an impl and trait method signature, inferring any hidden types in the process [typeof] computing type of [checkmodimplwf] checking that impls are well-formed in top-level module [analysis] running analysis passes on this crate --
Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details

<!-- 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 nightly-2023-05-04 commit[0] 2023-05-02: Auto merge of - compiler-errors:attr-query-no-caching, r=cjgillot commit[1] 2023-05-02: Auto merge of - fortanix:raoul/bugfixlibtestjson_synchronization, r=pietroalbini commit[2] 2023-05-03: Auto merge of - nnethercote:restrict-From-for-Diagnostics, r=davidtwco commit[3] 2023-05-03: Auto merge of - weihanglo:update-cargo, r=weihanglo commit[4] 2023-05-03: Auto merge of - jdno:reduce-builder-sizes, r=pietroalbini commit[5] 2023-05-03: Auto merge of - cuviper:ct-ng-1.25, r=pietroalbini commit[6] 2023-05-03: Auto merge of - Dylan-DPC:rollup-0pq0hh3, r=Dylan-DPC
Minimized:
Above example bisects to :thinking:
Change:
C, } <ins> enum Option2<A, B> { Some(A, B), None } </ins> pub fn main() { assert_eq!(size_of::<u8>(), 1 as usize); assert_eq!(size_of::<u32>(), 4 as usize);

Discussion:
On x86_64, this prints the values in comments: What's happening here is that when we pick the niche to represent of , we pick the largest (or "roomiest") of the niches in , so that further enums around have more optimization opportunities themselves. (Why just one niche? That has to do with the fact that in an , the only part of the representation guaranteed to be always initialized and valid is the tag / niche, but no other variant fields) For , however, we just pick the best niche in and only look at if has no niches at all, so if has a better niche, we miss it. This is a small oversight in the code itself, and arguably it will be slightly nicer once this is fixed, but I wanted to open this issue first, before I have a chance to fix it myself (if someone else doesn't get there first). cc
I was pretty sure that my patch to find the roomiest niche covered that case, but apparently it didn't. :(
Change:
ty::TyStruct(def, substs) => { let ccx = bcx.ccx(); // First get the size of all statically known fields. <del> // Don't use type_of::sizing_type_of because that expects t to be sized. </del> <ins> // Don't use type_of::sizing_type_of because that expects t to be sized, // and it also rounds up to alignment, which we want to avoid, // as the unsized field's alignment could be smaller. </ins> assert!(!t.is_simd()); <del> let repr = adt::represent_type(ccx, t); let sizing_type = adt::sizing_type_of(ccx, &repr, true); debug!("DST {} sizing_type: {:?}", t, sizing_type); let sized_size = llsize_of_alloc(ccx, sizing_type); let sized_align = llalign_of_min(ccx, sizing_type); </del> <ins> let layout = ccx.layout_of(t); debug!("DST {} layout: {:?}", t, layout); let (sized_size, sized_align) = match *layout { ty::layout::Layout::Univariant { ref variant, .. } => { (variant.min_size().bytes(), variant.align.abi()) } _ => { bug!("size_and_align_of_dst: expcted Univariant for `{}`, found {:#?}", t, layout); } }; </ins> debug!("DST {} statically sized prefix size: {} align: {}", t, sized_size, sized_align); let sized_size = C_uint(ccx, sized_size);

Discussion:
On stable, beta, and nightly, the follow code prints followed by : CC
This is probably for drop flags, in which case it should get fixed by
Reduced:
where would there be a drop flag here?
My point isn't that there is, but that the code assumes all trait objects have drop flags. I could be wrong though, it might be a bug in the alignment logic.
Not fixed by , will have to investigate further.
Uhhhh, the computation starts with: Which is completely wrong, because you want no trailing padding, i.e. should be . EDIT: getting a field pointer might also be broken, needs looking into. EDIT2: to handle the "minimum size" needed to compute the field offset, so that works.
Change:
} mis.iter().fold(true, |res, mi| { <del> let mut mi = mi.meta_item().unwrap().clone(); </del> <ins> let Some(mut mi) = mi.meta_item().cloned() else { dcx.emit_err(session_diagnostics::CfgPredicateIdentifier { span: mi.span(), }); return false; }; </ins> if let [seg, ..] = &mut mi.path.segments[..] { seg.ident.name = Symbol::intern(&format!("target_{}", seg.ident.name)); }

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'called on a value'', 'thread 'rustc' panicked at 'called on a value'' 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<!-- query stack: [resolverforlowering_raw] getting the resolver for lowering --
mvce
bisects to cc ^^'
Change:
<ins> trait T0<'a, A> { type O; } struct L<T> { f: T, } // explicitly named variants of what one would normally denote by the // unit type `()`. Why do this? So that we can differentiate them in // the diagnostic output. struct Unit1; struct Unit2; struct Unit3; struct Unit4; impl<'a, A, T> T0<'a, A> for L<T> where T: FnMut(A) -> Unit3, { type O = T::Output; } trait T1: for<'r> Ty<'r> { fn m<'a, B: Ty<'a>, F>(&self, f: F) -> Unit1 where F: for<'r> T0<'r, (<Self as Ty<'r>>::V,), O = <B as Ty<'r>>::V>, { unimplemented!(); } } trait Ty<'a> { type V; } fn main() { let v = Unit2.m( //~^ ERROR type mismatch //~| ERROR type mismatch L { f : |x| { drop(x); Unit4 } }); } impl<'a> Ty<'a> for Unit2 { type V = &'a u8; } impl T1 for Unit2 {} </ins>

Discussion:
The following code results in an ICE on stable, beta, and nightly () Errors:
thanks to for providing a ICE appears to have been injected between 1.32.0 and 1.33.0. We could obviously use further bisection.
triage: P-high, removing nomination, marking needs-bisect, and assigning to self.
ICE was injected between nightly-2019-01-03 ( 2019-01-02) and nightly-2019-01-04 ( 2019-01-03). We did not have many PR's merged in that time frame, just these: Based on past experience, I'm guessing this is due to the Universes PR .
I'm going to take a shot at just turning the current call into a and see where that gets us.
Change:
|     ^^^^^^^^^ `str` cannot be mutably indexed by `usize` | = help: the trait `std::ops::IndexMut<usize>` is not implemented for `str` <ins> = note: you can use `.chars().nth()` or `.bytes().nth()` see chapter in The Book <https://doc.rust-lang.org/book/ch08-02-strings.html#indexing-into-strings> </ins> error: aborting due to 3 previous errors

Discussion:
The following buggy code: produces the error: This is usefully documented in TRPL (ch08-02-strings), but that is not easily discoverable from the error. Meanwhile, the error itself is a natural one that programmers from many languages (C, C++, etc) might run into. Speaking as someone who spent some time assuming that the issue was related to slices/references/usize (i.e. various new, Rust-specific concepts), not strings and UTF-8 encoding, I wonder whether a special case might be produced, replacing error E0277, when the types involved are specifically strings/strs and integers. :
We should add a pointing to in the following code of E0277 errors. The example has a similar case to this one, but the additional code should be something along the lines of This will cause an extra to be displayed for this case. Beyond changing the code, you will also need to add a new test case with the repro case above and (running and possibly updating the test comments for any remaining failing tests).
I would like to work on this.
do not hesitate to reach out either here or on if you need help!
Possible proposed output from :
Change:
suggest_to_change_suffix_or_into(err, is_fallible); true } <del> (&ty::Int(_), &ty::Uint(_)) | (&ty::Uint(_), &ty::Int(_)) => { </del> <ins> (&ty::Int(exp), &ty::Uint(found)) => { let is_fallible = match (exp.bit_width(), found.bit_width()) { (Some(exp), Some(found)) if found < exp => false, (None, Some(8)) => false, _ => true, }; suggest_to_change_suffix_or_into(err, is_fallible); true } (&ty::Uint(_), &ty::Int(_)) => { </ins> suggest_to_change_suffix_or_into(err, true); true }

Discussion:
() Errors: I would’ve expected something like: Edit: What actually should happen is the same as currently already with , i.e. it would look like modify labels: A-diagnostics, T-compiler, D-papercut, C-enhancement, E-easy <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Okay, lots of cases that already work got me confused into thinking this was fixed in nightly for a moment. What currently already works is the hint about converting where < where < What currently suggest even though works where < where ≤16 where ≤16
I reported a similar issue not long ago. Maybe it would be more robust and also more general to rewrite this suggestion code to actually look for the impl in question instead of having just a hard-coded list?
claim
I've created a PR augmenting the existing code to change the suggestions for the cases listed. However, I would like to explore the approach suggested(perhaps as part of a separate PR?). Any advice on how I could get the code to look for the impl so it can make the appropriate suggestion? Is the crate the right place to be looking at for this?
Yeah. I believe you'll need to create an and and then call , but there might be other/better ways to do this. You might want to ask for advice on Zulip.
Change:
} } <del> fn doc_meta( attrs: ~[ast::attribute] ) -> Option<@ast::meta_item> { /*! * Given a vec of attributes, extract the meta_items contained in the  * doc attribute */ let doc_metas = doc_metas(attrs); if vec::is_not_empty(doc_metas) { if vec::len(doc_metas) != 1u { warn!("ignoring %u doc attributes", vec::len(doc_metas) - 1u); } Some(doc_metas[0]) } else { None } } </del> fn doc_metas( attrs: ~[ast::attribute] ) -> ~[@ast::meta_item] {

Discussion:
If document strings for rustdoc are written as a sequence of single line comments (i.e. ///) then rustdoc only uses the first line. The whole sequence should be joined to form a single attribute for further processing.
I would be happy to have a look at this (I guess maybe I caused the issue).
It seems like one way to fix this issue would be to have rustdoc concatenate all doc-attributes/doc-comments for an item and use the concatenated text as if it were from a single doc-attribute/comment. Currently rustdoc discards all but the first doc-attribute, and emits a warning that the others were discarded. However the warning is emitted using warn!(...) which means it doesn't actually display to the user unless they have turned on warn logging for rustdoc, which seems unlikely. Would this approach (concatenating all doc-comments) be ok?
Another approach would be to change the lexer so that it parses multiple adjacent lines that all start with /// as a single doc-comment.
Having rustdoc concatenate the attributes sounds good to me.
You're right, I ran rustdoc without warnings being logged. Are you referring to fn docmeta in That looks like it would be a sensible place to do the concatenation.
Yup. See the pull request - it makes multi-line comments work the same as comments (as a side effect of concatenating all kinds of doc-comment). Unfortunately multi-line comments seem a bit broken in general with rustdoc. In html output mode they are concatenated into a single line (I think due to some weirdness with pandoc).
Fixed by
Change:
} }); <del> let Some((test_name, _)) = test.to_str().map(|s| s.split_once('.')).flatten() else { </del> <ins> let Some(test_name) = test.file_stem().map(OsStr::to_str).flatten() else { </ins> continue; }; <ins> assert!( !test_name.contains('.'), "test name cannot contain dots '.': `{}`", test.display() ); </ins> test_info.insert(test_name.to_string(), (test, expected_revisions)); }

Discussion:
Running on my checkout with the current master commit fails with tons of errors. here's the last few screens of messages:
Is the check looking for in the full path? My rustc checkout is in a directory called (it's my 2nd of 3 checkouts), and I suspect tidy gets confused by that.
It does CC
That code should probably use .
Oops, I will try to fix this ASAP
Submitted a fix for this at .
Change:
fn consume(&mut self, _n: usize) {} } <ins> #[stable(feature = "empty_seek", since = "1.51.0")] impl Seek for Empty { fn seek(&mut self, _pos: SeekFrom) -> io::Result<u64> { Ok(0) } fn stream_len(&mut self) -> io::Result<u64> { Ok(0) } fn stream_position(&mut self) -> io::Result<u64> { Ok(0) } } </ins> #[stable(feature = "std_debug", since = "1.16.0")] impl fmt::Debug for Empty { fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {

Discussion:
You can create an empty io-reader with , which returns an . That doesn't implement the trait. However, I don't see any reason why it shouldn't.
I don't understand how a reader which is always at EOF should be seekable. Can you please explain more about it?
You can think of a reader which is always at EOF as a reader which is always at position 0 with a stream end of position 0. I don't think there is any disadvantage of having implemented for . It allows it to be passed to more generic code.
Did you hit a case where you actually wanted to do this?
In is discussing ways to implement a 307/308 HTTP redirect. Those two codes (in contrast to 301/302/303) require the payload to be sent after the redirect. However, parts of the payload may already have been sent to the server, before the server responds with the redirect. With a generic API taking an as Payload, it's not possible to seek back to the beginning. Thus, one suggestion is to use instead. To allow an empty body (e.g. for a GET request), it would be nice to keep using . While will probably decide to follow a different way for those redirects, I still think this pattern makes sense to support.
Change:
LL | struct X(Y); |          ^ move occurs because `self.0` has type `Y`, which does not implement the `Copy` trait | <ins> = note: `#[derive(Debug)]` triggers a move because taking references to the fields of a packed struct is undefined behaviour </ins> = note: this error originates in the derive macro `Debug` (in Nightly builds, run with -Z macro-backtrace for more info) error: aborting due to previous error; 2 warnings emitted

Discussion:
The following code causes a compilation error. : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This is intended, it is an attempt to make derives and work in more cases. The derive cannot know whether the field is copy. It cannot take a reference to the field, since it's not aligned. So it tries to copy, which at least works for types.
Should, or can this be fixed?
It cannot. repr(packed) sucks.
Atleast, we should modify the error message to make it clearer? Something like error[E0507]: cannot move out of which is behind a shared reference -- | 3 | #[derive(Debug)] | ----- in this derive macro expansion 4 | struct B(String); | ^^^^^^ move occurs because has type , which does not implement the trait | = note: this error originates in the derive macro (in Nightly builds, run with -Z macro-backtrace for more info) = note: this struct is marked as , but unaligned field references are undefined behaviour. For more information about this error, try .
that's possible.
claim
I'll let others implement the diagnostic message.
Change:
<ins> // check-pass // edition: 2021 #![feature(c_str_literals)] // aux-build: print-tokens.rs extern crate print_tokens; fn main() { print_tokens::print_tokens! { 1 17u8 42. 3.14f32 b'a' b'xFF' 'c' 'x32' ""str"" r#""raw" str"# r###"very ##"raw"## str"### b""byte" str" br#""raw" "byte" str"# c""c" str" cr#""raw" "c" str"# } } </ins>

Discussion:
Current output as of nightly-2023-06-20: The correct output would have . The ToString of procmacro::Literal is the only interface by which proc macros are able to inspect literals. It is supposed to include the entire literal, with quotes and escape sequences and everything as originally appear in the source code. Without this, it is impossible for proc macros to operate correctly on literals. For example, it would currently be impossible for a proc macro to tell the difference between and , but those are not the same token. Mentioning tracking issue: Mentioning since you have worked on this feature in the past. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
Does resolve this or is there more?
Not fixed as of rustc 1.73.0-nightly ( 2023-08-02).