jiebi/CodeConvo huggingface dataset:
Change:
let _timer = cgcx .prof .generic_activity_with_arg("LLVM_thin_lto_patch_debuginfo", thin_module.name()); <del> llvm::LLVMRustLTOPatchDICompileUnit(llmod, cu1); </del> <ins> llvm::LLVMRustThinLTOPatchDICompileUnit(llmod, cu1); </ins> save_temp_bitcode(cgcx, &module, "thin-lto-after-patch"); }

Discussion:
As of the 2021-09-23 nightly, rustc has stopped producing debug output for variables in a specific combination of circumstances: The variable is It is defined in a lib crate. The lib crate is included in a bin crate. The bin crate is built with . We noticed this after bumping past 09-23 to the 2021-10-27 nightly, when our debugger broke. The static is still being included in the ELF output (both allocated space, and represented correctly in the symtab), but is missing from DWARF. Bisecting indicates 2021-09-23 as the culprit (09-22 works). Here is a repro case that I've reduced that works on linux x86-64, at least, and probably other DWARF platforms. modify labels: +regression-from-stable-to-nightly -regression-untriaged
Bumping to regression-stable-to-beta, because 2021-09-23 is a 1.57 nightly. But would be good to confirm this reproduces on beta.
points at (). That being a rollup, looks the most relevant.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high
I think this may be a duplicate of . Please test on a current nightly, and when goes out it should have the backport via . It's still possible that introduced its own problem, but maybe it just exacerbated the LLVM issue.
It looks to me like the problem still reoccurs on the current nightly: <details<summaryFor completeness, here is a transcript showing the behavior that is expected, from nightly-2021-09-22</summary</details
This appears to still be reproducing as of ; we're stuck on because basically anything newer breaks our debugger.
So, after working out how to build a toolchain that includes our cross target and rust-lld and whatnot locally, I've tested today's mainline with a revert for PR , commit -- which had previously identified as the likely culprit. I can confirm that DWARF output for our statics on thumbv7em and kin is restored after that commit is reverted. Shall I prepare a PR?
Change:
| Options::ENABLE_FOOTNOTES | Options::ENABLE_STRIKETHROUGH | Options::ENABLE_TASKLISTS <ins> | Options::ENABLE_SMART_PUNCTUATION </ins> } /// A subset of [`opts()`] used for rendering summaries. pub(crate) fn summary_opts() -> Options { <del> Options::ENABLE_STRIKETHROUGH </del> <ins> Options::ENABLE_STRIKETHROUGH | Options::ENABLE_SMART_PUNCTUATION </ins> } /// When `to_string` is called, this struct will emit the HTML corresponding to

Discussion:
Split off from . modify labels: T-rustdoc C-enhancement <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Uh, it looks like rustbot is editing my message and adding weird comments:
Cc
It looks like smart punctuation doesn't work in headers: ! wasn't able to reproduce this in pulldown itself; I'm guessing rustdoc is doing something special with headers. Cc
Triagebot does that as a way of easily storing data per-issue (we could do it in the database now, we didn't have one back then). But it's expected and shouldn't really be a problem.
Is this a good thing? Wouldn't keeping things as it is is better?
I think if you want to argue against doing this, giving reasons would be helpful. I personally think given that we already use emoji and otherwise non-ASCII characters readily, it should be reasonable for us to generate smart quotes as well.
I do think emoji and other non-ASCII characters if specified would be good except for smart quote. It's like saying to use greek question mark which is the same as semi-colon when a semi-colon was seen in documentation to make it look a bit cooler. One thing is copying, when others are copying the text, it will copy the utf-8 version of smart quotes which when displayed in terminals which in turn will make it look ugly and hard for text processing. Auto changing text to emoji I am okay with that. But not automatically changing single quotes, double quotes and semi-colons. Personally I don't see much benefit to that, usually if users want it they would specifically type it out but otherwise it would be similar. In my humble opinion, looks wise the smart quotes are more ugly, but easier to distinguish opening and closing quotes, but still when copied and pasted it may not look so good.
Change:
#![deny(const_err)] <ins> const X: *const u8 = b"" as _; </ins> fn main() { let _ = ((-1 as i8) << 8 - 1) as f32;

Discussion:
In particular, . We can't use because it's in a const context.
whoops, on it
Please reopen.
hmm... that's a different issue. this looks like your new constant code
Change:
<ins> // Regression test for https://github.com/rust-lang/rust/issues/122581 // This used to ICE, because the union was unsized and the pointer casting code // assumed that non-struct ADTs must be sized. union Union { val: std::mem::ManuallyDrop<[u8]>, //~^ ERROR the size for values of type `[u8]` cannot be known at compilation time } fn cast(ptr: *const ()) -> *const Union { ptr as _ } fn main() {} </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: should be sized but is not?', 'error: internal compiler error: should be sized but is not?' 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: [typeck] type-checking [analysis] running analysis passes on this crate --
cc
This is incidentally fixed by by making unions always sized.
smaller: The union is currently in fact not sized, but this code assumes that non-struct ADTs must be sized:
Change:
// available to normal end-users. return true } <del> let codegen_fn_attrs = tcx.codegen_fn_attrs(self.def_id()); // need to use `is_const_fn_raw` since we don't really care if the user can use it as a // const fn, just whether the function should be inlined codegen_fn_attrs.requests_inline() || tcx.is_const_fn_raw(self.def_id()) </del> <ins> tcx.codegen_fn_attrs(self.def_id()).requests_inline() </ins> } }

Discussion:
Adding to 's definition works around the ICE. Also, the bug doesn't trigger if is an non- , so it's not just that is inlined cross-crate, but -specific behavior is also involved. cc
Still happens on the latest nightly. cc It doesn't block , but the workaround in that PR is a bit ugly.
I have a fix in
Change:
}; write!(w, "{}{}{}fn <a href='{href}' class='fnname'>{name}</a> {generics}{decl}{where_clause}", <del> UnsafetySpace(unsafety), </del> ConstnessSpace(constness), <ins> UnsafetySpace(unsafety), </ins> match abi { Abi::Rust => String::new(), a => format!("extern {} ", a.to_string())

Discussion:
Doc inclusion / doc reexport does not show properly (example: std::cell::Cell::new). Reexport metabug: rustdoc: Pain points of reexports const fn tracker:
Change:
(InternMode::Static, hir::Mutability::MutMutable) => {}, // we statically prevent `&mut T` via `const_qualif` and double check this here (InternMode::ConstBase, hir::Mutability::MutMutable) | <del> (InternMode::Const, hir::Mutability::MutMutable) => bug!("const qualif failed to prevent mutable references"), </del> <ins> (InternMode::Const, hir::Mutability::MutMutable) => { match referenced_ty.sty { ty::Array(_, n) if n.unwrap_usize(self.ecx.tcx.tcx) == 0 => {} ty::Slice(_) if value.to_meta().unwrap().unwrap().to_usize(self.ecx)? == 0 => {} _ => bug!("const qualif failed to prevent mutable references"), } }, </ins> } // Compute the mutability with which we'll start visiting the allocation. This is // what gets changed when we encounter an `UnsafeCell`

Discussion:
The build of smoltcp on nightly started failing recently with an ICE: https://travis- ~I suspect this might be caused by E0713, but it shouldn't be an ICE in any case.~
I believe the fundamental cause of the error is that the code looks like the following: That's pretty obviously unsound.
Correction for earlier comment: E0713 is completely unrelated. I've eliminated the problematic code that caused it in m-labs/smoltcp but the crash is still there.
cc (also, such an ICE should say "const checking" or similar - we should maybe even rename the pass itself in the compiler - the "qualify" part isn't as primary for MIR as it is for the AST side).
<details<summaryFull backtrace</summary</details<details<summaryfunction </summary</details
MCVE: : ok : ICE I'm bisecting it now.
Bisected to / .
Oh, I forgot about the ZST trickery, sorry, will have a fix tomorrow
What's the ZST here? in ?
Yes. That's a that gets unsized to .
Change:
<ins> // edition: 2021 async fn asyncfn() { let binding = match true {}; //~^ ERROR non-exhaustive patterns: type `bool` is non-empty } fn main() {} </ins>

Discussion:
<!-- ICE: Rustc '' 'error: internal compiler error: unexpected coroutine type Pin<&mut {async fn 3:2}', 'error: internal compiler error: unexpected coroutine type Pin<&mut {async fn 3:2}' File: --snippet: 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
regression in ping
Change:
// an error. let mut cu1 = ptr::null_mut(); let mut cu2 = ptr::null_mut(); <del> llvm::LLVMRustLTOGetDICompileUnit(llmod, &mut cu1, &mut cu2); </del> <ins> llvm::LLVMRustThinLTOGetDICompileUnit(llmod, &mut cu1, &mut cu2); </ins> if !cu2.is_null() { let msg = "multiple source DICompileUnits found"; return Err(write::llvm_err(&diag_handler, msg));

Discussion:
As of the 2021-09-23 nightly, rustc has stopped producing debug output for variables in a specific combination of circumstances: The variable is It is defined in a lib crate. The lib crate is included in a bin crate. The bin crate is built with . We noticed this after bumping past 09-23 to the 2021-10-27 nightly, when our debugger broke. The static is still being included in the ELF output (both allocated space, and represented correctly in the symtab), but is missing from DWARF. Bisecting indicates 2021-09-23 as the culprit (09-22 works). Here is a repro case that I've reduced that works on linux x86-64, at least, and probably other DWARF platforms. modify labels: +regression-from-stable-to-nightly -regression-untriaged
Bumping to regression-stable-to-beta, because 2021-09-23 is a 1.57 nightly. But would be good to confirm this reproduces on beta.
points at (). That being a rollup, looks the most relevant.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high
I think this may be a duplicate of . Please test on a current nightly, and when goes out it should have the backport via . It's still possible that introduced its own problem, but maybe it just exacerbated the LLVM issue.
It looks to me like the problem still reoccurs on the current nightly: <details<summaryFor completeness, here is a transcript showing the behavior that is expected, from nightly-2021-09-22</summary</details
This appears to still be reproducing as of ; we're stuck on because basically anything newer breaks our debugger.
So, after working out how to build a toolchain that includes our cross target and rust-lld and whatnot locally, I've tested today's mainline with a revert for PR , commit -- which had previously identified as the likely culprit. I can confirm that DWARF output for our statics on thumbv7em and kin is restored after that commit is reverted. Shall I prepare a PR?
Change:
CFG_DISABLE_UNSTABLE_FEATURES=1 endif ifeq ($(CFG_RELEASE_CHANNEL),beta) <del> CFG_RELEASE=$(CFG_RELEASE_NUM)-beta </del> <ins> CFG_RELEASE=$(CFG_RELEASE_NUM)-beta$(CFG_PRERELEASE_VERSION) </ins> # When building beta distributables just reuse the same "beta" name # so when we upload we'll always override the previous beta. This # doesn't actually impact the version reported by rustc - it's just

Discussion:
current beta is 'rustc 1.1.0-beta' but it should be 'rustc 1.1.0-beta.1'
Change:
} } <del> pub fn name(&self, id: HirId) -> Name { match self.get(id) { </del> <ins> pub fn opt_name(&self, id: HirId) -> Option<Name> { Some(match self.get(id) { </ins> Node::Item(i) => i.ident.name, Node::ForeignItem(fi) => fi.ident.name, Node::ImplItem(ii) => ii.ident.name,

Discussion:
I wanted to quickly prototype a bit of code involving tokio and some shared state but ran into a rustc panic: I installed by running rustup update a few hours back. In my code (see below) there seems to be a mistake, having a lock living too long i suppose. The following code leads to the error (based on ) : Unfortunately I could not remove unnecessary parts of the code without making the panic go away. Might this has something to do with detecting the lock lifetimes?
ICE occurs in:
Error before: Regression in cc (I'm on a MCVE)
triage: P-high, removing nomination tag.
Here we go: So takes a type that is , but isn't . That's causing the ICE.
modify labels: -E-needs-mcve
Not sure how to express the for the MCVE here. You can of course use a new struct (like I did before with ), or use a . Interesting this works with as well, but not with other (custom) traits. Maybe because is an ?
Fixed output:
Change:
use char; use convert::TryFrom; use fmt; <del> use iter::{Map, Cloned, FusedIterator}; </del> <ins> use iter::{Map, Cloned, FusedIterator, TrustedLen}; use iter_private::TrustedRandomAccess; </ins> use slice::{self, SliceIndex}; use mem;

Discussion:
I compared the performance of three equivalent functions: This is results (release mode):
IIRC zip is specialized for slices which is why the last case is so much faster.
Try also to compile with
A question could be: is it possible for to return something similar to ?
It makes the two times faster, the speed of the and the has stayed the same as before.
You've discovered the "untweaked speed" of zip :frowning_face:, which is what has. can implement the same way slice iterators do, in fact is just a newtype around an iterator that already implements that trait.
Change:
<ins> #![feature(type_alias_impl_trait)] type T = impl Copy; //~^ ERROR cannot resolve opaque type static STATIC: T = None::<&'static T>; fn main() {} </ins>

Discussion:
This triggers a stack overflow of rustc (even without the TAIT feature gate, i.e. on stable too) (): <details<summaryBacktrace</summary<p</p</details
(side-note: doesn't overflow in the new trait solver )
I'm gonna look into this
Change:
<ins> error[E0477]: the type `(dyn Bar<&'a u32> + 'static)` does not fulfill the required lifetime --> $DIR/supertrait-lifetime-bound.rs:10:5 | LL |     test1::<dyn Bar<&'a u32>, _>(); |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | note: type must satisfy the static lifetime as required by this binding --> $DIR/supertrait-lifetime-bound.rs:5:22 | LL | fn test1<T: ?Sized + Bar<S>, S>() { } |                      ^^^^^^ error: aborting due to previous error For more information about this error, try `rustc --explain E0477`. </ins>

Discussion:
Found in () Errors: modify labels: T-compiler, C-bug, A-traits, A-dst, A-associated-items, A-typesystem and please add “I-unsound ”
cc - this looks like it might be related to some of your work.
Assigning as discussed as part of the and removing .
Without the keyword, the function type-checks since Rust 1.0.0. And a function like e.g. leads to reading a bunch of memory and segfaulting on every Rust version, as far as I can tell (at least in debug builds).
To me, this is the same root cause as : we unconditionally say that any type is well-formed and implements without checking the actual where clauses declared on the trait, so you can deduce contradictory things with the help of implied bounds (to be fair, already introduced some checks). Except that I was wrong in my saying that an easy fix for our current limited form of implied bounds would be to just check transitive lifetime requirements. Obviously, example shows that implied bounds for super traits play a role as well.
Change:
let OnUnimplementedNote { message, label, note } = self.on_unimplemented_note(trait_ref, obligation); let have_alt_message = message.is_some() || label.is_some(); <ins> let is_try = self.tcx.sess.source_map().span_to_snippet(span) .map(|s| &s == "?") .unwrap_or(false); let is_from = format!("{}", trait_ref).starts_with("std::convert::From<"); let message = if is_try && is_from { Some(format!( "`?` couldn't convert the error to `{}`", trait_ref.self_ty(), )) } else { message }; </ins> let mut err = struct_span_err!( self.tcx.sess,

Discussion:
Currently E277's message is confusing and seemingly ambiguous when it occurs on a try () expression (this may not be limited to E277, it's just the one I noticed). For example, in : The problem is that 's error type is while 's error type is . In this case the error isn't too confusing, but if the try is in a chained expression () and you're a noob it isn't clear why it wants implemented on . It doesn't necessarily even require a whole fix suggestion, all it would take is making the error only highlight the , as the issue is actually occuring when unwrapping the result. Thanks!
Change:
tcx.arena.alloc_slice(&result) } defined_lib_features => { cdata.get_lib_features(tcx) } <del> defined_lang_items => { cdata.get_lang_items(tcx) } </del> <ins> defined_lang_items => { tcx.arena.alloc_from_iter(cdata.get_lang_items()) } </ins> diagnostic_items => { cdata.get_diagnostic_items() } missing_lang_items => { cdata.get_missing_lang_items(tcx) }

Discussion:
(Using + ) (Minimized from ) : <details<summary<strongBacktrace</strong</summary<p</p</detailscc
One thing I forgot to do is check that my minimization is exhaustive. After deleting all the from the original crate it still ICEs, so there must be another way that it is triggering this too.
Could this issue be related/duplicate of (and therefore fixed by )? Also, perhaps replace the team label with ?
I assume you meant ? That was included in which I tested with (we have a collection of failing crates in that I am rebuilding as each fix for the fallout from lands).
Fixed in
Change:
<ins> fn main() { (if foobar) //~ ERROR expected `{`, found `)` } </ins>

Discussion:
I tried this code: first outputs some error messages and then hangs up trying to allocate a large amount of memory. :
modify labels: regression-from-stable-to-nightly
Error: Label regression-from-stable-to-nightly can only be set by Rust team members Please let know if you're having trouble with this bot.
Rust 1.34.0 and before is OK:
triage: P-medium. Removing nomination. Assigning to self and for initial investigation.
I'm seeing the same behavior on the following programs: and These were found with the help of .
Another program that I also observe to make run out of memory:
The original report is caused due to growing unbounded in a bad parser code path, in part due to it being a and not a (which it can't be at the moment). Now that I have a clue at what causes the behavior, I'll dig deeper for the trigger.
Change:
// Must destructure at least one field of `Foo` let Foo { field } = beverage; // boom <del> _ = field; //~ ERROR non-binding let on a type that implements `Drop` </del> <ins> _ = field; //~ ERROR non-binding let on a type that has a destructor </ins> <del> let _ = field; //~ ERROR non-binding let on a type that implements `Drop` </del> <ins> let _ = field; //~ ERROR non-binding let on a type that has a destructor </ins> }

Discussion:
I tried this code: I got this warning: However, there is no impl on the type, so the error message is misleading. It is true however that there is a destructor, as defined here: That being said, it's insiginificant for all underlying types (only destructor of and type in the ), so ideally the warning still wouldn't even show. : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Well, even if the parameter of is , it still has a side-effect (deallocates memory). I don't think we need this special-casing. I do think the diagnostic is a bit misleading and should just say "has a destructor" or "has side-effects when dropped". Is there a more practical code example for why you'd want to suppress this error? The example you gave is a bit artificial, so it's a hard to motivate why we'd want to suppress this code since it really could be rewritten to be clearer.
claim
Change:
"--retry", "3", "-Sf", "-o", path, url], verbose=verbose, exception=True, # Will raise RuntimeError on failure <del> help_on_error=help_on_error) </del> <ins> ) </ins> except (subprocess.CalledProcessError, OSError, RuntimeError): # see http://serverfault.com/questions/301128/how-to-download if platform_is_win32:

Discussion:
I accidentally missed this when porting it to rustbuild: It would be nice to add it back. Mentoring instructions: Add a new parameter to and pass it down from : This code moved around in so you may want to base your changes off that PR until it lands. label +E-easy +E-mentor +A-rustbuild <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Please also remove the dead code from at the same time:
claim