jiebi/CodeConvo huggingface dataset:
Code change:
<del> Subproject commit 5399a24c66cb6164cf32280e7d300488c90d5765 </del> <ins> Subproject commit b31c30a9bb4dbbd13c359d0e2bea7f65d20adf3f </ins>

Related discussion:
text: Running the miscompiled binary in gdb (with ) gives:
Yeah, that would crash...
I think this is a minimal reproducer: We infer that the result of this function is nonnull...
Upstream issue:
WG-prioritization assigning priority (). label -I-prioritize +P-high
Code change:
<ins> #![feature(unboxed_closures)] #![feature(fn_traits)] fn main() { let handlers: Option<Box<dyn for<'a> FnMut<&'a mut (), Output=()>>> = None; handlers.unwrap().as_mut().call_mut(&mut ()); //~ ERROR: `&mut ()` is not a tuple } </ins>

Related discussion:
text: Reduced example
e
The first compilation error -- the example with looks fine to me. Types used for static variables must outlive the lifetime. The compiler can prove that outlives only if . Hence lifetimes are inferred in lieu of the anonymous lifetimes. Since your variable does not live for the whole lifetime, it cannot be used as you are trying to. Maybe the actual bug is that should desugar to , as it would be for ? It may be weird to special-case only the traits though -- i.e. if you define your own trait , then just means for some lifetime to be inferred by the compiler, it does not mean . Your reduced example is actually different since it actually does not involve static data. It seems to be the same bug as in , and hence is a bug with the feature. Going from to (note the tuple of size ) makes the ICE go away.
Fixed by
Code change:
#[cfg(test)] mod tests; <ins> #[doc(no_inline)] </ins> pub use hir::*; pub use hir_id::*; pub use lang_items::{LangItem, LanguageItems};

Related discussion:
text: We have some relative links in doc, e.g., the link of in the comments for : but we will get the page if we click it in , which is re-exported. So I think we can fix this by two ways: 't use relative path in rustc doc 't generate new link for re-exported items, use the same links with the original definition but for the second option, we may have private middle mods, so it may be not a solution. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc
I'm thinking of tackling this issue, is this Issue aimed at removing this invalid path once and for all? (Sorry if I'm wrong as I'm trying to contribute for the first time)
claim
Hi just checking if you are still working on the issue? If so, apologies please ignore this. Otherwise I'm happy to take over. Thanks
take it
Code change:
src = t!(fs::canonicalize(src)); } else { let link = t!(fs::read_link(src)); <del> t!(self.symlink_file(link, dst)); </del> <ins> t!(self.config.symlink_file(link, dst)); </ins> return; } }

Related discussion:
text: broke the rust-analyzer config we suggest in the dev-guide: https://rustc-dev- since now rustfmt is in instead of . Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
Hi! Just to clarify, the idea is to change to code to match the docs?
I think the idea is changing the docs to match the new behavior.
For reference:
I'd prefer to change the code so that we don't force all contributors to update their config.
I don't think we can put the binary back, or at least, that feels iffy - we'd be trying to overlap two different sysroots. rustfmt used to be statically linked to libstd and librustc_driver, but that's no longer the case.
I suppose we could try to create a symlink from the old path to the new one? That might work, not sure.
Maybe add a proxy? On Linux it might just be
A symlink seems like a good solution to me.
Does the symlink still finds the correct so?
try it and see
I'll experiment adding a symlink.
On Windows, creating a symlink does not find the needed DLLs. Trying to execute the symlink pops two msgbox saying that it doesn't find the and DLLs. You would need to symlink also the DLLs. On Linux, it does find the correct SOs.
Symlinking also works on macOS.
Ok, this is pretty messy. How about doing both: Add the symlink, which will work with both the old and new config on Mac and Linux Update the recommended config in the dev-guide, which will help contributors fix the error message on Windows and from there we can work long-term to using the same toolchain for rustfmt and other tools, without having a time pressure.
cc ,
May I get some guidance and the creation of the symlink? Do I use rust to create the symlink in after the rustfmt_path line or do I use a bash command? If I do use a bash command, is there a file I should be adding it to? Thank you!
use
And just to confirm, I use that symlink function here?
Code change:
src = t!(fs::canonicalize(src)); } else { let link = t!(fs::read_link(src)); <del> t!(self.symlink_file(link, dst)); </del> <ins> t!(self.config.symlink_file(link, dst)); </ins> return; } }

Related discussion:
text: yes
I think it would be possible to move rustfmt back to the same sysroot as the bootstrap compiler by only taking , and from the nightly rustc component and not copying any other files like the rustc binary. and both contain a hash in their name unique for each rustc version. should contain the rustc version, so that shouldn't conflict either.
Doing the same with the DLLs on Windows could also work.
related (different error with rustfmt, but caused by the same change):
Hi any progress on the symlink? happy to help out if you're running into trouble :)
Hey ! Thanks for reaching out! I'll be starting tomorrow and will reach out to you if/when I need help! Apologies for the delay!
Code change:
<ins> // Regression test for #100143 use std::iter::Peekable; pub struct Span<F: Fn(&i32)> { inner: Peekable<ConditionalIterator<F>>, } pub struct ConditionalIterator<F> { f: F, } // @has 'fn_bound/struct.ConditionalIterator.html' '//h3[@class="code-header in-band"]' 'impl<F: Fn(&i32)> Iterator for ConditionalIterator<F>' impl<F: Fn(&i32)> Iterator for ConditionalIterator<F> { type Item = (); fn next(&mut self) -> Option<Self::Item> { todo!() } } </ins>

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:
// Types of fields (other than the last) in a struct must be sized. FieldSized, <ins> // Only Sized types can be made into objects ObjectSized, </ins> } pub type Obligations<'tcx> = subst::VecPerParamSpace<Obligation<'tcx>>;

Related discussion:
text: cc
cc too, presumably a consequence of the trait reform/new vtable lookup code
Hmm, yes. Probably we can fix this by just...allowing it to skolemize an open existential type. I just didn't expect this to ever happen.
actually, while debugging this I remembered that it is not possible to make an object out of an unsized type. We need to add a check for this I guess!
Explanation from PR: In the general case, at least, it is not possible to make an object out of an unsized type. This is because the object type would have to store the fat pointer information for the self value and the vtable -- meaning it'd have to be a fat pointer with three words -- but for the compiler to know that the object requires three words, it would have to know the self-type of the object (is self a thin or fat pointer?), which of course it doesn't.
Code change:
pub fn read_line(&self, buf: &mut String) -> io::Result<usize> { self.lock().read_line(buf) } <ins> // Locks this handle with any lifetime. This depends on the // implementation detail that the underlying `Mutex` is static. fn lock_any<'a>(&self) -> StdinLock<'a> { StdinLock { inner: self.inner.lock().unwrap_or_else(|e| e.into_inner()) } } /// Consumes this handle to the standard input stream, locking the /// shared global buffer associated with the stream and returning a /// readable guard. /// /// The lock is released when the returned guard goes out of scope. The /// returned guard also implements the [`Read`] and [`BufRead`] traits /// for accessing the underlying data. /// /// It is often simpler to directly get a locked handle using the /// [`stdin_locked`] function instead, unless nearby code also needs to /// use an unlocked handle. /// /// # Examples /// /// ```no_run /// #![feature(stdio_locked)] /// use std::io::{self, Read}; /// /// fn main() -> io::Result<()> { ///     let mut buffer = String::new(); ///     let mut handle = io::stdin().into_locked(); /// ///     handle.read_to_string(&mut buffer)?; ///     Ok(()) /// } /// ``` #[unstable(feature = "stdio_locked", issue = "none")] pub fn into_locked(self) -> StdinLock<'static> { self.lock_any() } </ins> } #[stable(feature = "std_debug", since = "1.16.0")]

Related discussion:
text: is declared as follows: Because there is only one input lifetime (the elided lifetime of ), it is assigned to the output lifetime , which is why the lock can live at most as long as the temporary.
Thanks. I think this might be a bug in libstd (using instead of as the return type), but I'll file that separately. What I think is a diagnostic inaccuracy is that the error message refers to a borrow, when, by inspection of the library source code, no borrow is taking place in . (Unless I'm missing something?) What I think is happening is that the compiler is enforcing that lives no longer than the temporary produced by , and is misleadingly calling that a borrow in the error message.
As a simplified example: The error message refers to a borrow even when the output type of does not refer to at all!
that's because of the elision rules: on the declaration you're implicitly telling the compiler that the lifetime of the borrow matches the lifetime of the type. .
Thanks. I think the error messages could use a little more detail about how something that the borrow checker sees as a borrow may be an artifact of lifetime constraints in a function signature rather than an actual borrow in the function body. It certainly surprised me the first time I ran into it. (Maybe only in the explanatory text in the compiler error index. It looks like E0597 could also benefit from that detail, because it's a similar case, and an example in E0716 produces E0597.)
Shorter example, probably better suited for an example in the compiler error index:
Code change:
<ins> error[E0310]: the associated type `<&'a V as IntoIterator>::Item` may not live long enough --> $DIR/issue-71546.rs:12:27 | LL |       let csv_str: String = value |  ___________________________^ LL | |         .into_iter() LL | |         .map(|elem| elem.to_string()) | |_____________________________________^ | = help: consider adding an explicit lifetime bound `<&'a V as IntoIterator>::Item: 'static`... = note: ...so that the type `<&'a V as IntoIterator>::Item` will meet its required lifetime bounds... note: ...that is required by this bound --> $DIR/issue-71546.rs:10:55 | LL |     for<'a> <&'a V as IntoIterator>::Item: ToString + 'static, |                                                       ^^^^^^^ error: aborting due to previous error For more information about this error, try `rustc --explain E0310`. </ins>

Related discussion:
text: Playground: UPDATE: MCVE is here: Code: Crashes compiler with
Would be nice to figure out if this is a regression or not and if it is when has this regressed. ping cleanup
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
It has been present since at least 2019-08-01 according to bisect-rustc
Simplified code to remove dependencies This compiles for 1.20.0 and not for 1.30.0 (setting edition to 2015) I'll try and pinpoint at least the version where it causes the ICE
From what I can tell the first time this ICE would happen is in 1.24.0
Assigning
Even simpler:
Triage: This ICE has been fixed in the latest nightly, I assume it's fixed by . Marking as .
Wait, the original code and still triggers the ICE... glacier was tracking with but it seems the others encounter another roadblock. Dropping .
No longer ICEs since , likely from
Code change:
#![feature(cfg_target_has_atomic)] #![feature(cfg_target_thread_local)] #![feature(char_error_internals)] <ins> #![feature(char_internals)] </ins> #![feature(clamp)] #![feature(concat_idents)] #![feature(const_cstr_unchecked)]

Related discussion:
text: The following program causes UB: Miri says: The problem is this code: This calls unless the new code point is in , but what about surrogates in ? This code is unchanged since its introduction in I am not sure what the intended safety contract of is. That method is not marked but clearly should be -- it calls . So my guess is the safety precondition is that must not be part of a surrogate pair, but the thing is, calls it without actually ensuring that condition. The condition it does ensure is that the codepoint is not in , but that does not help.
is excluded from Unicode scalar values a.k.a. , but it’s fine as a Unicode code point. I think this bug is not in the contract of (which is private anyway) but in its implementation, namely going through . The fix is to either duplicate the logic of into , or (to avoid duplication) move that logic to a new function in libcore that takes a parameter and that is called by both and . This function would need to be public because is in a different crate, but it should be prema-unstable and .
I would classify the priority of this bug as low. Although this call to is UB, I expect Miri checking for it explicitly is the only case where that has any consequence in today’s implementation: behaves as expected (for the purpose of WTF-8) in the surrogate range and does not exploit this UB The "layout" of in rustc excludes values beyond but not surrogates:
By the way, the docs at feel insufficient: Which values are invalid? Similarly, and say that represents Unicode Scalar values, but I couldn’t find it documented anywhere that constructing an out of range is Undefined Behavior rather than "merely" a logic bug. Is this specified elsewhere? What is the closest we have to a written down normative resource that specifies what is or isn’t UB in the the Rust language? (For APIs I assume this is the responsibility of their respective doc-comments.)
I agree the impact is low, but it's not just Miri -- this blocks , which is how I discovered the problem. That would be
But then what is "unchecked" about it? Elsewhere in that file the code is careful not to construct a from a without checking for surrogates: That made me assume the author was aware that surrogates in are UB.
Code change:
#![feature(cfg_target_has_atomic)] #![feature(cfg_target_thread_local)] #![feature(char_error_internals)] <ins> #![feature(char_internals)] </ins> #![feature(clamp)] #![feature(concat_idents)] #![feature(const_cstr_unchecked)]

Related discussion:
text: The type contains a (generalized-UTF-8-encoded) sequence of code point (including potentially surrogates) that doesn’t form a surrogate pair. doesn’t check for surrogate pairs. is a public method that is documented as returning a scalar value, therefore excluding all surrogates. Ok I looked into it, there are three different people involved. The original code in 2014 was YOLO Later in 2014, moved to duplicating logic instead. In 2015, PR which first imported WTF-8 support in libstd deduplicated that logic by adding a function that takes . (I knew that approach sounded familiar…) In 2016, PR changed the signature of and in passing removed . It made use + instead, presumably in the middle of updating many callers other.
Okay, so the fix would be to revert the part of that removed ?
That or copy into . I find them both not great, so meh.
Even with that done, there's still UB in another testcase: This is converting something to a before calling -- so probably the same issue as the above, just for a different encoding.
Code change:
), .. }) => { <del> let hir::Ty { span, .. } = inputs[local.index() - 1]; </del> <ins> let hir::Ty { span, .. } = *inputs.get(local.index() - 1)?; </ins> Some(span) } _ => None,

Related discussion:
text: <!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'index out of bounds: the len is 1 but the index is 1'', 'thread 'rustc' panicked at 'index out of bounds: the len is 1 but the index is 1'' 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: [mirborrowck] borrow-checking [analysis] running analysis passes on this crate --
cc
label +D-diagnostic-infra -needs-triage
Code change:
true } <ins> // Suggest to change `Option<&Vec<T>>::unwrap_or(&[])` to `Option::map_or(&[], |v| v)`. #[instrument(level = "trace", skip(self, err, provided_expr))] pub(crate) fn suggest_deref_unwrap_or( &self, err: &mut Diag<'_>, error_span: Span, callee_ty: Option<Ty<'tcx>>, call_ident: Option<Ident>, expected_ty: Ty<'tcx>, provided_ty: Ty<'tcx>, provided_expr: &Expr<'tcx>, is_method: bool, ) { if !is_method { return; } let Some(callee_ty) = callee_ty else { return; }; let ty::Adt(callee_adt, _) = callee_ty.peel_refs().kind() else { return; }; let adt_name = if self.tcx.is_diagnostic_item(sym::Option, callee_adt.did()) { "Option" } else if self.tcx.is_diagnostic_item(sym::Result, callee_adt.did()) { "Result" } else { return; }; let Some(call_ident) = call_ident else { return; }; if call_ident.name != sym::unwrap_or { return; } let ty::Ref(_, peeled, _mutability) = provided_ty.kind() else { return; }; // NOTE: Can we reuse `suggest_deref_or_ref`? // Create an dummy type `&[_]` so that both &[] and `&Vec<T>` can coerce to it. let dummy_ty = if let ty::Array(elem_ty, size) = peeled.kind() && let ty::Infer(_) = elem_ty.kind() && size.try_eval_target_usize(self.tcx, self.param_env) == Some(0) { let slice = Ty::new_slice(self.tcx, *elem_ty); Ty::new_imm_ref(self.tcx, self.tcx.lifetimes.re_static, slice) } else { provided_ty }; if !self.can_coerce(expected_ty, dummy_ty) { return; } let msg = format!("use `{adt_name}::map_or` to deref inner value of `{adt_name}`"); err.multipart_suggestion_verbose( msg, vec![ (call_ident.span, "map_or".to_owned()), (provided_expr.span.shrink_to_hi(), ", |v| v".to_owned()), ], Applicability::MachineApplicable, ); } </ins> /// Suggest wrapping the block in square brackets instead of curly braces /// in case the block was mistaken array syntax, e.g. `{ 1 }` -> `[ 1 ]`. pub(crate) fn suggest_block_to_brackets(

Related discussion:
text: Given : Current error, for the motivating use case above: It should be possible for rustc to suggest replacing this specific instantiation of with . Maybe similarly for some other common cases: . Originally posted by in label -T-rustdoc T-compiler
Code change:
/// ``` #[stable(feature = "rust1", since = "1.0.0")] pub fn lock(&self) -> StdinLock<'_> { <del> StdinLock { inner: self.inner.lock().unwrap_or_else(|e| e.into_inner()) } </del> <ins> self.lock_any() </ins> } /// Locks this handle and reads a line of input, appending it to the specified buffer.

Related discussion:
text: Given the following code: The current output is: I think it's typical for a newcomer to want to get a iterator by chaining method calls like . There's no obvious reason why that shouldn't work. The examples in the documentation do typically show being assigned to a variable prior to calling its method, but don't explain why that's necessary. I think the "borrow" terminology is misleading, but there might not be a concise way to describe what's actually going on to the user. The "temporary value is freed at the end of this statement" is probably correct. The "creates a temporary which is freed while still in use" is probably more correctly "creates a temporary that is required to outlive (or live exactly as long as) the result of...", followed by a pointer to the method invocation, with text of " method call". Maybe it should also point out the lifetime argument in the return type. I tried and failed to find a satisfactory explanation of what exactly was borrowing from the temporary value produced by . When I looked through the library source code, the only references in were those created by locking a , and the in question is static. I'm guessing the existence of a borrow is assumed rather than inferred from analyzing the function body of . The assumption might be the result of the anonymous lifetime argument on the output type from , which imposes a requirement that the doesn't outlive (or has the same lifetime as?) the value that is the receiver of . The correct fix might be to change the locked stdin handles to all use lifetimes, but I will probably file that as a separate issue.
label +A-borrow-checker +A-lifetimes +D-confusing +D-incorrect +D-newcomer-roadblock
IMO the intent is clear here. Without changing the API, why exactly is Rust unable to lift 'a &'static X to 'static & 'static X, if X also contains only 'static lifetimes? I don't think raw references have a meaningful dropper; borrowck is able to freely resolve any derived lifetimes on impls that don't depend on anything else to 'static; I'm pretty sure under current rules we should be able to substitute latter for earlier and get exactly the same behaviour.
This is due to .
Code change:
/// ``` #[stable(feature = "rust1", since = "1.0.0")] pub fn lock(&self) -> StdinLock<'_> { <del> StdinLock { inner: self.inner.lock().unwrap_or_else(|e| e.into_inner()) } </del> <ins> self.lock_any() </ins> } /// Locks this handle and reads a line of input, appending it to the specified buffer.

Related discussion:
text: is declared as follows: Because there is only one input lifetime (the elided lifetime of ), it is assigned to the output lifetime , which is why the lock can live at most as long as the temporary.
Thanks. I think this might be a bug in libstd (using instead of as the return type), but I'll file that separately. What I think is a diagnostic inaccuracy is that the error message refers to a borrow, when, by inspection of the library source code, no borrow is taking place in . (Unless I'm missing something?) What I think is happening is that the compiler is enforcing that lives no longer than the temporary produced by , and is misleadingly calling that a borrow in the error message.
As a simplified example: The error message refers to a borrow even when the output type of does not refer to at all!
that's because of the elision rules: on the declaration you're implicitly telling the compiler that the lifetime of the borrow matches the lifetime of the type. .
Thanks. I think the error messages could use a little more detail about how something that the borrow checker sees as a borrow may be an artifact of lifetime constraints in a function signature rather than an actual borrow in the function body. It certainly surprised me the first time I ran into it. (Maybe only in the explanatory text in the compiler error index. It looks like E0597 could also benefit from that detail, because it's a similar case, and an example in E0716 produces E0597.)
Shorter example, probably better suited for an example in the compiler error index: