jiebi/CodeConvo huggingface dataset:
Change:
<ins> // The ayu theme has a different color for the "<code>" tags in the doc blocks. We need to // check that the rule isn't applied on other "<code>" elements. // // While we're at it, we also check it for the other themes. goto: file://|DOC_PATH|/test_docs/fn.foo.html // If the text isn't displayed, the browser doesn't compute color style correctly... show-text: true // Set the theme to dark. local-storage: {"rustdoc-theme": "dark", "rustdoc-preferred-dark-theme": "dark", "rustdoc-use-system-theme": "false"} // We reload the page so the local storage settings are being used. reload: assert-css: (".docblock pre > code", {"color": "rgb(221, 221, 221)"}, ALL) assert-css: (".docblock > p > code", {"color": "rgb(221, 221, 221)"}, ALL) // Set the theme to ayu. local-storage: {"rustdoc-theme": "ayu", "rustdoc-preferred-dark-theme": "ayu", "rustdoc-use-system-theme": "false"} // We reload the page so the local storage settings are being used. reload: assert-css: (".docblock pre > code", {"color": "rgb(230, 225, 207)"}, ALL) assert-css: (".docblock > p > code", {"color": "rgb(255, 180, 84)"}, ALL) // Set the theme to light. local-storage: {"rustdoc-theme": "light", "rustdoc-use-system-theme": "false"} // We reload the page so the local storage settings are being used. reload: assert-css: (".docblock pre > code", {"color": "rgb(0, 0, 0)"}, ALL) assert-css: (".docblock > p > code", {"color": "rgb(0, 0, 0)"}, ALL) </ins>

Discussion:
My guess is that the yellow inline code style is incorrectly being applied to code blocks too. ! !
cc since you're knowledgeable about rustdoc's CSS
I'll send a fix shortly.
looks to be the likely cause. searched nightlies: from nightly-2021-07-01 to nightly-2021-08-25 regressed nightly: nightly-2021-08-20 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-apple-darwin Reproduce with: </details
Change:
#include "llvm/Object/Archive.h" #include "llvm/Object/ObjectFile.h" #include "llvm/Bitcode/BitcodeWriterPass.h" <ins> #include "llvm/Support/Signals.h" </ins> #include "llvm/IR/CallSite.h"

Discussion:
Related to . If a fatal error occurs in LLVM, the compiler exits with status 1. This is problematic, because if a test is expecting a compilation failure, the test could still pass. It also makes it difficult to test for the presence of ICEs in general. A simple fix would be to patch our copy of LLVM to exit with 101 (like ICEs) in , but any other ideas would be appreciated.
Those error functions all call , which sounds like it could be a great hook for us, but then that only calls . :/
There is  though, and that handler gets called first.
That sounds nice, but if we exit with 101 (or simply panic) in the handler won't we be skipping any other cleanup (, plus any future cleanup that gets there)? Or could we just call it in our handler? I'm interested in putting a patch together, but I'm unfamiliar with how we link Rust to C++. The error handler needs to be able to consume a .
We shouldn't do anything that looks like exception unwinding. See : I think we can call it -- it's publicly declared in . We might want to keep a note to make sure we check for new cleanup needed when we update LLVM though. We bridge C++ code in . You could just write our handler in C++ there, and add some C-FFI function for to call and hook that up.
Change:
<ins> // check-pass #![feature(type_alias_impl_trait)] #![deny(improper_ctypes)] pub trait Foo { type Assoc; } impl Foo for () { type Assoc = u32; } type Bar = impl Foo<Assoc = u32>; fn assign() -> Bar {} extern "C" { pub fn lint_me() -> <Bar as Foo>::Assoc; } fn main() {} </ins>

Discussion:
cc Gives the following incorrect warning:
I'm not sure if this is incorrect - I think this is what I'd expect. In the declaration of , we don't know what concrete type is - if it were , then we could normalize to - but we don't know? Maybe I'm missing something.
Hmm, that might be true. I definitely think that the following should not lint here (with bound to u32)
I agree that seems like it should be fine. So, this happens because of this call: It makes sense that we want to lint on opaque types on extern declarations, it's unclear whether we would want to allow projections which contain opaque types - this would solve the case you've shown here, but could be used to "sneak" opaque types by the lint (in , the projection normalizes to an opaque type; it's hard to detect because the normalization goes further and resolves it to so we can't tell that it was an opaque type) - I have a build with this locally. Any thoughts on whether we should change the behavior here? cc
Hm, I think it might be worth it to normalize using here, which should not normalize the first case and your example while fixing the second one if I am not mistaken.
Long ago I filed where we also concluded Reveal::UserFacing is the right behavior for normalization in this lint. The current behavior comes from cc
I'll put up a PR with my experiments from last night later in that case.
Change:
} None if let Some((deleg, item)) = node.delegation() => { let Some(suffixes) = &deleg.suffixes else { <ins> let traitless_qself = matches!(&deleg.qself, Some(qself) if qself.position == 0); </ins> let item = match node.to_annotatable() { Annotatable::ImplItem(item) => item, ann @ (Annotatable::Item(_)

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'internal error: entered unreachable code'', 'thread 'rustc' panicked at 'internal error: entered unreachable code'' 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: [resolverforloweringraw] getting the resolver for lowering -- label +F-fndelegation
^_^
Fixed in
Change:
llcx: &'static mut llvm::Context, llmod_raw: *const llvm::Module, <del> // independent from llcx and llmod_raw, resources get disposed by drop impl tm: OwnedTargetMachine, </del> <ins> // This field is `ManuallyDrop` because it is important that the `TargetMachine` // is disposed prior to the `Context` being disposed otherwise UAFs can occur. tm: ManuallyDrop<OwnedTargetMachine>, </ins> } unsafe impl Send for ModuleLlvm {}

Discussion:
After using command random dependencies throw error. I'm 100% sure that dependencies I'm trying to build are valid because at every compile attempt different dependency fails e.g. tomledit, crossbeam-channel, actix-router_. Sometimes none of imported dependencies fail and out of 5 attempts I was able to build project succesfully twice (I deleted folder after each attempt). Example output: some dependencies (in my case 23) command Improve build scripts on Windows ARM?
Thanks for the report! Transferred to rust-lang/rust since this is a compiler issue. I'm able to reproduce, though I am also using Parallels on an aarch64 mac. I do not have native Windows ARM hardware to test, so I'm not sure if this is unique to the M2 or Parallels. If someone has native hardware, it might be good to help with testing to see if it is a general problem with the target. This appears to be a regression, and I have bisected to cc
I'm seeing the same issue intermittently on a project that uses . It looks like we might have a UAF on an LLVM object. <details<summaryCrashing stack</summary</details<details<summaryEarlier "untrack" operation</summary</detailsI'm guessing this might be triggered because causes us to drop the LLVM TargetMachine dropping the LLVM context.
Swapping the drop order back to the way we had it originally makes my reproducer compile successfully.
WG-prioritization assigning priority (). label -I-prioritize +P-high
Re-opening to track backports
I encountered this issue in Github CI yesterday. It only occurs with rust-1.74 but not with 1.73 and lower.
this should be fixed by and included in the upcoming 1.74.1 stable release. You can probably try a nightly rustc build if you're curious to test the fix.
74.1 has been released.
Yes fixed it.
Hi, sorry for reply to the closed issue, but since I updated my M2 macbook to Sonoma 14.2 last week, I randomly got similar issue
This is happening again with Full log here
Please open a new issue, but it might also have something to do with
Change:
use rustc::middle::codegen_fn_attrs::CodegenFnAttrFlags; use rustc::mir::visit::*; use rustc::mir::*; <del> use rustc::ty::subst::{InternalSubsts, Subst, SubstsRef}; use rustc::ty::{self, Instance, InstanceDef, ParamEnv, Ty, TyCtxt, TypeFoldable}; </del> <ins> use rustc::ty::subst::{Subst, SubstsRef}; use rustc::ty::{self, Instance, InstanceDef, ParamEnv, Ty, TyCtxt}; </ins> use rustc_attr as attr; use rustc_hir::def_id::DefId; use rustc_index::bit_set::BitSet;

Discussion:
The assembly generated in debug builds (-C opt-level=0) worsened for this code that uses an associated constant from a trait.This seems to be caused by the fact that the function is generic,even though the associated constant doesn't depend on the generic parameters of the function. The code: The entirety of the generated assembly for stable 1.41.0 in a debug build: The assembly generated for the same functions by rustc 1.42.0-beta.2 (2020-02-04 ) in a debug build:
out of curiosity, what prompted you to investigate this specific code sequence? (I'm trying to evaluate the severity of this code-quality regression, and it might help for me to get some idea of how wide-spread the problem might be. There are obviously a couple different features interacting in the example you have provided...)
triage: leaving unprioritized. Nominating for discussion at today's T-compiler triage meeting.
I was experimenting to figure out the best design for a feature I want to add to eventually,being efficient in debug builds is a plus(but not a hard requirement for me). The reason I reported this is that if it optimizes fine in non-generic functions,it should also do the same optimization in generic functions(so long as the constant doesn't depend on generic parameters).
How does LLVM even generate such a code sequence? Well...: Okay so I guess LLVM doesn't even simplify the CFG when optimizations are off? <hr/Anyway, the MIR differs. This is a constant folding regression. cc
I'm guessing this is caused by We're in a generic context and resolve has to be conservative so it doesn't accidentally try to inline a default value if it could get a different value in an impl. In this situation that can't happen, but I don't know how to coax resolve to know this.
The fix was already implemented though! already returns in the problematic cases. Users of don't need to special-case anything anymore. Nor do we ever need to use just because something might be polymorphic, because the fix is in already, as it has been in for associated types. I left comments here:
T-compiler triage: P-medium. Leaving nomination tag on until we actually assign this to someone.
Change:
debug!("normalize_and_test_predicates(predicates={:?})", predicates); <del> tcx.infer_ctxt().enter(|infcx| { </del> <ins> let result = tcx.infer_ctxt().enter(|infcx| { </ins> let param_env = ty::ParamEnv::empty(Reveal::All); let mut selcx = SelectionContext::new(&infcx); let mut fulfill_cx = FulfillmentContext::new();

Discussion:
Compiler panicks instead of showing an appropriate error message in case boundaries are not satisfied. I tried this code: In the result compiler panicked with the following message:
Minimal repr:
Still panics on stable 1.15.1
Change:
<ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // Related issues: #20401, #20506, #20614, #20752, #20829, #20846, #20885, #20886 fn main() { "".homura[""]; //~ ERROR no field with that name was found } </ins>

Discussion:
Found another bug in the compiler: This is the output from :
Do you have an example of code that produces this crash?
I managed to reproduce the error in the Rust play-pen: I will copy the snippet here anyway:
A simpler repro:
Change:
// (Re)check that it implements the noop diagnostic. let Some(name) = cx.tcx.get_diagnostic_name(i.def_id()) else { return }; <del> let op = match name { sym::noop_method_borrow => "borrow", sym::noop_method_clone => "clone", sym::noop_method_deref => "deref", _ => return, }; </del> let receiver_ty = cx.typeck_results().expr_ty(receiver); let expr_ty = cx.typeck_results().expr_ty_adjusted(expr); let arg_adjustments = cx.typeck_results().expr_adjustments(receiver);

Discussion:
If I have a type , and a trait that is implemented for both and , is a valid way to get a reference from an object of type . But since beta 1.71, this emits a warning. I have no idea what the warning is trying to convey, what "double reference" is referring to, or what "the inner type" is. No response
cc
Ah. then I think this lint shouldn't apply to since can mean specifically to borrow . But I think this should still apply to and
(sorry)
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
_ => return, }; <del> debug!(?poly_trait_ref, "assemble_candidates_from_object_ty"); let poly_trait_predicate = self.infcx.resolve_vars_if_possible(obligation.predicate); let placeholder_trait_predicate = self.infcx.instantiate_binder_with_placeholders(poly_trait_predicate); </del> <ins> debug!(?principal_trait_ref, "assemble_candidates_from_object_ty"); </ins> // Count only those upcast versions that match the trait-ref // we are looking for. Specifically, do not only check for the // correct trait, but also the correct type parameters. // For example, we may be trying to upcast `Foo` to `Bar<i32>`, // but `Foo` is declared as `trait Foo: Bar<u32>`. <del> let candidate_supertraits = util::supertraits(self.tcx(), poly_trait_ref) </del> <ins> let candidate_supertraits = util::supertraits(self.tcx(), principal_trait_ref) </ins> .enumerate() .filter(|&(_, upcast_trait_ref)| { self.infcx.probe(|_| {

Discussion:
The type is not inferred to be by the above mentioned nightly release, c.f. Using the stable, the code compiles with out issue. EDIT: It seems to be related to GAT, i.e. a more minimal reproducer is: which similarly fails on nightly and builds on stable. <details<summaryMore details</summaryon the above-mentioned nightly version whereas stable is happy Simply asserting that is via e.g. works on stable and nightly. </details
The reproducer wouldn't compile on stable though?
Sorry, I must have messed something up when trying to whittle it down as the reproducer I started with definitely did compile on stable. Will try to trace my steps backwards.
And indeed using instead of makes it compile on stable. (I wanted to avoid to avoid the standard library but indeed is closer to the original code in question.) I updated the reproducer in the OP accordingly.
Great, thank you. So I believe this to be a different manifestation of from cc -- and therefore also to be fixed by
Stumbled on this separately in my own code. The simplest reproduction I was able to come up with is Removing makes it compile on nightly as well. Putting a bound on does not help.
Change:
id: NodeId, parent_prefix: &[Segment], nested: bool, <ins> list_stem: bool, </ins> // The whole `use` item item: &Item, vis: ty::Visibility,

Discussion:
I have a that has started to fail running clippy, due to a compiler error compiling wayland-protocols. The dependency chain is down from iced thru "clipboardwayland" (0.2.0) to "smithay-clipboard" (0.6.6) and to "wayland-protocols" v0.29.5 "clipboardwayland" 0.2.0 is the latest version on , but it depends on "smithay-clipboard" 0.6.6, while 0.7.0 is the latest version on wayland-protocols 0.29.5 : See also: </p</details
Ruffle is running into this same ICE with wayland-protocols:
minimized:
searched nightlies: from nightly-2023-12-17 to nightly-2023-12-19 regressed nightly: nightly-2023-12-19 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.7</summaryHost triple: x86_64-pc-windows-msvc Reproduce with: </details
cc for the bisection
~This snippet doesn't reproduce the ICE.~ Upd: sorry, it does, on 2018+ edition.
Fixed in
After being released to nightly yesterday, things are back to normal and building. Thanks!
Change:
let task = get_task_id(); // Expect the weak task service to be alive assert service.try_send(RegisterWeakTask(task, shutdown_chan)); <del> unsafe { rust_inc_kernel_live_count(); } </del> <ins> unsafe { rust_dec_kernel_live_count(); } </ins> do fn&() { let shutdown_port = swap_unwrap(&mut *shutdown_port); f(shutdown_port) }.finally || { <del> unsafe { rust_dec_kernel_live_count(); } </del> <ins> unsafe { rust_inc_kernel_live_count(); } </ins> // Service my have already exited service.send(UnregisterWeakTask(task)); }

Discussion:
/ and / do the same thing.
So, should registertask/unregistertask then be exposed in rust_builtin so it can be called from Rust?
Yes, though I suggest renaming it, since it will no longer just be used for 'registering', nor does it strictly have anything to do with tasks or weak tasks from the kernel's perspective - this count is only for determining when to shutdown the runtime. Maybe for the method name and for the builtin. It's not great either, but is less wed to implementation details.
Change:
<del> #![feature(stmt_expr_attributes)] #![deny(unused_doc_comments)] macro_rules! mac { () => {} } /// foo //~ ERROR unused doc comment mac!(); fn foo() { /// a //~ ERROR unused doc comment let x = 12; /// multi-line //~ unused doc comment /// doc comment /// that is unused match x { /// c //~ ERROR unused doc comment 1 => {}, _ => {} } /// foo //~ ERROR unused doc comment unsafe {} #[doc = "foo"] //~ ERROR unused doc comment #[doc = "bar"] //~ ERROR unused doc comment 3; /// bar //~ ERROR unused doc comment mac!(); let x = /** comment */ 47; //~ ERROR unused doc comment /// dox //~ ERROR unused doc comment { } } fn main() { foo(); } </del>

Discussion:
Other expressions work as expected: it reports just one error, for the whole sequence of doc comment lines. () Errors:
( is a rustc lint.)
True, but I as well since it's a rustdoc-related lint.
Change:
impl<T, A: Alloc> RawVec<T, A> { /// Like `new` but parameterized over the choice of allocator for /// the returned RawVec. <del> pub fn new_in(a: A) -> Self { </del> <ins> pub const fn new_in(a: A) -> Self { </ins> // !0 is usize::MAX. This branch should be stripped at compile time. <del> let cap = if mem::size_of::<T>() == 0 { !0 } else { 0 }; </del> <ins> // FIXME(mark-i-m): use this line when `if`s are allowed in `const` //let cap = if mem::size_of::<T>() == 0 { !0 } else { 0 }; </ins> // Unique::empty() doubles as "unallocated" and "zero-sized allocation" RawVec { ptr: Unique::empty(), <del> cap, </del> <ins> // FIXME(mark-i-m): use `cap` when ifs are allowed in const cap: [0, !0][(mem::size_of::<T>() == 0) as usize], </ins> a, } }

Discussion:
It should either elaborate on AssertUnwindSafe or else drop the claim that it will elaborate below.
Change:
<ins> error: attribute value must be a literal --> $DIR/validation-on-associated-items-issue-121537.rs:2:13 | LL |     #[doc = MyTrait] |             ^^^^^^^ error: aborting due to 1 previous error </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'called on a value'', 'thread 'rustc' panicked at 'called on a value'' 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<!-- query stack: [hircrate] getting the crate HIR [hirattrs] getting HIR owner attributes in `` [entry_fn] looking up the entry function of a crate [analysis] running analysis passes on this crate --
Crashes since cc
For the record: helped expose a latent bug in AST validation, which will fix.
Also (probably the same cause):
This code now causes unbound memory growth after when trying to print the query stack. after
Change:
unsafe fn handle_deadlock() { let registry = rustc_rayon_core::Registry::current(); <del> let context = tls::get_tlv(); assert!(context != 0); rustc_data_structures::sync::assert_sync::<tls::ImplicitCtxt<'_, '_>>(); let icx: &tls::ImplicitCtxt<'_, '_> = &*(context as *const tls::ImplicitCtxt<'_, '_>); let session_globals = rustc_span::with_session_globals(|sg| sg as *const _); let session_globals = &*session_globals; thread::spawn(move || { tls::enter_context(icx, |_| { rustc_span::set_session_globals_then(session_globals, || { tls::with(|tcx| QueryCtxt::from_tcx(tcx).deadlock(&registry)) }) }); </del> <ins> let query_map = tls::with(|tcx| { QueryCtxt::from_tcx(tcx) .try_collect_active_jobs() .expect("active jobs shouldn't be locked in deadlock handler") </ins> }); <ins> thread::spawn(move || rustc_query_impl::deadlock(query_map, &registry)); </ins> } #[cfg(parallel_compiler)]

Discussion:
<!-- 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. --code from glacier <!-- 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. --: NOTE this is the alt master rustc, installed via <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
This features a parallel-compiler-only bug. It is a variant of It is ultimately a blocker for and might be a blocker for but itself does not need to be fixed any time soon.
Remark from
This is not a problem with the implementation logic of the deadlock handler, but a very hard-to-trace thread scheduling vulnerability. If we add the following non-functional statement in of the function, this problem will disappear. Get rid of in deadlock handler can fix this. I just submited a to fix a set of ui test failures, including this issue.
Change:
// file descriptor. Otherwise, the first file descriptor opened // up in the child would be numbered as one of the stdio file // descriptors, which is likely to wreak havoc. <del> let setup = |&: src: Option<AnonPipe>, dst: c_int| { </del> <ins> let setup = |src: Option<AnonPipe>, dst: c_int| { </ins> let src = match src { None => { let flags = if dst == libc::STDIN_FILENO {

Discussion:
and are obsolete, but is not.
I think I spotted the problem, testing...
Fix in