jiebi/CodeConvo huggingface dataset:
Change:
fn add_borrow_suggestions(&self, err: &mut Diag<'_>, span: Span) { match self.infcx.tcx.sess.source_map().span_to_snippet(span) { Ok(snippet) if snippet.starts_with('*') => { <del> err.span_suggestion_verbose( span.with_hi(span.lo() + BytePos(1)), "consider removing the dereference here", String::new(), Applicability::MaybeIncorrect, ); </del> <ins> let sp = span.with_lo(span.lo() + BytePos(1)); let inner = self.find_expr(sp); let mut is_raw_ptr = false; if let Some(inner) = inner { let typck_result = self.infcx.tcx.typeck(self.mir_def_id()); if let Some(inner_type) = typck_result.node_type_opt(inner.hir_id) { if matches!(inner_type.kind(), ty::RawPtr(..)) { is_raw_ptr = true; } } } // If the `inner` is a raw pointer, do not suggest removing the "*", see #126863 // FIXME: need to check whether the assigned object can be a raw pointer, see `tests/ui/borrowck/issue-20801.rs`. if !is_raw_ptr { err.span_suggestion_verbose( span.with_hi(span.lo() + BytePos(1)), "consider removing the dereference here", String::new(), Applicability::MaybeIncorrect, ); } </ins> } _ => { err.span_suggestion_verbose(

Discussion:
Cloning the pointer doesn't make sense in that situation and would cause a type mismatch error. I'm not sure whether any of the two current suggestions should be kept or removed in this case. No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Note that this works: It works because is a place expression and then we attach to that, which then reborrows the String. I don't think we should suggest , which may have undesirable or unexpected effects in the case of things like types that handle backing buffers, instead of issuing a safe which will recreate the backing allocation correctly.
I didn't know that was possible, thanks for letting me know. I guess that the best approach would then be to change the suggestion accordingly as below?
Correct. Also, we could mention in the error for pointers, but we shouldn't recommend it. It's unsafe code, we should strive to preserve the "you break it, you buy it" / "do your own research" experience for that.
The relevant section of diagnostic code is here but it will require some restructuring to account for the fact that the suggestion will not be doing things like stripping parentheses, but suggesting adding them if they don't exist.
claim It looks good for me to make a try.
Change:
assert_eq!(vec![1, 2, 3].into_iter().count(), 3); } <ins> #[test] fn test_cow_from() { let borrowed: &[_] = &["borrowed", "(slice)"]; let owned = vec!["owned", "(vec)"]; match (Cow::from(owned.clone()), Cow::from(borrowed)) { (Cow::Owned(o), Cow::Borrowed(b)) => assert!(o == owned && b == borrowed), _ => panic!("invalid `Cow::from`"), } } </ins> #[bench] fn bench_new(b: &mut Bencher) { b.iter(|| {

Discussion:
Both Vec<Tand &[T] are missing From impls for Cow, unlike String/&str and PathBuf/&Path. Coherence is not (afaict) an issue, since the impl would be in the same crate as Cow. Is there some reason these don't exist (do they cause coherence issues in downstream crates or something)?
Whoa, I have no idea why these aren't implemented... Should be good to go ahead and add them! Want to send a PR?
Change:
= note: this lint makes sure the compiler doesn't get stuck due to infinite loops in const eval. If your compilation actually takes a long time, you can safely allow the lint. help: the constant being evaluated <del> --> $DIR/infinite_loop.rs:4:18 </del> <ins> --> $DIR/infinite_loop.rs:10:18 </ins> | <del> LL |       let _ = [(); { </del> <ins> LL |       let s = [(); { </ins> |  __________________^ LL | |         let mut n = 113383; // #20 in https://oeis.org/A006884 LL | |         while n != 0 {

Discussion:
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
Regression in nightly-2023-06-02 Regression in cc
Change:
## Attributes ~~~~ {.notrust .ebnf .gram} <del> attribute : '#' '!' ? '[' attr_list ']' ; attr_list : attr [ ',' attr_list ]* ; attr : ident [ '=' literal | '(' attr_list ')' ] ? ; </del> <ins> attribute : '#' '!' ? '[' meta_item ']' ; meta_item : ident [ '=' literal | '(' meta_seq ')' ] ? ; meta_seq : meta_item [ ',' meta_seq ]* ; </ins> ~~~~ Static entities in Rust &mdash; crates, modules and items &mdash; may have _attributes_

Discussion:
According to the manual, multiple comma-separated attributes may be specified within a single pair of square brackets. The parser does not do this at present (). Which one is correct? Use case:
I believe the manual is correct in this case, that looks like it should be a valid attribute.
But, which is the behaviour we want?
Yes, I could imagine either scheme becoming blessed as the preferred style, so I feel this needs more discussion if it hasn't already been decided. Either way, there will need to be a test to preserve the preferred style in the future.
Nominating.
Not a 1.0 milestone issue, Asssigning P-low.
IMO, we should not accept a comma in attributes. We never used that feature, I've long wanted to remove it, and didn't realize that it was broken.
Change:
<ins> // run-pass //! This snippet causes the type length to blowup exponentially, //! so check that we don't accidentially exceed the type length limit. // FIXME: Once the size of iterator adaptors is further reduced, // increase the complexity of this test. fn main() { let c = 2; let bv = vec![2]; let b = bv .iter() .filter(|a| **a == c); let _a = vec![1, 2, 3] .into_iter() .filter(|a| b.clone().any(|b| *b == *a)) .filter(|a| b.clone().any(|b| *b == *a)) .filter(|a| b.clone().any(|b| *b == *a)) .filter(|a| b.clone().any(|b| *b == *a)) .filter(|a| b.clone().any(|b| *b == *a)) .filter(|a| b.clone().any(|b| *b == *a)) .filter(|a| b.clone().any(|b| *b == *a)) .filter(|a| b.clone().any(|b| *b == *a)) .filter(|a| b.clone().any(|b| *b == *a)) .filter(|a| b.clone().any(|b| *b == *a)) .filter(|a| b.clone().any(|b| *b == *a)) .filter(|a| b.clone().any(|b| *b == *a)) .filter(|a| b.clone().any(|b| *b == *a)) .filter(|a| b.clone().any(|b| *b == *a)) .collect::<Vec<_>>(); } </ins>

Discussion:
I started to get the following error with my nightly builds around two days ago: Using I got the following commit and after building rustc manually I got down to this PR. After poking around my project I found the method in here was causing the issue (stubbing out the method fixed the error) but I haven't been able to reproduce this outside of my codebase (this code is used as a separate crate) Following the on the error causes the error still to happen until increasing it to Sorry I can't be more helpful with a way to reproduce this at the moment
This might be expected, since types used internally can change without notice, and your code might have been getting pretty close to the length limit even before that. Are you chaining/nesting a lot of types (iterators or futures)?
I use iterator chains quite a bit. The thing that confused me was why doubling the limit to wasn't enough and I had to go all the way to which seems like a huge jump.
Played around on the playground and got this silly example: On stable this compiles but on nightly you have to increase the type length limit past the initial suggestion all the way to . So chances are I have something similar in my code (filter inside a filter) and changes are just amplified in my case.
potentially related to
assigning P-high for now since this is a stable-to-beta regression. Given that its already been narrowed down to PR ... this may be a T-libs issue rather than T-compiler one? Not sure.
I would normally also remove the nomination tag, since I do not think there is much for T-compiler to discuss here apart from the severity of the regression. But since it is potentially related to , I figured I'll leave the nomination tag for now, just to help ensure that when we discuss , we will hopefully remember to take note of this issue () as well.
triage: Under assumption that this is duplicate of , I'm going to downgrade this to P-medium and remove the nomination tag.
Afaict this issue can now be closed as the blowup of iterator adapters has been reduced and is used to track the more general problem.
Change:
<del> #[link(name="library")] extern "C" { fn foo(); } fn main() { unsafe { foo(); } } </del>

Discussion:
when running locally I get errors in the test : The most notable part being this: perhaps related to the linker on my system?
Compiler team pre-triage: marking as P-medium, this is probably something wacky in my local setup. We'll see if others complain about it.
I have also seen this in Fedora and RHEL builds, but I didn't worry enough to chase it down yet. This error is actually from itself: Arguments 5 and 6 from the command in your report are: -L /home/nmatsakis/versioned/rust-6/build/x8664-unknown-linux-gnu/test/run-make-fulldeps/linker-output-non-utf8/linker-output-non-utf8/zzz$'xff' That line is deliberately in the test: I have no idea why this isn't an issue in CI though...
Oh, I think I do know why. That in the Makefile is assuming shell expansion of that (with doubled to escape from itself). Fedora and RHEL use -which does expand it, but Debian and Ubuntu (used in CI) have -, which is a more limited shell. bash: dash: So I think this test hasn't really been working as desired on -using platforms at all, since the isn't really "bad" when not escaped. And it can't work even then because won't accept non-utf8 arguments in the first place, never mind reaching the linker.
Note, the and builders do use CentOS 5 as the base image, which would have this issue too, but we don't actually run tests there. It would be nice to add some diversity to the testing images, either with Fedora or perhaps the redistributable .
Any idea what to do with this test? Having to use for over two weeks isn't very practical.
We can probably just remove that test, it doesn't seem worth the pain of having it if it's causing people problems. It sounds like we don't have a test case that would work universally even on *nix platforms, right? Or that's my interpretation of at least. It's also pretty unclear to me that ICE-ing on non-utf8 output from linkers is something we need to test for. That sounds both incredibly uncommon, and also pretty easily fixable if we need to.

One thought for testing this is to override the linker rustc uses with a shell script or even a rust program that runs the linker internally but just does something like or with some non-utf8 output.
This test continues to be super annoying. I'm happy to just remove it, per suggestion.
Okay I've filed to remove the test -- seems like everyone is in agreement it does not pull its weight.
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. fn main() { let mut t = [1; 2]; t = [t[1] * 2, t[0] * 2]; assert_eq!(&t[..], &[2, 2]); } </ins>

Discussion:
Assigning to a mutable vector causes it to be modified in-place even if the right side of the assignment references it. On IRC, pointed me to , which might be related.
Nominating. This may not be a 1.0 backcompat-lang issue though as it seems fairly rare.
Same thing with structs:
OK, same thing happens with enums, which is a bit more serious since it now affects memory safety.
I believe this problem is in trans -- it is supposed to used a temporary buffer for these sorts of cases, but obviously that check is not working correctly.
Team believes this to be a miscompilation issue (and not, as we feared at first, a failure of the borrow-checker to reject an incorrect program). That is, these programs should be compilable; the problem is that the generated code is wrong. P-high, not 1.0.
All of the code examples from this ticket seem to work now: So I think this just needs regression tests.
Change:
main_thread_worker_state = MainThreadWorkerState::Idle; } Message::Done { result: Err(()), worker_id: _ } => { <del> shared_emitter.fatal("aborting due to worker thread failure"); // Exit the coordinator thread return Err(()) </del> <ins> bug!("worker thread panicked"); </ins> } Message::CodegenItem => { bug!("the coordinator should not receive codegen requests")

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:
///    destroyed, but not all platforms have this guard. Those platforms that do ///    not guard typically have a synthetic limit after which point no more ///    destructors are run. <del> /// 3. On macOS, initializing TLS during destruction of other TLS slots can ///    sometimes cancel *all* destructors for the current thread, whether or not ///    the slots have already had their destructors run or not. </del> /// /// [`with`]: ../../std/thread/struct.LocalKey.html#method.with /// [`thread_local!`]: ../../std/macro.thread_local.html

Discussion:
Moved from because the issue is not specific to . Repro: toolchain: rustc 1.33.0-nightly ( 2019-01-10) OSX 10.14 If thread is changed to access before exiting, then the ASAN error goes away. <details<summaryAddress Sanitizer Log</summary<p</p</details
Might be related to / caused by
Looking at the for and , it sure looks like UB to call during which lldb shows is happening in this example. This is worse than just not running tls destructors for the main thread. It is unsound AFAICT.
Thanks for debugging this I wonder if we can fix this on our end? We might be able to prevent new TLS slots from being initialized after a thread has exited perhaps?
I don't know how to reliably detect that a thread is exiting using the APIs that OSX provides (there could be a way). The logic in Apple's looks similar to what already exists in , except that handles destructor registering during thread exit properly AFAICT. Perhaps we could call into that . FWIW C++ has similar problems with "static local" thread locals when compiled by appleclang.
Makes sense yeah, perhaps as a fallback solution we could just fix this issue for Rust-spawned threads? For those we know exactly when they're exiting (or at least when user-written Rust code has ceased executing) and that may be enough too! Skipping may also be reasonable and we already do that on a number of other platforms too
visiting for T-compiler triage. Retagged as T-libs.
Filed an apple bug report.
Change:
// run-pass <del> #![feature(const_unreachable_unchecked)] </del> const unsafe fn foo(x: bool) -> bool { match x { true => true,

Discussion:
Currently one cannot call in constant functions, so one cannot add hints of the form: These types of hints can heavily influence code generation, which can substantially change the performance of when they are invoked at run-time. It would be a shame to have to write and call and because the code generated for is sub-par. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
One cannot do any sort of conditional control flow, so would currently be less than useless. Any test you can write would be undefined behaviour
the RFC for / in const was merged and is pending an implementation right? When that's implemented, will still be useless?
No it makes sense after we have conditional control flow.
As I understand / in const functions is now implemented. Can be made into a now?
yes. Basically you just need to add the attribute to the intrinsic and wrapper function. This is documented at https://rustc-dev- Let me know if anything is unclear (in which case we should update the guide)
Hi, It looks like previous PR is not being worked on currently. I'm working on this and will create a PR soon. claim
As mentioned in , this issue should be reopened (to track stablization)
cc ^
After a short discussion on Zulip, it was decided that it's best to wait for to stabilize to avoid a potential footgun wherein users use this instead of , leading to UB at runtime. I'm subscribed to the issue and intend to file a PR to stabilize this once the aforementioned happens.
Change:
err_ty_str = format!("`{}`", ty); Some(err_ty_str.as_str()) } <del> } }; if let Some(unsupported_type) = err { if is_ptr { tcx.sess.span_err( hir_ty.span, &format!( "using {} as const generic parameters is forbidden", unsupported_type ), ); } else { let mut err = tcx.sess.struct_span_err( hir_ty.span, &format!( "{} is forbidden as the type of a const generic parameter", unsupported_type ), ); err.note("the only supported types are integers, `bool` and `char`"); if tcx.sess.is_nightly_build() { err.help( </del> <ins> }; if let Some(unsupported_type) = err { if is_ptr { tcx.sess.span_err( hir_ty.span, &format!( "using {} as const generic parameters is forbidden", unsupported_type ), ); } else { let mut err = tcx.sess.struct_span_err( hir_ty.span, &format!( "{} is forbidden as the type of a const generic parameter", unsupported_type ), ); err.note("the only supported types are integers, `bool` and `char`"); if tcx.sess.is_nightly_build() { err.help( </ins> "more complex types are supported with `#![feature(adt_const_params)]`", ); <ins> } err.emit(); </ins> } <del> err.emit(); } }; if traits::search_for_structural_match_violation(param.span, tcx, ty).is_some() { // We use the same error code in both branches, because this is really the same // issue: we just special-case the message for type parameters to make it // clearer. if let ty::Param(_) = ty.peel_refs().kind() { // Const parameters may not have type parameters as their types, // because we cannot be sure that the type parameter derives `PartialEq` // and `Eq` (just implementing them is not enough for `structural_match`). struct_span_err!( tcx.sess, hir_ty.span, E0741, "`{}` is not guaranteed to `#[derive(PartialEq, Eq)]`, so may not be  used as the type of a const parameter", ty, ) .span_label( hir_ty.span, format!("`{}` may not derive both `PartialEq` and `Eq`", ty), ) .note( "it is not currently possible to use a type parameter as the type of a  const parameter", ) .emit(); } else { struct_span_err!( tcx.sess, hir_ty.span, E0741, "`{}` must be annotated with `#[derive(PartialEq, Eq)]` to be used as  the type of a const parameter", ty, ) .span_label( hir_ty.span, format!("`{}` doesn't derive both `PartialEq` and `Eq`", ty), ) .emit(); </del> } } }

Discussion:
Given the following code (): Rust gives a diagnostic suggesting deriving : However, adding leads the compiler to still give an error about not supporting this. A non-nightly compiler should not give the second error at all; it should only give the first, saying that the only supported types are integers, and . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
assigning this to project-const-generics, getting worked on in https://rust-
claim
To fix this issue, you can do the following steps: grep for "forbidden as the type of a const generic parameter" look at that function for a bit change it so that the second error isn't emitted on stable (probably actually change the control flow to start by branching on In case you are interested but need more help to fix this, feel free to reach out to me on
claim
Change:
--> $DIR/issue-105330.rs:19:11 | LL |     foo::<Demo>(); <del> |           ^^^^ types differ </del> <ins> |           ^^^^ expected `32`, found `<Demo as TraitWAssocConst>::A` </ins> | <ins> = note: expected constant `32` found constant `<Demo as TraitWAssocConst>::A` </ins> note: required by a bound in `foo` --> $DIR/issue-105330.rs:11:28 |

Discussion:
thread panicked at 'called on a value', <details<summaryBacktrace</summary</detailsRegression in nightly-2022-12-04, in rollup , likely from (
Change:
f1: isize, f2: X, } <del> enum E<X: ?Sized> { V1(X), V2{x: X}, V3(isize, X), V4{u: isize, x: X}, } </del> pub fn main() { }

Discussion:
Backtrace: This seems to occur when using a non-struct type that contains an unsized type. This is probably because  only handles and the base unsized types. This should be extended to handle enums and tuples as well.
This is still happening. Does this mean we should avoid using DSTs for complex custom types for now?
Visiting for triage This is still an issue:
ICE also happens with a tupled trait object:
I've seen this too with: Reproducer: Version: Backtrace:
No longer reproduces but the other tests do.
cc
Is this the same as or related to ?
leads to . As mentioned inline, using the correct type works (). I'm using the Ubuntu PPA "rust-nightly", version ~~vivid.
Does not compile for other reasons that the ICE anymore. I've adjusted to the following and could not reproduce it anymore.
Another example hitting this same ICE:
Bugs similar to this one have been reported numerous times (most of the references to this issue are duplicates). Although it would be nice for reporters to search for similar issues before filing a new one, it's hard to blame them, since the ICE message from rustc tells people to file an issue. This issue itself was opened over two years ago. Separate from fixing the underlying problem, we should at least investigate displaying a real error instead of an ICE.
Change:
pub fn process_token(&mut self, token: Token) -> TokenStream { match token.kind { <ins> token::Interpolated(nt) if let token::NtIdent(ident, is_raw) = *nt => { TokenTree::Token(Token::new(token::Ident(ident.name, is_raw), ident.span)).into() } </ins> token::Interpolated(nt) => { let tts = (self.nt_to_tokenstream)(&nt, self.parse_sess, self.synthesize_tokens); TokenTree::Delimited(

Discussion:
As of , some of our code utilizing macros in [] started to fail to compile. The code that is failing is some macro magic for making nice pin name aliases for microcontrollers, so it's not surprising that broke it. I see that some other repos were broken as well and that helped fix it, but I'm really not sure how to do the fix in our repo. To reproduce: clone the [] repo I expect this to compile properly like on stable, instead it fails to compile with: It most recently worked on: Regressed to with () : modify labels: +regression-from-stable-to-nightly -regression-untriaged []:
Fixed in
Thanks for the quick fix!