jiebi/CodeConvo huggingface dataset:
Change:
} } <ins> /// Blocks the current thread until this condition variable receives a /// notification and the required condition is met. Spurious wakeups are /// ignored and this function will only return once the condition has been /// met. /// /// This function will atomically unlock the mutex specified (represented by /// `guard`) and block the current thread. This means that any calls /// to [`notify_one`] or [`notify_all`] which happen logically after the /// mutex is unlocked are candidates to wake this thread up. When this /// function call returns, the lock specified will have been re-acquired. /// /// # Errors /// /// This function will return an error if the mutex being waited on is /// poisoned when this thread re-acquires the lock. For more information, /// see information about [poisoning] on the [`Mutex`] type. /// /// [`notify_one`]: #method.notify_one /// [`notify_all`]: #method.notify_all /// [poisoning]: ../sync/struct.Mutex.html#poisoning /// [`Mutex`]: ../sync/struct.Mutex.html /// /// # Examples /// /// ``` /// use std::sync::{Arc, Mutex, Condvar}; /// use std::thread; /// /// let pair = Arc::new((Mutex::new(false), Condvar::new())); /// let pair2 = pair.clone(); /// /// thread::spawn(move|| { ///     let &(ref lock, ref cvar) = &*pair2; ///     let mut started = lock.lock().unwrap(); ///     *started = true; ///     // We notify the condvar that the value has changed. ///     cvar.notify_one(); /// }); /// /// // Wait for the thread to start up. /// let &(ref lock, ref cvar) = &*pair; /// // As long as the value inside the `Mutex` is false, we wait. /// cvar.wait_until(lock.lock().unwrap(), |started| { started }); /// ``` #[unstable(feature = "wait_until", issue = "47960")] pub fn wait_until<'a, T, F>(&self, mut guard: MutexGuard<'a, T>, mut condition: F) -> LockResult<MutexGuard<'a, T>> where F: FnMut(&mut T) -> bool { while !condition(&mut *guard) { guard = self.wait(guard)?; } Ok(guard) } </ins> /// Waits on this condition variable for a notification, timing out after a /// specified duration. ///

Discussion:
Yes, another incarnation of . and also have this issue. Note that is an error and has a test for it. cc
Does this also date back to 1.0, like did?
Yes. The fix would be technically a breaking change.
Change:
} fn visit_fn(&mut self, fn_kind: FnKind<'ast>, sp: Span, _: NodeId) { let rib_kind = match fn_kind { <del> FnKind::Fn(FnCtxt::Foreign, ..) => return visit::walk_fn(self, fn_kind, sp), FnKind::Fn(FnCtxt::Free, ..) => FnItemRibKind, </del> <ins> // Bail if there's no body. FnKind::Fn(.., None) => return visit::walk_fn(self, fn_kind, sp), FnKind::Fn(FnCtxt::Free, ..) | FnKind::Fn(FnCtxt::Foreign, ..) => FnItemRibKind, </ins> FnKind::Fn(FnCtxt::Assoc(_), ..) | FnKind::Closure(..) => NormalRibKind, }; let previous_value = replace(&mut self.diagnostic_metadata.current_function, Some(sp));

Discussion:
I'm seeing an internal compiler error on the following input (found by ):
Report from : regressed nightly: nightly-2020-02-07
It looks like caused the regression. (The error happens at but not at .) cc
The specific commit where the error starts happening is .
triage: P-high. Removing nomination. Added regression stable-to-nightly tag.
Fixed by
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. // Regression test for #20676. Error was that we didn't support // UFCS-style calls to a method in `Trait` where `Self` was bound to a // trait object of type `Trait`. See also `ufcs-trait-object.rs`. use std::fmt; fn main() { let a: &fmt::Show = &1_i32; format!("{:?}", a); } </ins>

Discussion:
Discovered this ICE in the rollup that I'm preparing:
In Grust, I tried to change to: The crate compiles without an issue, but compiling another crate where this is used results in an ICE that looks to be this one.
Looks like I missed a case in
Nominating for 1.0 beta.
Are there any known workarounds for this problem? I ran into this in a hard way trying to update to the newest nightlies.
not sure, I'll try to get a PR up today
a new type wrapper around the object would probably work, ping me on irc () for more details
I just wanna run iron example on MAC 10.10 with rust-nightly, the same error occurs, I don't know if it's of the same case: error: internal compiler error: static call to invalid vtable: VtableObject(VtableObject(object_ty=error::Error + 'static))
This is also blocking Iron, which itself compiles well, but using the crate fails:
Fix in , sorry for the delay.
thanks for the work! I pulled your PR and built with it, and my code compiles again. Hooray!
Change:
///   <br>Used to determine line-wrapping. /// * `indent`: The number of spaces to indent each successive line with, if line-wrapping is ///   necessary. <del> /// * `asyncness`: Whether the function is async or not. </del> pub(crate) fn full_print<'a, 'tcx: 'a>( &'a self, header_len: usize, indent: usize, <del> asyncness: hir::IsAsync, </del> cx: &'a Context<'tcx>, ) -> impl fmt::Display + 'a + Captures<'tcx> { <del> display_fn(move |f| self.inner_full_print(header_len, indent, asyncness, f, cx)) </del> <ins> display_fn(move |f| self.inner_full_print(header_len, indent, f, cx)) </ins> } fn inner_full_print( &self, header_len: usize, indent: usize, <del> asyncness: hir::IsAsync, </del> f: &mut fmt::Formatter<'_>, cx: &Context<'_>, ) -> fmt::Result {

Discussion:
produces: But I think it should be. For the HTML backend, rustdoc "resugars" the return type to get the from I think we should move this to a pass. cc does this change seem like a good idea. modify labels: +T-rustdoc +A-rustdoc-json
I'm not sure if it's worth adding a pass for this... Maybe handling this into a specific function shared between both formats could be a better idea?
We could call in . Or we could move this to when constructing . I'm not sure which makes most sense.
In directly seems like a good approach.
Change:
in_body: false, span: krate.span, empty_tables: &empty_tables, <ins> visited_anon_tys: FxHashSet() </ins> }; intravisit::walk_crate(&mut visitor, krate);

Discussion:
I guess this should be erroring with or E0666 (nested impl trait is not allowed).
Continues crashing in 1.26 stable.
This does not crash:
Particularly unfortunate because of and . <strikeWhat is going on here: There is a syntactical check to forbid nested impl Trait, but the default sneaks past that check, so we probably have to check for that substitution after lowering from HIR in type collection. Though it can also be done in the syntax check with some contortion.</strikeI was thinking that this shouldn't be allowed because it's like nested impl Trait, but is not at all like because the latter allows the inner type to be different from the outer one, while the former doesn't. So it might just be a case of fixing the overflow itself . I can take this myself but someone looking for mentorship or who is just faster is welcome.
Change:
`thumbv8m.base-none-eabi` | * | Bare ARMv8-M Baseline `thumbv8m.main-none-eabi` | * | Bare ARMv8-M Mainline `thumbv8m.main-none-eabihf` | * | Bare ARMv8-M Mainline, hardfloat <del> [`sparc-unknown-none-elf`](./platform-support/sparc-unknown-none-elf.md) | * | Bare 32-bit SPARC V7+ </del> `wasm32-unknown-emscripten` | ✓ | WebAssembly via Emscripten `wasm32-unknown-unknown` | ✓ | WebAssembly `wasm32-wasi` | ✓ | WebAssembly with WASI

Discussion:
lists sparc-unknown-none-elf as Tier 2, but it's Tier 3 as you don't build libcore for it. My bad - no idea how I managed to put it in the wrong table. It's not even alphabetically in the right place.
paging Sorry!
lmao whoops.
Change:
use crate::collections; use crate::panicking; use crate::sync::atomic::{AtomicU8, Ordering}; <del> use crate::sync::{Mutex, RwLock}; </del> <ins> use crate::sync::{Condvar, Mutex, RwLock}; </ins> use crate::thread::Result; #[doc(hidden)]

Discussion:
I expected to see this happen: No errors. This code compiles on Linux, as I would expect based on Condvar's documentation. Instead, this happened: When compiling on Mac OS, I get this error: On Linux, this code compiles correctly, and the hosted Rust document this type as UnwindSafe. I'm filing this issue to ask: Is the current MacOS implementation not actually UnwindSafe? My workaround for this issue is to wrap Condvar in AssertUnwindwSafe, but I would like to confirm this is actually safe. My personal hope is that these sync primitives are UnwindSafe and that this is a safe workaround. <!-- 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. --:
label O-macos T-libs
sounds like a bug, there's probably an implementation missing on some MacOS specific sys struct, the unwind safety traits are always forgotten feel free to send a PR adding it
Hi, is there any updates? I am seeing the same issue.
No updates because no one has fixed this yet. Feel free to make a PR and fix if yourself :)
Is it correct to assume that Condvar is supposed to be UnwindSafe on all platforms? My basic understanding of this is that Condvar should be UnwindSafe and, barring any surprises, the data structures should already be unwind safe and are simply not marked as such. it seems like this issue likely affects multiple platforms, as similar primitives are used across other Condvars without accompanying UnwindSafe impls. I'm happy to try to put together a PR that adds a test asserting unwind safety (similar tests exist for other data structures) if someone more knowledgeable than me can confirm it is the correct thing to do. This would be my first contribution, which is also why I'm hesitant to throw in a PR about something I'm not sure I fully understand.
What's a current state of this bug, please?
said they'd work on here, but nothing seems to have happened. If you want to, you can submit a PR fixing it.
Actually the current state is asking whether it is the correct behavior for all platforms or not. My last comment expressed how I do not have confidence to know that it's the right choice, and was looking for confirmation on the approach before beginning work.

Generally for these platforms, we would really like them all to be the same, otherwise it results in really confusing issues.
I do agree. A condition variable's behavior as a synchronization primitive should be consistent across platforms. If it is on Linux, it should also be on macOS.
Change:
<ins> // Copyright 2014 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. pub fn main() { const INPUT_TXT: &'static str = include_str!("input.txt"); const INPUT_BIN: &'static [u8] = include_bytes!("input.bin"); println!("{}", INPUT_TXT); println!("{:?}", INPUT_BIN); } </ins>

Discussion:
This causes cargo to misbehave: Tagging as E-easy, since the appropriate fix.
I'm going to try and fix this.
After reading the files and , I have come up with a plan. This is a little bit tricky, since with , we know that we are including utf-8 content, so it's safe to store the source as a String in a . We don't know that for , but I don't think we actually need to track the contents anyways, so I'm passing to . Currently building, I'll see if that fixes it.
This should have been Can someone with power close?
Indeed!
Change:
<ins> error[E0277]: the trait bound `(): std::ops::CoerceUnsized<*const [u8]>` is not satisfied --> $DIR/issue-44861.rs:21:5 | LL |     type Data2: CoerceUnsized<*const [u8]>; |     --------------------------------------- required by `Smartass::Data2` ... LL |     default type Data2 = (); |     ^^^^^^^^^^^^^^^^^^^^^^^^ the trait `std::ops::CoerceUnsized<*const [u8]>` is not implemented for `()` error: aborting due to previous error For more information about this error, try `rustc --explain E0277`. </ins>

Discussion:
This snippet is found in . Reduced: :
Nitpick: There's no need to put the two into different functions, you can put them both in .
Like , when using an anonymous binding (), the above code :
No longer ICEs since

With specialization, it is possible to define a default associated type that does not fulfill its trait bounds. Here is a minimal example, that surely should not compile, but does with rustc 1.35.0-nightly: Unsurprisingly, adding the main function causes an ICE. Error message and backtrace (compiled at the playground):
Triage: the latest nightly rejects the code, marking as E-needs-test.

This code generates an ICE with this message. Replacing by makes the code to compile and run fine, which is strange because ! does not implements . By removing the specialization the compiler refuses to compile the code with the error:
The ICE has been fixed in the latest nightly, marked as E-needstest
Thanks Indeed, the example compiles fine in nightly ( 2019-11-12), however, replacing the main function by these two generates the same ICE.
ah, thanks for the update! I confirmed it ()
Triage: the ICE doesn't occur anymore with the latest nightly, marking as E-needs-test.

I was attempting to figure out the feature landscape for , and I found this ICE when playing with it and specialization:
The given code builds fine on current nightly.
This is still an ICE on current nightly when not .
This code compiles without a problem whether I do or using current nightly: . Tested on Windows 10 x64 and Ubuntu x64.
Really? But on the playground, the ICE still appears. Can you check the above link?
Yes, I get an ICE in the playground when I just build.
It does ICE when using instead of .
You need or , not . It seems like a still ICE to me.
Triage: the latest nightly rejects the code without an ICE. Marking as E-needs-test.
Change:
<ins> error[E0369]: binary operation `+` cannot be applied to type `&str` --> $DIR/issue-47377.rs:13:12 | 13 |      let _a = b + ", World!"; |               ^^^^^^^^^^^^^^ `+` can't be used to concatenate two `&str` strings help: `to_owned()` can be used to create an owned `String` from a string reference. String concatenation appends the string on the right to the string on the left and may require reallocation. This requires ownership of the string on the left | 13 |      let _a = b.to_owned() + ", World!"; |               ^^^^^^^^^^^^ error: aborting due to previous error </ins>

Discussion:
This code (containing tabs) gives an error (): The error works fine on stable: But is mispositioned on rustc 1.25.0-nightly ( 2018-01-11) as well as on rustc 1.24.0-beta.2 ( 2018-01-10): cc
Interesting. Im new to code work so following you guys has been extremely helpful thanks
Using bisect-rust I could see that the issue started with , but probably the actual issue is somewhere else (e.g. in the machinery in that starts using for tabs).
Yeah, the issue also exists when emojis are involved (no tabs): Gives: The emoji manifestation of the issue is no beta regression, seems to exist on stable as well.
I've created for the emoji/unicode issue.
It seems to me that the issue only manifests itself in suggestions, and that is handled separately from the main diagnostics. Mentoring instructions:  needs to be modified to use instead of , the start being and the end being ( already accounts for unicode chars). This change should fix both this and .
Will pick this up
Change:
<ins> error[E0207]: the type parameter `T` is not constrained by the impl trait, self type, or predicates --> $DIR/issue-74244.rs:9:6 | LL | impl<T> Allocator for DefaultAllocator { |      ^ unconstrained type parameter error: aborting due to previous error For more information about this error, try `rustc --explain E0207`. </ins>

Discussion:
Compiled with: Using: Gives:
The problem is not tied to box:
No longer ICEs after
Ops, sorry, I reopen until a test is present.

: <details<summary<strongBacktrace</strong</summary<p</p</detailssearched nightlies: from nightly-2019-10-03 to nightly-2020-07-05 regressed nightly: nightly-2020-02-16 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.1</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with:
Minified, It seems possible to ICE on stable, though I'm not sure if it counts? <details<summaryStable error</summary</details
The ICE is fixed in the latest nightly, marking as .
Change:
<ins> error[E0207]: the type parameter `T` is not constrained by the impl trait, self type, or predicates --> $DIR/issue-74244.rs:9:6 | LL | impl<T> Allocator for DefaultAllocator { |      ^ unconstrained type parameter error: aborting due to previous error For more information about this error, try `rustc --explain E0207`. </ins>

Discussion:
This produces an ICE (): It points to this assert firing: This assert assumes that if we match on a with a const, then must be . I'm not sure where this assumption comes from (I'd guess byte-array patterns), but it's clearly wrong. Note that this also fails with any other non- type here instead of . Note that this does not fail when the arrays are not behind references, or if we use slices instead of arrays. EDIT: removed unnecessary feature gate
The feature gate isn't needed to trigger the ICE
Oh, well spotted. And it appears that fails on stable too then
cc as it's possible this is related to your structural match work I guess?
Funny enough: this doesn't ICE but instead shows the correct "unreachable" warning
Reduced:
What the heck?!?
triage: P-high. Removing nomination. Self-assigning.
That's a leftover from matching on byte strings, which used to be one of the few constants one could actually match on.
I think it's one more of theses cases where we don't know how to handle properly. shouldn't even exist: specialization should be able to specialize consts by unpacking a pattern into its subpatterns, like we specialize everything else.
I've figured out a way to eliminate the ICE, but I do not think my code has the desired semantics. That is, I would imagine we would want this to be accepted: but my current draft code rejects the above as non-exhaustive. On the other hand, that does match the current behavior of the compiler, for better or for worse. Update: Or maybe I've forgotten the desirata for how match usefulness and consts are supposed to interact...?
This was not a stable reduction; on the current nightly, the above length-zero ZST array is accepted with no ICE, while the original length-one ZST array still causes an ICE.
Yet another fun variation on the test: yields:
The reason it exists is that we don't want to unpack a multi megabyte byte string you may have gotten from . That would be super inefficient and likely just cause an out of memory abort. The reason why I believe we should also do this optimization for other types is that you can easily transmute a multi megabyte byte string to another array type in a constant, and then you have the same problem all over again.

(Or you init with a repeat expression). I agree that it would be nicer and less fragilr if we just unpacked everything.
Btw, addresses a few of the ICEs around this
Since the original and reduced versions no longer ICE, but still does
The above no longer ICEs after , could do with a test
Change:
UnusedImportBraces: UnusedImportBraces, UnsafeCode: UnsafeCode, AnonymousParameters: AnonymousParameters, <del> EllipsisInclusiveRangePatterns: EllipsisInclusiveRangePatterns, </del> <ins> EllipsisInclusiveRangePatterns: EllipsisInclusiveRangePatterns::new(), </ins> NonCamelCaseTypes: NonCamelCaseTypes, DeprecatedAttr: DeprecatedAttr::new(), ]);

Discussion:
The parameter is a hack (to fix ) that should be refactored. The idea is that the state should be contained in instead. This should be straightforward to fix. the parameter from (You'll also need to update the signature of in . a method with an identical signature below it. the condition from an early lint pass for at the end. a field to in (Look at for an example of a lint with fields.) You'll also need to initialise it with here: should be replaced with an assignment of the new field in to : should be early-exited if the field is . a implementation to and reset the field to if the pattern ID matches the field ID. sure the UI tests still pass with no changes.
hi I'm happy to take care of this one if it's not taken already.
go ahead! Let me know if you have any questions or problems with the implementation! :)
Change:
/// Build crtbegin.o/crtend.o for musl target. fn run(self, builder: &Builder<'_>) -> Self::Output { <ins> builder.update_submodule(&Path::new("src/llvm-project")); </ins> let out_dir = builder.native_dir(self.target).join("crt"); if builder.config.dry_run() {

Discussion:
I cloned the Rust repo with the intention of building rustc for cross-compilation to the target. I did the following: selected the "codegen" option the file to append: This failed; the end of the output is as follows: After I executed and retried the build command, the LLVM submodule was checked out and the build was able to make progress. It seems like this should be done automatically. I'm not sure if the issue is specific to this target or if it's happening with other cross-compilation targets. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Hmm. This is some interaction between and cross-compiling, but I'm not sure exactly what — it should be a no-op unless you're building for the host. As a workaround you can set and that should handle the submodule automatically.
(Note that is implied by .)
Ok, it looks like we only try to build crtbegin.o for musl targets: So I think we would have checked out the submodule if we were doing a full LLVM build, but because we're only building the CRT it got missed when download-ci-llvm was implemented. I think the simplest fix is to call at the start of , like we do for the step:
looks like it also has the same bug: as well as :
claim
Does fixing also come under the scope of this issue? I'd be happy to fix that as well.
sure thing, feel free to fix all three at once :)
Do I pause work on this till gets resolved? Since it's implementing the workaround you mentioned as a solution
no, this fix still makes sense - not everyone is using the profile without changes.