jiebi/CodeConvo huggingface dataset:
Change:
pub use parking_lot::MutexGuard as LockGuard; pub use parking_lot::MappedMutexGuard as MappedLockGuard; <del> pub use once_cell::sync::OnceCell; </del> <ins> pub use std::lazy::SyncOnceCell as OnceCell; </ins> pub use std::sync::atomic::{AtomicBool, AtomicUsize, AtomicU32, AtomicU64};

Discussion:
After is merged, usage of in this module: should be replaced by . The dependency from corresponding can be removed afterwards. It might make sense to request a perf run, as version uses parkinglot, while the standard one uses std mutex, but I expect the difference to not matter -- fast path is equivalent for both.
claim
is done! Though, I am not unsure if we maybe should wait until it tickles down to beta? Not sure how bootstraping works with libstd, I guess, we can just try and see if the build fails.
The compiler always builds with the in-tree standard library, so cfg(bootstrap) should never be necessary (beyond lints, and other compiler-implemented rather than library-implemented) details.
ping this is ready to be implemented.
I'll start soon! Sorry I got a bit overwhelmed with work. If in the next couple of days I haven't replied feel free to re-assign.
On it!
once this is merged, should other sub-crates that depend on also be updated? Like for example. Also, what about ? Some usage can probably be replaced by .
We definitely should actively remove oncecell crate from all rustc’s crates, because having two difference sources of the same data structure feels bad. Replacing lazystatic with std::lazy would also be good!
I'll try to take of it once this issue is fixed :+1:
Change:
let query_map = FromDyn::from(tls::with(|tcx| QueryCtxt::new(tcx).collect_active_jobs())); let registry = rayon_core::Registry::current(); <del> thread::spawn(move || deadlock(query_map.into_inner(), &registry)); </del> <ins> thread::Builder::new() .name("rustc query cycle handler".to_string()) .spawn(move || { let on_panic = defer(|| { eprintln!("query cycle handler thread panicked, aborting process"); // We need to abort here as we failed to resolve the deadlock, // otherwise the compiler could just hang, process::abort(); }); break_query_cycles(query_map.into_inner(), &registry); on_panic.disable(); }) .unwrap(); </ins> }); if let Some(size) = get_stack_size() { builder = builder.stack_size(size);

Discussion:
I noticed that when parallel rustc panics due to deadlock, it would say instead of . Is this intended?
Hm, I did recently land but I'm not sure if it would cause this issue. It should only affect threads that Rust doesn't create itself and in any case it switches the default name from (which gets rendered as ) to the OS thread name (if available). So if anything I'd have thought it would have the opposite effect. Though maybe there's something about parallel's deadlocks I'm missing.
I think you're good since the problem is older than your pr :D
Oh good! I mean bad, but I was dreading a very long debugging session
well, if you feel bored or something.... :upsidedownface:
Serial rustc creates a single thread called rustc. I assume parallel rustc just doesn't name its rayon threads, no debugging session ahead.
We create a new thread to look for query cycles, it's unnamed at the moment and that's where the panic happens.
Change:
LocalRef::Operand(None) => return, LocalRef::Operand(Some(operand)) => { <ins> // Don't spill operands onto the stack in naked functions. // See: https://github.com/rust-lang/rust/issues/42779 let attrs = bx.tcx().codegen_fn_attrs(self.instance.def_id()); if attrs.flags.contains(CodegenFnAttrFlags::NAKED) { return; } </ins> // "Spill" the value onto the stack, for debuginfo, // without forcing non-debuginfo uses of the local // to also load from the stack every single time.

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> const F: &'static dyn Send = &7u32; fn main() { let a: &dyn Send = &7u32; match a { F => panic!(), //~^ ERROR trait objects cannot be used in patterns _ => {} } } </ins>

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. --<!-- 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 that the error is also present on stable (1.42.0). <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
cc
cc I don't think should be structurally matchable.
Note that this isn't matching on , it's matching on . There's a double pointer indirection because AtomicPtr requires T to be Sized.
References match by their pointee value, unlike raw pointers. You should use if you want to actually compare the pointers.
Change:
<ins> const F: &'static dyn Send = &7u32; fn main() { let a: &dyn Send = &7u32; match a { F => panic!(), //~^ ERROR trait objects cannot be used in patterns _ => {} } } </ins>

Discussion:
Pretty straightforward. The idea is to plug logic into a template. This seems like something that should/could work. Playground link: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
"smaller": Error:
claim
release-assignment is not structural match so this should not compile. We probably shouldn't ICE here though :laughing: cc
It shouldn't be, but it currently is. To fix it you need to change , .
Change:
// Issue #14893. Tests that casts from vectors don't behave strangely in the // presence of the `_` type shorthand notation. <ins> // </ins> // Update: after a change to the way casts are done, we have more type information // around and so the errors here are no longer exactly the same. <ins> // // Update: With PR #81479 some of the previously rejected cases are now allowed. // New test cases added. </ins> struct X { y: [u8; 2],

Discussion:
cc is this a coercion that's expected to work?
triage: I-nominated
The first cast is from to , the second is from to . I'm not actually sure if this is meant to work, I guess it should. The intention here is to give a way to treat arrays like C-arrays and get a pointer to the start of the array. It seems that if the array is mutable, then the pointer should be too. I recommend this is P-low - it is backwards compatible, rare, and just a bug by omission, really. The fix should be pretty easy though.
Ah I wasn't sure if this was intended, if it's actually intended then I don't mind removing the nomination as well!
I'm not sure how intended this is, but it doesn't seem too harmful. ;)
P-low, (perhaps "just a bug", perhaps a minor feature.)
Triage: no change
This still happens today (with ), but the error message is slightly different: is another -related issue.
Change:
A link name was given with an empty name. Erroneous code example: <del> ```ignore (cannot-test-this-because-rustdoc-stops-compile-fail-before-codegen) </del> <ins> ```compile_fail,E0454 </ins> #[link(name = "")] extern {} // error: `#[link(name = "")]` given with empty name ```

Discussion:
The below code (in ) has three doc tests: first succeeds as expected. second test fails as expected: the constant would be and there is an attempt to subtract with overflow. third test should succeed as it has the exact same code as the second test but is marked as . However the test fails with the message “Test compiled successfully, but it's marked .” rust /// let works = cf::S::<u32::default(); /// (); /// rust /// let shouldfail = cf::S::<u64::default(); /// (); /// compilefail /// let shouldfail = cf::S::<u64::default(); /// (); ///
This is a consequence of how works. (and ) does the equivalent of (or the same as ), which does not perform all steps of compilation (like codegen and linking). One of the issues tracking this problem is . I'm not sure why rustdoc does not perform the full compilation steps for and .
Change:
`i686-unknown-freebsd` | ✓ | 32-bit FreeBSD [^x86_32-floats-return-ABI] `i686-unknown-linux-musl` | ✓ | 32-bit Linux with musl 1.2.3 [^x86_32-floats-return-ABI] [`i686-unknown-uefi`](platform-support/unknown-uefi.md) | * | 32-bit UEFI <del> [`loongarch64-unknown-linux-musl`](platform-support/loongarch-linux.md) | ? |  | LoongArch64 Linux (LP64D ABI) with musl 1.2.3 </del> [`loongarch64-unknown-none`](platform-support/loongarch-none.md) | * |  | LoongArch64 Bare-metal (LP64D ABI) [`loongarch64-unknown-none-softfloat`](platform-support/loongarch-none.md) | * |  | LoongArch64 Bare-metal (LP64S ABI) [`nvptx64-nvidia-cuda`](platform-support/nvptx64-nvidia-cuda.md) | * | --emit=asm generates PTX code that [runs on NVIDIA GPUs]

Discussion:
The output is miles of errors like this: I think this target has somehow slipped past our CI? Maybe I'm searching our codebase wrong, but I don't think I can find any tests for it? Note that this affects the target specifically, as identified by the Miri cron job that tries to build all tier 2 targets: which just failed: cc target maintainers:
I'm sorry. The is incorrectly written in the Tier 2 table in .
Change:
let closure_hir_id = self.tcx.hir().local_def_id_to_hir_id(local_def_id); if should_do_migration_analysis(self.tcx, closure_hir_id) { <del> self.perform_2229_migration_anaysis(closure_def_id, capture_clause, span, body); </del> <ins> self.perform_2229_migration_anaysis(closure_def_id, capture_clause, span); </ins> } // We now fake capture information for all variables that are mentioned within the closure

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. --Removing allows the code to compile successfully. <!-- 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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
cc
I dont have too much context on how type folding works, but my guess is we are calling fold sooner that we should. I have this to the for RFC 2229, I'll bring it up during our sync tomorrow.
We want to use .
assign
Error: Parsing assign command in failed: ...'bot assign' ''... Please let know if you're having trouble with this bot.
claim
Thanks
Change:
RUST_CONFIGURE_ARGS: --build=x86_64-pc-windows-msvc --enable-profiler SCRIPT: python x.py test - MSYS_BITS: 32 <del> RUST_CONFIGURE_ARGS: --build=i686-pc-windows-msvc --target=i586-pc-windows-msvc </del> <ins> RUST_CONFIGURE_ARGS: --build=i686-pc-windows-msvc --target=i686-pc-windows-msvc </ins> SCRIPT: python x.py test --host i686-pc-windows-msvc --target i686-pc-windows-msvc # MSVC aux tests

Discussion:
The time to complete the build has became dangerously close to 3 hours starting from August 13th. ! Assuming AppVeyor is normal, I suspect one or more of the following are responsible: ( "Expose all OS-specific modules in libstd doc.") (1 hr 50 min → 2 hr 3 min = +13 min) ( "Rustbuild cleanups/fixes and improvements") (2 hr 3 min → 2 hr 25 min = +22 min) ( "Rollup of 8 pull requests") (2 hr 25 min → 2 hr 33 min = +8 min) ( "Optimize allocation paths in RawVec") (2 hr 33 min → 2 hr 50 min = +17 min) I'll check the detailed timing breakdown later. <details<summaryRaw timing data from AppVeyor</summary The raw data is extracted by running in the browser's console. </details
The cause is definitely (cc but arguably is doing the right thing. There are two noticeable change with build 4267: The non-full-deps test cases are all run twice, once for i686 and once for i586. This is because the job is configured as , and now respects . These tests occpied 43 minutes in build 4267. The takes a much longer time to build (6 seconds → 2 minutes). The other builds become slower probably only because AppVeyor was busier at that time. While this is correct to test both i586 and i686, this pushes the complete test time too close to 3 hours. If AppVeyor become really slow, the build will spuriously timeout and 3 hours are wasted. Is it a good idea to not test (since it is Tier 2)? <details<summaryDetailed timing breakdown</summary </details
Thanks so much for the detailed investigation here I... thought we were testing i586 all this time bug I guess not :(. I think we may have stopped testing awhile ago when we never detected a regression and wanted to get round 2 hours, so I think it's ok at the very least to go back to the status quo of not testing it. All in all I think it's ok to not be testing it.

Ideally we'd test everything but we just don't always have the capacity to do so :(
Unfortunately the Macs and ARMs still take about 2.5 hours (not regression) .
Change:
//! collect them instead. use rustc_ast::{Attribute, MetaItemKind}; <del> use rustc_attr::VERSION_"; </del> <ins> use rustc_attr::{rust_version_symbol, VERSION_"}; </ins> use rustc_errors::struct_span_err; use rustc_hir::intravisit::Visitor; use rustc_middle::hir::nested_filter;

Discussion:
with rustc master looks like the stabilisation version is borked? :sweat_smile: cc
Hm, it actually says it like this in the code :D
This is correct, but not ideal: https://rustc-dev- cc maybe we want to special case this in the diagnostics
Yeah seems I've missed correcting that lint. For GATs, the stabilization version will be adjusted very soon, in the coming days, as we are close to the release cycle. But this needs to be fixed for future stabilizations as well. Working on a PR. label bug
Error: Label bug can only be set by Rust team members Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
Yeah it warns correctly for lib features so only lang features are affected:
PR filed:
Change:
<ins> error: this file contains an un-closed delimiter --> $DIR/issue-62881.rs:6:53 | LL | fn f() -> isize { fn f() -> isize {} pub f< |                 - un-closed delimiter ... LL | |                                                     ^ error: missing `fn` or `struct` for function or struct definition --> $DIR/issue-62881.rs:3:41 | LL | fn f() -> isize { fn f() -> isize {} pub f< |                                         ^ error[E0308]: mismatched types --> $DIR/issue-62881.rs:3:29 | LL | fn f() -> isize { fn f() -> isize {} pub f< |                      -      ^^^^^ expected isize, found () |                      | |                      this function's body doesn't return | = note: expected type `isize` found type `()` error: aborting due to 3 previous errors For more information about this error, try `rustc --explain E0308`. </ins>

Discussion:
I'm getting an internal compiler error on the following program (found by ): I'm seeing the error on stable, beta, and nightly. As with , the error occurs on () but not on (). , the proposed fix for , does not fix this error. cc
Change:
} } <ins> struct AssociatedTypeNormalizerEnv<'a, 'gcx: 'a> { tcx: TyCtxt<'a, 'gcx, 'gcx>, param_env: ty::ParamEnv<'gcx>, } impl<'a, 'gcx> AssociatedTypeNormalizerEnv<'a, 'gcx> { fn new(tcx: TyCtxt<'a, 'gcx, 'gcx>, param_env: ty::ParamEnv<'gcx>) -> Self { Self { tcx, param_env } } fn fold<T: TypeFoldable<'gcx>>(&mut self, value: &T) -> T { if !value.has_projections() { value.clone() } else { value.fold_with(self) } } } impl<'a, 'gcx> TypeFolder<'gcx, 'gcx> for AssociatedTypeNormalizerEnv<'a, 'gcx> { fn tcx<'c>(&'c self) -> TyCtxt<'c, 'gcx, 'gcx> { self.tcx } fn fold_ty(&mut self, ty: Ty<'gcx>) -> Ty<'gcx> { if !ty.has_projections() { ty } else { debug!("AssociatedTypeNormalizerEnv: ty={:?}", ty); self.tcx.normalize_associated_type_in_env(&ty, self.param_env) } } } </ins> // Implement DepTrackingMapConfig for `trait_cache` pub struct TraitSelectionCache<'tcx> { data: PhantomData<&'tcx ()>

Discussion:
Compiling v0.2.10 and v0.4.4 with , I get the following ICEs:
reproduction:
Change:
pub literal: Literal<'tcx>, } <ins> #[derive(Clone, RustcEncodable, RustcDecodable)] pub struct TypedConstVal<'tcx> { pub ty: Ty<'tcx>, pub span: Span, pub value: ConstVal } impl<'tcx> Debug for TypedConstVal<'tcx> { fn fmt(&self, fmt: &mut Formatter) -> fmt::Result { try!(write!(fmt, "const ")); fmt_const_val(fmt, &self.value) } } </ins> #[derive(Clone, Copy, Debug, PartialEq, RustcEncodable, RustcDecodable)] pub enum ItemKind { Constant,

Discussion:
See and relevant FIXME in
As a side-note, would solve this problem quite neatly, if we were to adopt and implement it. :)
Change:
}; if let Some((article, expected)) = unexpected_res { let path_str = pprust::path_to_string(path); <del> let msg = format!("expected {}, found {} `{}`", expected, res.descr(), path_str); self.tcx .sess .struct_span_err(path.span, &msg) .span_label(path.span, format!("not {} {}", article, expected)) .emit(); </del> <ins> let mut err = MacroExpectedFound { span: path.span, expected, found: res.descr(), macro_path: &path_str, ..Default::default() // Subdiagnostics default to None }; // Suggest moving the macro out of the derive() if the macro isn't Derive if !path.span.from_expansion() && kind == MacroKind::Derive && ext.macro_kind() != MacroKind::Derive { err.remove_surrounding_derive = Some(RemoveSurroundingDerive { span: path.span }); err.add_as_non_derive = Some(AddAsNonDerive { macro_path: &path_str }); } let mut err = self.tcx.sess.create_err(err); err.span_label(path.span, format!("not {} {}", article, expected)); err.emit(); </ins> return Ok((self.dummy_ext(kind), Res::Err)); }

Discussion:
(The actual desired output should have colours and minuses on the removed derive, but to give the idea) Many users are not familiar with the terminology being used by the compiler error (i.e. the different flavours of procedural macro, derive vs attribute) and might be confused as to what they need to do in order to fix the error. Since the fix is straight-forward (i.e. remove the ), the compiler should show a code snippet that fixes the issue. No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
I have a partially functional implementation of this, though I've run into a bit of trouble, some guidance would be appreciated. Currently I'm implementing this next to the existing error in in . My trouble comes with knowing what the macro is invoked on, (function, struct), and sending the help message selectively based on that. Is there a way to get this information in , or is my approach wrong and the error should be elsewhere? As far as I can tell I am trying to implement this in a place before the AST is fully parsed, so this may be unviable
Change:
<ins> error: allow, cfg, cfg_attr, deny, forbid, and warn are the only allowed built-in attributes in function parameters --> $DIR/check-doc-alias-attr-location.rs:22:12 | LL |     fn foo(#[doc(alias = "qux")] _x: u32) -> Self::X { |            ^^^^^^^^^^^^^^^^^^^^^ </ins> error: `#[doc(alias = "...")]` isn't allowed on extern block --> $DIR/check-doc-alias-attr-location.rs:9:7 |

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. --<!-- 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
ICE only appears since 1.52. label regression-from-stable-to-stable
Better-looking code example Bisection points to
Reading the descriptions, I’d guess most likely , cc
This is indeed caused by since we're now checking parameters unlike before. The issue is in when . The call to panics because there is no name for a param. The question I have is whether we should support params for doc aliases. I didn't find anything in the tracking issue to indicate that it was supposed to be supported, and I personally don't think it makes sense. If we decide to not support doc aliases for params, then it should be an easy change to to error when is a . cc
Doc aliases are only supported for items showing up in doc search, function parameters don't, so in this case, it should error on the doc alias attribute.
Do you want to send a fix or should I?
I'll submit a fix.
Thanks! Please ping me on it (and don't forget to add a test for it too ;) ).
Change:
impl MyTrait for .. {} //~^ ERROR conflicting implementations for trait `MyTrait` <ins> trait MySafeTrait: MarkerTrait {} unsafe impl MySafeTrait for .. {} //~^ ERROR implementing the trait `MySafeTrait` is not unsafe unsafe trait MyUnsafeTrait: MarkerTrait {} impl MyUnsafeTrait for .. {} //~^ ERROR the trait `MyUnsafeTrait` requires an `unsafe impl` declaration </ins> fn main() {}

Discussion:
I suspect that we may want more experience with this syntax before freezing it, but I may also be misremembering! cc cc
triage: I-nominated
I believe you're right. I'll work on a fix for this. Here's a test case:
0 beta, P-backcompat-lang.