jiebi/CodeConvo huggingface dataset:
Change:
i += 1; } // like the first, a last line of all stars should be omitted <del> if j > i && lines[j - 1].chars().skip(1).all(|c| c == '*') { </del> <ins> if j > i && !lines[j - 1].is_empty() && lines[j - 1].chars().all(|c| c == '*') { </ins> j -= 1; }

Discussion:
When using to insert another file as a docstring, it seems that the last line gets cut off if it contains only one character. : : (Both files have a trailing new line.) : Running on the above produces output like this: That is, the file gets included correctly, but the file loses its second line. This bug only seems to happen if the last line is a single character. Reproduced this bug on both stable and nightly. : :
does this also happen for string constants and other things using ? Or just the doc attribute?
Oh I didn't think to check that. Looks like the bug doesn't reproduce with a non- use of . This runs without error:
Ok cool and follow-up question - does have the same issue? Or only with include_str?
That does reproduce the issue. The rustdoc output looks like .
cc this is probably related to your changes to try and make the indentation smarter.
You mean removing the smart indent? ;) But yes, very likely. I'll take a look.
Change:
<ins> // compile-flags: -C no-prepopulate-passes #![crate_type = "staticlib"] // CHECK: define void @a() #[no_mangle] #[inline] pub extern "C" fn a() {} // CHECK: define void @b() #[export_name = "b"] #[inline] pub extern "C" fn b() {} // CHECK: define void @c() #[no_mangle] #[inline] extern "C" fn c() {} // CHECK: define void @d() #[export_name = "d"] #[inline] extern "C" fn d() {} // CHECK: define void @e() #[no_mangle] #[inline(always)] pub extern "C" fn e() {} // CHECK: define void @f() #[export_name = "f"] #[inline(always)] pub extern "C" fn f() {} // CHECK: define void @g() #[no_mangle] #[inline(always)] extern "C" fn g() {} // CHECK: define void @h() #[export_name = "h"] #[inline(always)] extern "C" fn h() {} </ins>

Discussion:
Code: If the function is marked as , it doesn't get compiled into the dll file: The reason a function may be marked as both and is so that it gets inlined when compiling the crate as a rust library, but not inlined when compiling the crate as a cdylib. There should be a warning to use something like instead. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Related to - I think is that we should include 'd functions in s and s, but as a short term solution, a warning is a nice idea
claim

I currently use Rust to generate a static library for FFI consumption. In some public interfaces, I call other FFI public interfaces as primarily a wrapper with a few tweaks. I'd like to mark these "inner" functions as inline, however, this seems to cause them to not show up in the final staticlib. Given this drastically simplified example: The function makes it to the static library, but the function does not: If I remove the attribute, we see both functions in the static lib: The don't seem to hint that can prevent / items from surviving all the way to the final library, or that they shouldn't be used together. I would expect any function marked and/or should be present in the final artifact, regardless of attributes. I see this behavior on stable, as well as a recent nightly. I don't know if this is a regression, as this is the first time I've run into this. Thanks! Edit: Simplified profile settings, they are not needed to reproduce. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Tried with = same result
I’ve noticed this for a while but I always assumed it was intended... It would be really nice if this was fixed
This appears to have been done deliberately: Maybe it shouldn't apply to s.
Expanding on note, I would also expect this not to apply to s as well (I used the staticlib for my example, but my use case generates code for both static and dynamic library usage).
I think I'm going to take this on claim
Change:
<ins> fn foo() { //~^ HELP try adding a return type |x: &i32| 1i32 //~^ ERROR mismatched types } fn bar(i: impl Sized) { //~^ HELP a return type might be missing here || i //~^ ERROR mismatched types } fn main() {} </ins>

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should suggest how to specify the return type when a function returns a closure. <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. 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. The output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Is some thing like this not ok ?
release-assignment
It's ok but I was wondering if it's possible to make the compiler give some form of a suggestion to the user on how to do this. Cause the current diagnostics does not suggest how to fix it.
Change:
&mut self, constant: &mir::Constant<'tcx>, ) -> Result<ConstValue<'tcx>, ErrorHandled> { <del> match constant.literal.val { ty::ConstKind::Unevaluated(def_id, substs, promoted) => { let substs = self.monomorphize(&substs); self.cx .tcx() .const_eval_resolve(ty::ParamEnv::reveal_all(), def_id, substs, promoted, None) .map_err(|err| { if promoted.is_none() { self.cx .tcx() .sess .span_err(constant.span, "erroneous constant encountered"); } err }) } </del> <ins> match self.monomorphize(&constant.literal).val { ty::ConstKind::Unevaluated(def_id, substs, promoted) => self .cx .tcx() .const_eval_resolve(ty::ParamEnv::reveal_all(), def_id, substs, promoted, None) .map_err(|err| { if promoted.is_none() { self.cx .tcx() .sess .span_err(constant.span, "erroneous constant encountered"); } err }), </ins> ty::ConstKind::Value(value) => Ok(value), <del> _ => { let const_ = self.monomorphize(&constant.literal); if let ty::ConstKind::Value(value) = const_.val { Ok(value) } else { span_bug!(constant.span, "encountered bad ConstKind in codegen: {:?}", const_); } } </del> <ins> err => span_bug!( constant.span, "encountered bad ConstKind after monomorphizing: {:?}", err ), </ins> } }

Discussion:
: <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Got same error with: It seems unrelated to the type of the const
claim
Reduced: Looks like a normalization failure to me, but that shouldn't happen for .
So I found the bug, is just outright missing : <hr/But also, it's worrying that an equivalent to this is missing for consts (even if it's not relevant here):
For the record, what I described above () isn't fixed, just worked around. EDIT: opened .
Change:
opaque_hir_id: hir::HirId, ) -> bool { let mut hir_id = tcx.hir().as_local_hir_id(def_id).unwrap(); <del> trace!( "may_define_existential_type(def={:?}, opaque_node={:?})", tcx.hir().get(hir_id), tcx.hir().get(opaque_hir_id) ); </del> // Named existential types can be defined by any siblings or children of siblings. let scope = tcx.hir().get_defining_scope(opaque_hir_id).expect("could not get defining scope");

Discussion:
Mentioning the existential types tracking issue Mentioning and
O_o I don't think I considered closures at all. Should closures be defining uses? Or just uses (and thus only be able to return that type by calling a function that defines the existential)?
As a motivating use case, existential types defined by a closure are required if we want to extend to support referring to local variables.
Yeah, any in-scope use (including in a binding) can be a defining use.
A binding like this? It looks like this is not currently picked up. It is why I had to write rather than simply in my previous comment.
Yeah, the RFC specifies that that should work.
I chose a simpler logic: any in scope use must be a defining use.
We've moved from segmentation faults to an ICE:
Change:
pprust_hir::AnnNode::Name(_) => {}, pprust_hir::AnnNode::Item(item) => { s.s.space(); <del> s.synth_comment(format!("hir_id: {} hir local_id: {}", item.hir_id, item.hir_id.local_id.as_u32())) </del> <ins> s.synth_comment(format!("hir_id: {}", item.hir_id)); </ins> } pprust_hir::AnnNode::SubItem(id) => { s.s.space(); <del> s.synth_comment(id.to_string()) </del> <ins> s.synth_comment(id.to_string()); </ins> } pprust_hir::AnnNode::Block(blk) => { s.s.space(); <del> s.synth_comment(format!("block hir_id: {} hir local_id: {}", blk.hir_id, blk.hir_id.local_id.as_u32())) </del> <ins> s.synth_comment(format!("block hir_id: {}", blk.hir_id)); </ins> } pprust_hir::AnnNode::Expr(expr) => { s.s.space(); <del> s.synth_comment(format!("expr hir_id: {} hir local_id: {}", expr.hir_id, expr.hir_id.local_id.as_u32())); s.pclose() </del> <ins> s.synth_comment(format!("expr hir_id: {}", expr.hir_id)); s.pclose(); </ins> } pprust_hir::AnnNode::Pat(pat) => { s.s.space(); <del> s.synth_comment(format!("pat hir_id: {} hir local_id: {}", pat.hir_id, pat.hir_id.local_id.as_u32())) </del> <ins> s.synth_comment(format!("pat hir_id: {}", pat.hir_id)); } pprust_hir::AnnNode::Arm(arm) => { s.s.space(); s.synth_comment(format!("arm hir_id: {}", arm.hir_id)); </ins> } } }

Discussion:
ICE with the borrow checker on nightly. Tried on stable/beta and it correctly errors with in nightly, I get : Backtrace:
Reduced: cc
Bisected this one to and , that is, PR . cc
Change:
trait T2 {} trait Foo { <del> type A: T1; </del> <ins> type A: T1; //~ NOTE: ambiguous `A` from `Foo` </ins> } trait Bar : Foo { <del> type A: T2; </del> <ins> type A: T2; //~ NOTE: ambiguous `A` from `Bar` </ins> fn do_something() { let _: Self::A; //~^ ERROR E0221 //~| NOTE ambiguous associated type `A` <del> //~| NOTE associated type `Self` could derive from `Foo` //~| NOTE associated type `Self` could derive from `Bar` </del> <ins> } } trait T3 {} trait My : std::str::FromStr { type Err: T3; //~ NOTE: ambiguous `Err` from `My` fn test() { let _: Self::Err; //~^ ERROR E0221 //~| NOTE ambiguous associated type `Err` //~| NOTE associated type `Self` could derive from `std::str::FromStr` </ins> } }

Discussion:
Currently, E0221 can give an error like: This isn't terribly helpful. Ideally, we'd like to show where these associated types that cause ambiguity are coming from: cc
I'd be up to mentor this. The message is reported by some code in , which has the job of converting the HIR representation of a type into the compiler's internal representation. The challenge here is that the HIR types have spans (because they are basically the things that the user wrote) whereas the internal representations do not. Right now, the routine in question, , only has access to a list of the representations in internal form (. To give better spans, we have to trace those spans in (so e.g. we want ). What this routine does is, given a type like , it selects what traits the associated type might have been defined in, and tries to pick one. The list is the list of traits that implements. So e.g. it might include something like , which would suggest that could be expanded to . But if there was another bound, say , that also defines an associated type , that'd be an amiguity. If you look at the callers, there aren't that many (3, I think). Two of those are for trait objects, I think, where the bounds come from the supertraits of the trait object. Probably we could give those the spans of the trait type itself, though we may want to get the spans out of the trait definition where the supertraits come from (but that could be in another crate). That last part is a bit tricky because we'd have to extend the . Let's assume we're not doing that for now, and we're willing to give a span referring to a trait when in fact the item lies in a supertrait where . The other is the more general case of a type parameter. I think the major piece of work then is to augment this routine in the trait: so that it returns a , where we would thread through the spans whence each bound was derived. Anyway, this is non-trivial, but seems to me to be achievable if anyone wants to dig in. If so, ping me (either on IRC, , or here) and I'll try to give more hints.

:)
I'll try, I need some time to look around
gettypeparameterbounds in callerbounds contains vec of Predicate w/o spans. May be is it easy only for error case in oneboundforassociatedtype get spans from astmap (hir::map) by DefId extracted from TypeTraitItems like traitdefinesassociatedtype_named do?
I've updated it But what do you think about trait from extern crate?
Change:
<ins> //! [`long_cat`] is really long </ins>

Discussion:
: : I expected to see this happen: completes successfully with a "unresolved link to " warning Instead, this happened: <!-- 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<summaryBacktrace</summary<p</p</details
I bet the source span is wrong somehow.
The issue is that the documentation on the re-export is being combined with the original documentation. splits it up by the module it's scoped to, which is different for the two doc-comments; if you remove it works fine. needs to only pass the documentation for the current scope to , not the combined docs. Not sure why it needs a separate file.
The markdown range it comes up with is 3..13. Hmm, this is weird - I think this is actually the correct span because they both come from , which doesn't care about scoping and just works on strings. Maybe it is a bug in after all?
Aha, here we go: is trying to look at the rustc snippet instead of the text it was provided. Maybe it could just work with instead?
Hmm, there are some other bugs here too: normally rustdoc will resolve docs in the scope inside the module and to the scope of the parent. But since there are inner docs, it will resolve all of the links inside the module. I think the fix for both the issues is to separate outer docs from inner ones; not yet sure how to do that.
To add another test-case for what I believe is another instance of the same problem: This doesn't panic, but produces: For an even more confused case, split the module into its own file: Which yields this nonsensical warning: Essentially, the span of the unresolved link is misattributed to the wrong file. The line and column values are correct, it's just the wrong file that's used.
That's is assuming there is only inner or outer docs, not both.
Change:
let hashes = get_hashes_str(n); f(&["br", hashes, """, symbol, """, hashes, suffix]) } <del> _ => f(&[symbol, suffix]), </del> <ins> bridge::LitKind::CStr => f(&["c"", symbol, """, suffix]), bridge::LitKind::CStrRaw(n) => { let hashes = get_hashes_str(n); f(&["cr", hashes, """, symbol, """, hashes, suffix]) } bridge::LitKind::Integer | bridge::LitKind::Float | bridge::LitKind::Err => { f(&[symbol, suffix]) } </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).
Change:
// required. #[cfg(stage1)] #[cfg(stage2)] <ins> #[cfg(stage3)] </ins> pub impl<T: Owned> Chan<T> { fn send(&self, x: T) { chan_send(self, x) } fn try_send(&self, x: T) -> bool { chan_try_send(self, x) }

Discussion:
Kind of annoying to not have this imported by default.
Would it be an option to implement WriterUtils functionality as default methods on Writer? A similar situation exists with ReaderUtil too.
yes, that is a good use case for default methods, but they don't work yet.
Change:
f(MatchCheckCtxt { tcx, <ins> param_env, </ins> module, pattern_arena: &pattern_arena, byte_array_map: FxHashMap::default(), }) } <del> // convert a byte-string pattern to a list of u8 patterns. fn lower_byte_str_pattern<'p>(&mut self, pat: &'p Pattern<'tcx>) -> Vec<&'p Pattern<'tcx>> where 'a: 'p { let pattern_arena = &*self.pattern_arena; let tcx = self.tcx; self.byte_array_map.entry(pat).or_insert_with(|| { match pat.kind { box PatternKind::Constant { value: const_val } => { if let Some(ptr) = const_val.to_ptr() { let is_array_ptr = const_val.ty .builtin_deref(true) .and_then(|t| t.ty.builtin_index()) .map_or(false, |t| t == tcx.types.u8); assert!(is_array_ptr); let alloc = tcx.alloc_map.lock().unwrap_memory(ptr.alloc_id); assert_eq!(ptr.offset.bytes(), 0); // FIXME: check length alloc.bytes.iter().map(|b| { &*pattern_arena.alloc(Pattern { ty: tcx.types.u8, span: pat.span, kind: box PatternKind::Constant { value: ty::Const::from_bits( tcx, *b as u128, ty::ParamEnv::empty().and(tcx.types.u8)) } }) }).collect() } else { bug!("not a byte str: {:?}", const_val) } } _ => span_bug!(pat.span, "unexpected byte array pattern {:?}", pat) } }).clone() } </del> fn is_uninhabited(&self, ty: Ty<'tcx>) -> bool { if self.tcx.features().exhaustive_patterns { self.tcx.is_ty_uninhabited_from(self.module, ty)

Discussion:
Attempting to pattern match a slice with a constant value and THEN a slice literal causes an ICE. Simple test case: However simply changing the order to test the slice literal and then the const slice compiles fine: Error message: rustc version:
So... I do have a fix for byte slices, but that just exposed that we have the same ICE for other slices: This can be fixed, too, but I need to wait for to be merged before being able to do this in a reasonable way.
Change:
*self } } <ins> // Begin of ARM32 shim // The raw content of this file should be processed by `generate-windows-sys` // to be merged with the generated binding. It is not supposed to be used as // a normal Rust module. cfg_if::cfg_if! { if #[cfg(target_arch = "arm")] { #[repr(C)] pub struct WSADATA { pub wVersion: u16, pub wHighVersion: u16, pub szDescription: [u8; 257], pub szSystemStatus: [u8; 129], pub iMaxSockets: u16, pub iMaxUdpDg: u16, pub lpVendorInfo: PSTR, } pub enum CONTEXT {} } } // End of ARM32 shim </ins>

Discussion:
In the WinAPI definitions have been replaced by windows-bindgen generated bindings. However, the project does not generate metadata for ARM32-specific items, hence the generated bindings lack a few types like and on this platform. It effectively breaks for Rust.
Unfortunately, 32-bit ARM is not being supported by Microsoft going forward. What we could do is insert our own definitions in , copied from before the changes.
Besides the issue with ARM, all UWP targets actually have problems with linkage as well. Previously the APIs forbidden on UWP are gated behind fine-grained conditional compilation flags, but it is no longer the case with generated ones. I got this when building the UWP app that links again a Rust staticlib. !
Iirc, the functions were never gated. But we loaded them lazily (and panicked if they didn't load). This did allow UWP targets to compile. No idea if they actually ran. I'm not sure who's responsible for these targets.
I think you are correct. I can reproduce the link errors with toolchain . Let me file another issue after I pinpoint the underlying problem.
Oh wait, as staticlib? You currently need to make sure to link all the libraries it depends on. You can get them using .
This will fail Windows App Cert Kit tests. !
In that case I'm surprised that lazy loading worked.
WG-prioritization assigning priority (). label -I-prioritize +P-low
Change:
/// necessarily) at _exactly_ `MAX_REFCOUNT + 1` references. const MAX_REFCOUNT: usize = (isize::MAX) as usize; <ins> #[cfg(not(sanitize = "thread"))] macro_rules! acquire { ($x:expr) => { atomic::fence(Acquire) }; } // ThreadSanitizer does not support memory fences. To avoid false positive // reports in Arc / Weak implementation use atomic loads for synchronization // instead. #[cfg(sanitize = "thread")] macro_rules! acquire { ($x:expr) => { $x.load(Acquire) }; } </ins> /// A thread-safe reference-counting pointer. 'Arc' stands for 'Atomically /// Reference Counted'. ///

Discussion:
iff the crate contains two or more unit tests. TODO Sanitizers are not yet in tree. (cf. ) cc
Like with I'd be tempted to say these are false positives, but these stack traces don't look so familiar so I'm not certain of that
This will be a false positive because drop_slow uses a fence, and tsan doesn't work with fences.
So I take it this isn't actually a problem since we're just using a fence and tsan doesn't support that? Should we close?
Can the false-positive be worked-around by manually annotating the happens-before relationship? See
Well, maybe if we could conditionally build without the fence (rework to use a load/store instead) when tsan is enabled then the error wouldn't be seen.