jiebi/CodeConvo huggingface dataset:
Change:
F: FnOnce() -> T + Send + 'scope, T: Send + 'scope, { <del> Ok(ScopedJoinHandle(unsafe { self.spawn_unchecked_(f, Some(&scope.data)) }?)) </del> <ins> Ok(ScopedJoinHandle(unsafe { self.spawn_unchecked_(f, Some(scope.data.clone())) }?)) </ins> } }

Discussion:
The following code sometimes causes a data race to be reported by Miri: Miri reports: The deallocation occurs when returns and its local variable gets deallocated. The read occurs here (I am fairly sure): This reads the contents of the field after the . But the moment the is done, the memory backing might be deallocated. That makes the read a potential use-after-free, and a race with the deallocation. Cc
The following patch fixes this: However, even with this patch, we still run into a problem like the gets deallocated while still runs. This is still UB even after my proposed because contains a field that is not inside an (the field). So that part of what points to is expected to stay live for the entire duration of the function call. Another alternative might be to put the entire into an rather than allocating it on the stack frame of .
Going to attach this to the 1.63 milestone, since this is in a newly stabilized feature -- we may wish to back out stabilization for a cycle or backport fixes.
Re-opening for beta backport.
The fix was backported in .
Change:
encode_query_results::<symbol_name, _>(tcx, enc, qri)?; encode_query_results::<check_match, _>(tcx, enc, qri)?; encode_query_results::<trans_fn_attrs, _>(tcx, enc, qri)?; <ins> // const eval is special, it only encodes successfully evaluated constants use ty::maps::plumbing::GetCacheInternal; for (key, entry) in const_eval::get_cache_internal(tcx).map.iter() { use ty::maps::config::QueryDescription; if const_eval::cache_on_disk(key.clone()) { if let Ok(ref value) = entry.value { let dep_node = SerializedDepNodeIndex::new(entry.index.index()); // Record position of the cache entry qri.push((dep_node, AbsoluteBytePos::new(enc.position()))); // Encode the type check tables with the SerializedDepNodeIndex // as tag. enc.encode_tagged(dep_node, value)?; } } } </ins> } // Encode diagnostics

Discussion:
It's not clear yet whether mir interpretation is the culprit or some changes that crept into the same PR. Perf data: cc [ ] tuple-stress max: 109.4% clean-incremental is a 100% hit! The rest are small. [ ] tuple-stress-opt max: 109.1% same, clean-incremental is a 100% hit! [ ] encoding-opt max: 97.6% clean incremental-opt patched incremental: println-opt [ ] encoding max: 94.9% clean is ~ 20%, as is baseline incremental incremental cases are almost 100% [ ] coercions-opt max: 74.6% pretty universally bad, though incremental hurts worse [ ] coercions max: 66.6% pretty universally bad, though incremental hurts worse [ ] html5ever-opt max: 41.3% incremental [ ] inflate max: 40.4% universally bad, though incremental hurts worse [ ] regex-opt max: 4.7% patched incremental: byte frequencies-opt [ ] script-servo-opt max: 12.1% clean incremental-opt [ ] script-servo max: 11.6% clean incremental [ ] inflate-opt max: 11.6% incremental cases primarily
I'm going to start with ...
It would be good to dig into those use cases -- in particular, if you open them, we can see which of them are incremental use cases and which are not.
I just updated the tracking issue with that information. Most of them are incremental cases.
OK, for it's pretty clear: 58% of the execution time are spent in called from . Does that ring a bell, I haven't had time yet to really look at the code in question.
We might simply be encoding more constants now (that were previously encoded as HIR). I'll have to look at the exact logs (rustcmir::interpret::consteval=debug to just get the entry points). I'll check tomorrow morning
Ok. I found the issue. We don't seem to be loading constants from the cache. So the enormous regressions are from recomputing all constants, even if nothing changed in the code at all. That should be easy enough to fix
Only the incremental regressions were fixed. I'll investigate the others, too New perf data:
There have been a lot of perf optimizations for const eval over the last year. I think we're good now
Change:
} _ => {} } <del> // If someone calls a const fn, they can extract that call out into a separate constant (or a const // block in the future), so we check that to tell them that in the diagnostic. Does not affect typeck. let is_const_fn = match element.kind { </del> <ins> // If someone calls a const fn or constructs a const value, they can extract that // out into a separate constant (or a const block in the future), so we check that // to tell them that in the diagnostic. Does not affect typeck. let is_constable = match element.kind { </ins> hir::ExprKind::Call(func, _args) => match *self.node_ty(func.hir_id).kind() { <del> ty::FnDef(def_id, _) => tcx.is_const_fn(def_id), _ => false, </del> <ins> ty::FnDef(def_id, _) if tcx.is_const_fn(def_id) => traits::IsConstable::Fn, _ => traits::IsConstable::No, </ins> }, <del> _ => false, </del> <ins> hir::ExprKind::Path(qpath) => { match self.typeck_results.borrow().qpath_res(&qpath, element.hir_id) { Res::Def(DefKind::Ctor(_, CtorKind::Const), _) => traits::IsConstable::Ctor, _ => traits::IsConstable::No, } } _ => traits::IsConstable::No, </ins> }; // If the length is 0, we don't create any elements, so we don't copy any. If the length is 1, we // don't copy that one element, we move it. Only check for Copy if the length is larger. if count.try_eval_target_usize(tcx, self.param_env).map_or(true, |len| len > 1) { let lang_item = self.tcx.require_lang_item(LangItem::Copy, None); <del> let code = traits::ObligationCauseCode::RepeatElementCopy { is_const_fn }; </del> <ins> let code = traits::ObligationCauseCode::RepeatElementCopy { is_constable, elt_type: element_ty, elt_span: element.span, elt_stmt_span: self .tcx .hir() .parent_iter(element.hir_id) .find_map(|(_, node)| match node { hir::Node::Item(it) => Some(it.span), hir::Node::Stmt(stmt) => Some(stmt.span), _ => None, }) .expect("array repeat expressions must be inside an item or statement"), }; </ins> self.require_type_meets(element_ty, element.span, code, lang_item); } }

Discussion:
I'm basing this suggestion on two things. One, that if you follow it, the code compiles: and two, that the diagnostic help you get when you try to use a in the repeat position suggests something very similar, see "other cases." It would require the compiler to know that a value that is attempted to be repeated is able though, which I don't know whether it can, but I figured I'd suggest this, and you can reject it if it isn't possible to do. Alternatively, the help text could say something like "if the value can be made , consider creating [...]" I was inspired to make this issue based on the output you get when you try to use a as an array initializer. For instance, the code produces the output No response
hey why im getting this error message all over my github repository ! whenever i commit some changes, The first changes i able to create pull request but after some other changes im not able to do that why im getting these error ! Please help
I don't think your comment is related to this issue? If this is a problem you've encountered while trying to fix this issue, please reach out on instead.
Change:
g: X, //~ ERROR type `g` is dynamically sized. dynamically sized types may only appear as the ty h: int, } <ins> struct S3 { f: str, //~ ERROR type `f` is dynamically sized. dynamically sized types may only appear g: [uint] } struct S4 { f: str, //~ ERROR type `f` is dynamically sized. dynamically sized types may only appear g: uint } </ins> enum E<Sized? X> { V1(X, int), //~ERROR type `X` is dynamically sized. dynamically sized types may only appear as t V2{f1: X, f: int}, //~ERROR type `f1` is dynamically sized. dynamically sized types may only app

Discussion:
cc
This should be a compiler error, not an ICE. The error is (or should be) that is unsized, but is not a bare .
Why would this be an error? Isn't enabling this kind of code part of the goal of DST?
Not quite. We want to allow struct's last field to be potentially unsized, but it must be possible to have a sized version too. This is because only sized types can be instantiated. Since there is no possible sized version of , it cannot be instantiated and should be an error.
Hm, I see. This is kinda unfortunate though, because you can't hide away the actual slice type from your wrapper. Eg, you could do But that widens your wrapper to possibly be instantiated with more than and . Maybe allow a struct definition like but to use it you need to transmute something like ? As an aside, the example in this issue would probably not work anyway, as the stride should presumably be stored per pointer, and not once in the target matrices backing memory. But this is till relevant for newtype wrappers around , eg a hypothetical
Change:
} /// Cast to a pointer to a different type <del> #[unstable(feature = "ptr_cast", issue = "60602")] </del> <ins> #[stable(feature = "ptr_cast", since = "1.38.0")] </ins> #[inline] pub const fn cast<U>(self) -> *mut U { self as _

Discussion:
adds: Like with , the input pointed type does not need to be but the output pointed type does, because we wouldn’t know what appropriate pointer metadata (slice length, trait object vtable, …) to insert. The actual requirement is that the pointer is thin, but is the closest approximation we have (until we add something like ).
Let’s? fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [ ] [x] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon.
Getting this issue when executing: More detail:
Your Rust installation is out of date.
Change:
//! //! On Windows this indirects IO into threads to work around performance issues //! with Defender (and other similar virus scanners that do blocking operations). <del> //! On other platforms this is a thin shim to fs. </del> //! //! Only calls needed to permit this workaround have been abstracted: thus //! fs::read is still done directly via the fs module; if in future rustdoc //! needs to read-after-write from a file, then it would be added to this //! abstraction. <ins> use std::cmp::max; </ins> use std::fs; use std::io; use std::path::{Path, PathBuf}; use std::string::ToString; use std::sync::mpsc::Sender; <ins> use std::thread::available_parallelism; use threadpool::ThreadPool; </ins> pub(crate) trait PathError { fn new<S, P: AsRef<Path>>(e: S, path: P) -> Self

Discussion:
As discovered by in rust-lang/cargo, a Cargo test is intermittently failing on Windows because a source file generated by Rustdoc is not being written before the process exits. The suspected issue is that Rustdoc spawns asynchronous writes here: However, Rustdoc never checks that the writes are completed. We should add a mechanism that prevents the process from exiting before these write tasks are completed. One possible solution: Add a field to . Increment at the start of , and decrement at the end of the spawned Rayon task. Add a method that spin-loops until is zero. (Alternatively: use a condition variable, and have notify the condvar when is decremented.) Either call explicitly in the end of the Rustdoc process, or add it as a implementation to . cc
Change:
let pat_ty = pat_ty.fn_sig(tcx).output(); let pat_ty = pat_ty.no_bound_vars().expect("expected fn type"); <del> self.demand_eqtype_pat(pat.span, expected, pat_ty, match_arm_pat_span); </del> <ins> // Type-check the tuple struct pattern against the expected type. let diag = self.demand_eqtype_pat_diag(pat.span, expected, pat_ty, match_arm_pat_span); let had_err = diag.is_some(); diag.map(|mut err| err.emit()); </ins> // Type-check subpatterns. if subpats.len() == variant.fields.len()

Discussion:
Source code:
Please provide the source code needed to reproduce this (or preferably a reduced version of that)
Sourced code provided at the end of the document. I'm willing to provide more info if needed.
Reconstructed from first principles:
The problem occurs here:
triage: has PR. P-high, removing nomination.
Change:
<ins> // check-pass // edition:2018 #![deny(unreachable_code)] async fn foo() { endless().await; } async fn endless() -> ! { loop {} } fn main() { } </ins>

Discussion:
I tried this code: I expected to see this happen: no build warn Instead, this happened: :
We . The likely cause is that parts of the await desugaring are being linted against. We can likely check the span to see if the code that is being linted against is part of the desugaring, but we do want to be careful to ensure that still gets a lint warning.
Marking as deferred as this doesn't seem like a problem that needs to block stabilization.
cc who has done some work on the inhabited logic stuff.
I'm now getting this warning even for functions that loop but eventually return. It worked fine with nightly-2019-08-21, but the latest nightly (2019-09-17) is broken. For example, this code generates a warning: with the warning repeated twice:
Can confirm. I believe this regressed somewhere after nightly 09-09-2019.
I think I have this in my code here: Can somebody confirm this? If not I'll file another bug report.
yeah that's the same, the function can "never" return from the unconditional loop.
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. // error-pattern:oops fn main() { let func = || -> ! { panic!("oops"); }; func(); } </ins>

Discussion:
Compiler panics, when closure marked as diverging. I tried this code: I expected to see this happen: Instead, this happened: : Backtrace:
Change:
<ins> // check-pass #![feature(non_lifetime_binders)] //~^ WARN is incomplete and may not be safe pub fn foo() where for<V> V: Sized, { bar(); } pub fn bar() where for<V> V: Sized, { } pub fn main() {} </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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Regression in nightly-2023-02-18 commit[0] 2023-02-16: Auto merge of - matthiaskrgr:rollup-kpzfc6j, r=matthiaskrgr commit[1] 2023-02-16: Auto merge of - Zoxc:arena-query-clean, r=cjgillot commit[2] 2023-02-17: Auto merge of - matthiaskrgr:rollup-bgadak1, r=matthiaskrgr commit[3] 2023-02-17: Auto merge of - kylematsuda:type-of, r=BoxyUwU commit[4] 2023-02-17: Auto merge of - Zoxc:query-ctxtx-byval, r=cjgillot commit[5] 2023-02-17: Auto merge of - BoxyUwU:addconstarghastype_predicate, r=compiler-errors commit[6] 2023-02-17: Auto merge of - matthiaskrgr:rollup-5k2j7cx, r=matthiaskrgr commit[7] 2023-02-17: Auto merge of - WaffleLapkin:de-arena-allocates-you-OwO, r=Nilstrieb
It's just the non-lifetime binders pr:
Change:
<ins> // compile-flags: -Z mir-opt-level=2 // ignore-cloudabi no std::fs // build-pass use std::fs::File; use std::io::{BufRead, BufReader}; fn file_lines() -> impl Iterator<Item = String> { BufReader::new(File::open("").unwrap()) .lines() .map(Result::unwrap) } fn main() { for _ in file_lines() {} } </ins>

Discussion:
Compiling with I get since two nightlies:
Triage: It's now compiled fine with the latest nightly, I think it's fixed by .
It works now, thank you.
This should be open until the test is .

<!-- 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 is from glaciers , original ticket: The code still ICEs when checking with <!-- 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. --repo is @ <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Triage: It's now compiled fine with the latest nightly, perhaps it's fixed by .

As , the MIR inliner seems to fail when dealing with opaque return types. Test case: Invocation: <details<summaryICE:</summary</details
I'm not sure how async closures desugar, so this could be way off base, but this looks very similar to the other ICEs tracked in . Does this look like another instance of that issue to you?
The immediate cause of this is the fact that we call during inlining: If we do this, we should also be normalizing the substs we pass to , so that we reveal any opaque types. However, it looks like the opaque type occurs within a binder (due the opaque type appearing in the return type of an fn pointer), so I think lazy normalization may be required to fix this in the general case.
Triage: It's now compiled fine with the latest nightly, I think it's fixed by .
Change:
/// held. An RAII guard is returned to allow scoped unlock of the lock. When /// the guard goes out of scope, the mutex will be unlocked. /// <ins> /// The exact behavior on locking a mutex in the thread which already holds /// the lock is left unspecified, however, this function will not return on /// the second call, it might e.g. panic or deadlock. /// </ins> /// # Errors /// /// If another user of this mutex panicked while holding the mutex, then /// this call will return an error once the mutex is acquired. <ins> /// /// # Panics /// /// This function might panic when called if the lock is already held by /// the current thread. </ins> #[stable(feature = "rust1", since = "1.0.0")] pub fn lock(&self) -> LockResult<MutexGuard<T>> { unsafe {

Discussion:
is not reentrant (you can't a mutex if you already ed it and haven't released the lock), but this behavior is . Looks like the exact consequences of locking the mutex twice vary by platform. On linux, you get a deadlock. On windows there is a panic: Maybe this should on all platforms?
Windows will also deadlock most of the time as we use SRWLOCK instead of CRITICAL_SECTION, it should basically be documented that you can't lock a mutex twice on the same thread.
But are the exact consequences of locking twice unspecified?
Yeah I think we'll want to leave it unspecified. We must detect it with CRITICALSECTION as the underlying primitive allows reentrancy, and the most reasonable thing to do there is to just panic. We'd probably panic if we could on SRWLOCK and pthreadmutex_t, but they're not as easily detectable.
The problem is that Rust is so paranoid about data races, that one has to uses mutexes all over the place (if using shared memory) to fight the borrow checker off. This results then in increased risk of deadlocks due to the fact that locks are not reentrant.
parkinglot crate provides reentrant mutex if you need it: I‘m curious what’re the reasons behind not providing reentrant mutex as the default implementation in the standard library?
I think it's because Mutex and friends were originally meant to be wrappers around the native OS synchronization primitives, and some OS mutexes are not reentrant, though I'm not 100% sure on that.
there's definitely an interesting conversation to have here, but a closed PR is not the right venue for such discussions: it's unlikey to be noticed by anyone not originally subscribed to the issue it actively pings all relevant folks, which spends people's time. I've moved this issue to the forum: In the future, please consider steering folks to the appropriate discussion platforms, rather then engaging in the conversation on GitHub :) Thanks!
Change:
///    println!("{}", now.elapsed().as_secs()); /// } /// ``` <ins> /// /// # Underlying System calls /// Currently, the following system calls are being used to get the current time using `now()`: /// /// |  Platform |               System call                                            | /// |:---------:|:--------------------------------------------------------------------:| /// | Cloud ABI | [clock_time_get (Monotonic Clock)]                                   | /// | SGX       | [`insecure_time` usercall]. More information on [timekeeping in SGX] | /// | UNIX      | [clock_time_get (Monotonic Clock)]                                   | /// | Darwin    | [mach_absolute_time]                                                 | /// | VXWorks   | [clock_gettime (Monotonic Clock)]                                    | /// | WASI      | [__wasi_clock_time_get (Monotonic Clock)]                            | /// | Windows   | [QueryPerformanceCounter]                                            | /// [QueryPerformanceCounter]: https://docs.microsoft.com/en-us/windows/win32/api/profileapi/nf-profileapi-queryperformancecounter /// [`insecure_time` usercall]: https://edp.fortanix.com/docs/api/fortanix_sgx_abi/struct.Usercalls.html#method.insecure_time /// [timekeeping in SGX]: https://edp.fortanix.com/docs/concepts/rust-std/#codestdtimecode /// [__wasi_clock_time_get (Monotonic Clock)]: https://github.com/CraneStation/wasmtime/blob/master/docs/WASI-api.md#clock_time_get /// [clock_gettime (Monotonic Clock)]: https://linux.die.net/man/3/clock_gettime /// [mach_absolute_time]: https://developer.apple.com/library/archive/documentation/Darwin/Conceptual/KernelProgramming/services/services.html /// [clock_time_get (Monotonic Clock)]: https://github.com/NuxiNL/cloudabi/blob/master/cloudabi.txt /// /// **Disclaimer:** These system calls might change over time. /// </ins> #[derive(Copy, Clone, PartialEq, Eq, PartialOrd, Ord, Hash)] #[stable(feature = "time2", since = "1.8.0")] pub struct Instant(time::Instant);

Discussion:
Test Program: Error message on nightly [ 2019-09-02] and before: Error message since nightly [ 2019-09-03]: Diff Between the Nightlies: Reported by and in
I'm testing this with regression in Maybe cause it
cc -- I think we need to be more graceful by checking if liballoc exists or not or not requiring the language items.
PR show more suggestions on method take ,, or when method not found However, , and don't exist in , but in . Error message of this code:
Mentoring instructions: Change to return and use instead of .Make take in and call instead and return early . Also be sure to not use .Include tests like above and make sure to check for Box, Rc, and Arc.Use to update the tests.
Change:
<ins> // check-pass use std::borrow::Borrow; struct S; trait T: Sized { fn foo(self) {} } impl T for S {} impl T for &S {} fn main() { let s = S; s.borrow().foo(); s.foo(); } </ins>

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