jiebi/CodeConvo huggingface dataset:
Change:
X86_64, X86_64_macabi, Arm64_macabi, <ins> Arm64_sim, </ins> } fn target_cpu(arch: Arch) -> String {

Discussion:
Currently in our application we cannot run the iOS simulator on M1 machines because it is expecting architecture. Forcing using the target can build the project and ship the application but this targets the iOS Device SDK, and will not build in the simulator for testing with this error: should provide an target that uses the iOS Simulator SDK.
Is relevant at all? Can the same path be followed?
Awesome find I'll try doing this! If successful I'll open a similar PR :)
Ran into this now too. Happy to help here as well. Did you already get started?
I did but having trouble I've pushed my changes here: More than happy to work with you on this Jan!
I'll try to get a dev environment set up and then I'll take a look.
I built the toolchain successfully, but when I try to compile my project (with either or ) I'm getting: I think I've missed a setting in the build config I'm using, because the normal nightly compiles fine :( : Edit looks like I will try off :
Yeah, that looks like upstream breakage in because of recent changes. I can try taking your code tomorrow and throw this against my project to see if that fixes my simulator issues.
Yeah I the patch mentioned in that issue and am getting further but: which Xcode still seems to be getting x8664 somewhere: I tried replacing all the with and got closer: but got:
I believe my current version is working but there's something off in my Xcode project that I need to figure out:
Ah, you're building a binary? Yeah, that seems to sort-of work now? I managed to build your branch, my static library is still unchanged. I think we actually need LLVM 12 first to fully enable this ().
It was just a test to see if the simulator is working at all XD. Yeah my file is still saying it's :
Change:
// TODO(antoyo) } <ins> fn type_metadata(&mut self, _function: RValue<'gcc>, _typeid: String) { // Unsupported. } fn typeid_metadata(&mut self, _typeid: String) -> RValue<'gcc> { // Unsupported. self.context.new_rvalue_from_int(self.int_type, 0) } </ins> fn store(&mut self, val: RValue<'gcc>, ptr: RValue<'gcc>, align: Align) -> RValue<'gcc> { self.store_with_flags(val, ptr, align, MemFlags::empty()) }

Discussion:
The following code from the manual fails with rustboot .
How embarrassing. Thanks for the report, I'll look into it.
Fix mem op= mem bug in (via not terribly good fix). Closed by .
Change:
<ins> error[E0277]: the trait bound `<T as Base>::Base<C>: Functor<C>` is not satisfied --> $DIR/method-chain-gats.rs:18:20 | LL |     input.fmap(f1).fmap(f2) |                    ^^^^ the trait `Functor<C>` is not implemented for `<T as Base>::Base<C>` | note: the method call chain might not have had the expected associated types --> $DIR/method-chain-gats.rs:13:29 | LL | fn fmap2<T, A, B, C>(input: T, f1: impl Fn(A) -> B, f2: impl Fn(B) -> C) -> T::Base<C> |                             ^ `Base::Base` is `<T as Base>::Base<_>` here note: required by a bound in `Functor::fmap` --> $DIR/method-chain-gats.rs:10:24 | LL |     fn fmap<B>(self, f: impl Fn(A) -> B) -> Self::Base<B> |        ---- required by a bound in this associated function LL |     where LL |         Self::Base<B>: Functor<B>; |                        ^^^^^^^^^^ required by this bound in `Functor::fmap` help: consider further restricting the associated type | LL |     T::Base<B>: Functor<B, Base<C> = T::Base<C>>, <T as Base>::Base<C>: Functor<C> |                                                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0277`. </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. --issue appeared when going from 1 -2, was able to fix it by adding 3 <!-- 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
I've only skimmed the code but this is very likely due to the diagnostic method constructing a projection, more precisely an , with created for the trait item, not the associated type (with (pseudo) ), so we're missing the own generic arguments for the GAT.
Change:
} } <ins> fn suggest_add_clone_to_arg( &self, obligation: &PredicateObligation<'tcx>, err: &mut Diagnostic, trait_pred: ty::PolyTraitPredicate<'tcx>, ) -> bool { let self_ty = self.resolve_vars_if_possible(trait_pred.self_ty()); let ty = self.tcx.erase_late_bound_regions(self_ty); let owner = self.tcx.hir().get_parent_item(obligation.cause.body_id); let Some(generics) = self.tcx.hir().get_generics(owner.def_id) else { return false }; let ty::Ref(_, inner_ty, hir::Mutability::Not) = ty.kind() else { return false }; let ty::Param(param) = inner_ty.kind() else { return false }; let ObligationCauseCode::FunctionArgumentObligation { arg_hir_id, .. } = obligation.cause.code() else { return false }; let arg_node = self.tcx.hir().get(*arg_hir_id); let Node::Expr(Expr { kind: hir::ExprKind::Path(_), ..}) = arg_node else { return false }; let clone_trait = self.tcx.require_lang_item(LangItem::Clone, None); let has_clone = |ty| { self.type_implements_trait(clone_trait, [ty], obligation.param_env) .must_apply_modulo_regions() }; let new_obligation = self.mk_trait_obligation_with_new_self_ty( obligation.param_env, trait_pred.map_bound(|trait_pred| (trait_pred, *inner_ty)), ); if self.predicate_may_hold(&new_obligation) && has_clone(ty) { if !has_clone(param.to_ty(self.tcx)) { suggest_constraining_type_param( self.tcx, generics, err, param.name.as_str(), "Clone", Some(clone_trait), ); } err.span_suggestion_verbose( obligation.cause.span.shrink_to_hi(), "consider using clone here", ".clone()".to_string(), Applicability::MaybeIncorrect, ); return true; } false } </ins> fn suggest_add_reference_to_arg( &self, obligation: &PredicateObligation<'tcx>,

Discussion:
we should suggest cloning. Also, we should suggest <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
If we suggest add bound, we don't need dervie , This code will compile:
Change:
#[inline] #[stable(feature = "rust1", since = "1.0.0")] pub fn swap_remove(&mut self, index: usize) -> T { <ins> let len = self.len(); assert!(index < len); </ins> unsafe { // We replace self[index] with the last element. Note that if the <del> // bounds check on hole succeeds there must be a last element (which </del> <ins> // bounds check above succeeds there must be a last element (which </ins> // can be self[index] itself). <del> let hole: *mut T = &mut self[index]; let last = ptr::read(self.get_unchecked(self.len - 1)); self.len -= 1; </del> <ins> let last = ptr::read(self.as_ptr().add(len - 1)); let hole: *mut T = self.as_mut_ptr().add(index); self.set_len(len - 1); </ins> ptr::replace(hole, last) } }

Discussion:
To my knowledge, the following code is intended to be legal: However, Miri currently flags this as UB. I believe this is , but for . Discovered while writing . cc
Yeah this looks pretty similar. uses under the hood though, so I wonder why the issue still exists here. Looks like is implemented via -- and indeed, this errors, too:
The problem is in this line: The here is a slice method, so this creates a slice covering the entire , which overlaps with the mutable reference created before and thus invalidates it.
It shouldn't be too hard to locally fix this, but that duplicates some code and there are some other uses of in . Ideally, this would all use raw slices to avoid making any uniqueness promises. But without , raw slices are not very useful.
Here's a possible fix:
Fix PR is up:
Change:
<ins> // check-pass pub trait D {} pub struct DT; impl D for DT {} pub trait A<R: D>: Sized { type AS; } pub struct As<R: D>(R); pub struct AT; impl<R: D> A<R> for AT { type AS = As<R>; } #[repr(packed)] struct S(<AT as A<DT>>::AS); fn main() {} </ins>

Discussion:
Minimal example:
can you reproduce?
I can try, this is from Mar 2nd so not related to my recent changes right?
yes it fails for me with both stable rust 1.25 and the latest nightly rustc 1.27.0-nightly ( 2018-04-11). It's not failing in a part of typeck that I'm familiar with but I'll have a look sometime and see if it makes any sense to me.
Yes this is unrelated to that PR (I think there isn't a nightly including it yet). But since this is related to I thought you might want to take a look.
I started expanding the minimal example so that it didn't depend on nalgebra, it has expanded into quite a lot of code This example is enough to break the compiler but doesn't compile if the ICE is fixed (e.g. if the is commented out). For it to compile it still needs some external dependencies. It appears to be the associated type that is hitting the ICE.
Yeah 's example is huge. Maybe he doesn't know that minimal examples should have no dependencies. if you don't provide minimal examples in bug reports (that is: no dependencies; they should compile in the play ground) they'll take much longer than necessary to fix.
I understand. I'm a relative beginner to rust, so it would take quite a lot of time for me to figure out how to make a more minimal example. I am able to work around this issue in my own code, so it's not that important to me, but I figured it might be easy for someone more experienced to spot what was going wrong. If you don't think it's worth the effort to investigate further, I have no problem with you closing this until a more simple manifestation is discovered.
I've reduced it to the following ():
It's no longer reproduced an ICE on the latest nightly, it seems from 1.38.0. marked as E-needstest
Change:
} #[derive(LintDiagnostic)] <ins> #[diag(passes_doc_test_literal)] pub struct DocTestLiteral; #[derive(LintDiagnostic)] </ins> #[diag(passes_doc_test_takes_list)] pub struct DocTestTakesList;

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. --This is a fuzzed test case, found with and minimized with , and did not find any related issues. I was able to reproduce with a compiler I compiled from . <!-- 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 --
claim
label +S-bug-has-mcve
Change:
<ins> // ignore-tidy-filelength </ins> //! Lints in the Rust compiler. //! //! This contains lints which can feasibly be implemented as their own

Discussion:
I propose we add a lint that detects code like Some people seem to think that this is okay in contexts like or , but that is not the case -- on a NULL pointer is UB even as a place expression. To implement this, you can use the lint as a template: should check for  expressions with a operator, and then check the operand to be either a cast of to a pointer type, or a call to one of the methods. To detect the methods, make them "diagnostic items"; the lint does that e.g. for so it can again serve as a template here. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Ah, turns out clippy already has a lint for this: . So maybe we should just move that to rustc? Cc
claim
awesome. :) Let me know if you need any help.
Thanks :)
Did you mean something slightly different with your "okay in contexts like" examples, perhaps? Neither of those two actually compile as written, since they're just attempts to deference something that isn't even a pointer. You get: in both cases.
oops I screwed up the casts, should be fixed now.
Yeah, happy to have Clippy lints upstreamed to rust, let us know when it's done so we can deprecate it on our end
for detecting a call like you said to use . However I do not know what to use for the symbol argument. There is that defines symbol but nothing looks like creating a null ptr. Should I add one what should it look like ?
You first need to add the diagnostic item attribute to the relevant function inside , like so: This name must be globally unique, e.g. and . Then you add those names to the list in (please keep it alphabetically sorted), and then you can use them for .
Change:
} #[stable(feature = "rust1", since = "1.0.0")] <del> impl<T> error::Error for SendError<T> { </del> <ins> impl<T: Send> error::Error for SendError<T> { </ins> fn description(&self) -> &str { "sending on a closed channel"

Discussion:
currently requires , while requires . I'm unsure of what each should require, but I think they should agree so that it is possible to have code which returns (which is useful to allow try! across functions returning different types of error codes), and be able to the results.
There was a lengthy discussion about this towards the bottom of the RFC:
/cc , I vaguely remember this might change? If not, then this should be in the RFCs repo.
Nominating for 1.0-beta P-backcompat-libs. (The trait isn't yet, but it probably will be for 1.0).
0 beta, P-backcompat-libs, I-needs-decision.
Change:
Store(bcx, C_u8(bcx.ccx(), DTOR_NEEDED as usize), ptr); } Store(bcx, C_integral(ll_inttype(bcx.ccx(), ity), discr as u64, true), <del> GEPi(bcx, val, &[0, 0])) </del> <ins> GEPi(bcx, val, &[0, 0])); </ins> } Univariant(ref st, dtor) => { assert_eq!(discr, 0);

Discussion:
The attached source produces code that misbehaves on some platforms that are picky about memory access alignment. The code should exit with code 2, but on both Emscripten-generated JavaScript and ARMv5, it finishes with exit code 1 to indicate that the field is incorrectly tested as equal to . Changing the field to a type results in proper execution on these platforms. All optimization levels seem to cause it. Libraries that make use of structs with fields followed by enums seem particularly prone to this problem. It all works fine on platforms that allow unaligned memory access like x86, ARMv6, etc. Expected output: (x86, ARMv6) Actual output: (ARMv5, Emscripten) Note that the same ARM binary runs on both ARMv5 and ARMv6 platforms, producing the different results. See also: ( and removed)
To quote myself:
Change:
if { return } { } <ins> // regression test for https://github.com/rust-lang/rust/issues/106899 return { println!("!") }; //~^ WARN unnecessary braces </ins> }

Discussion:
The false negative bisects to , so pretty obviously . FYI From skimming , that's an issue about const generics. It doesn't seem like the PR was supposed to have affected unused_braces situations outside of const generics position.
Change:
LL | extern "rust-call" fn b(_i: i32) {} | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ <del> error: aborting due to previous error </del> <ins> error: A function with the "rust-call" ABI must take a single non-self argument that is a tuple --> $DIR/issue-22565-rust-call.rs:9:5 | LL |     extern "rust-call" fn b() {} |     ^^^^^^^^^^^^^^^^^^^^^^^^^ error: A function with the "rust-call" ABI must take a single non-self argument that is a tuple --> $DIR/issue-22565-rust-call.rs:16:5 | LL |     extern "rust-call" fn bar() {} |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: A function with the "rust-call" ABI must take a single non-self argument that is a tuple --> $DIR/issue-22565-rust-call.rs:21:5 | LL |     extern "rust-call" fn a() {} |     ^^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to 4 previous errors </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. --code from <!-- 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 --<!-- TRIAGEBOTEND --
This crashes on master/nightly but not on
This is an overlooked case for , I can add it to the type-checking claim
I couldn't find a regression-from-beta-to-nightly label so using label +regression-from-stable-to-nightly
How did this not get caught by CI?
Assigning and removing as in the prioritization working group.
How did this not get caught by CI? I guess the original code (which triggers the ice) got changed. I found this by running todays rustc on the testcases from a couple of releases/years ago. :)
Yep, the test case was changed as part of the original PR. I didn't think to add the trait case to the new test, I've fixed that oversight (And one or two other possible cases) in the fix.
Regression is on beta now.
Change:
nocapture: false, color: AutoColor, quiet: false, <ins> test_threads: None, </ins> } } }

Discussion:
Discussion carried over from: rust-lang/cargo Test binaries created by rustc should have a option instead of (in addition to?) controlling the thread count with . It's not a consistent user experience to have some functionality controlled via environment variables and some via command line options. CLI options should be preferred since they encourage users to keep configuration local to a single execution of a test binary and not export it globally, making it affect other test runs perhaps accidentally. It would also make the output of more uniform and compact.
Agreed.
The ability to specify this in the somehow might be nice. One of my crates I'm working on needs all the tests run like this.
It is already set table by an env var, no? Cargo just can't specify them. So still not ideal but might work in the meantime. On Apr 16, 2016, 19:05 -0400, Nathan , wrote:
Oh cool thanks, I'll set that in my project.
Change:
<ins> // run-rustfix pub trait MyTrait { type T; fn bar(self) -> Self::T; } pub fn foo<A: MyTrait, B>(a: A) -> B { return a.bar(); //~ ERROR mismatched types } fn main() {} </ins>

Discussion:
When a type parameter is expected, but an unconstrained associated type is found rustc suggests a syntactically incorrect fix with a misleading help message about trait bounds instead of associated type constraints. No response
Change:
_ => {} } <ins> // FIXME we need to revisit this for #67176 if rvalue.needs_subst() { return None; } </ins> self.use_ecx(|this| { trace!("calling eval_rvalue_into_place(rvalue = {:?}, place = {:?})", rvalue, place); this.ecx.eval_rvalue_into_place(rvalue, place)?;

Discussion:
The lint should fire on the following code, but it does not: (This testcase now exists in-tree as a FIXME in .) Cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
I'd like to take this. claim
I have some plans to follow-up on with some cleanup. That might at least partially resolve this issue here. So it's probably best to wait until after that is done.
All right, landed, so what I planned here is done. The remaining issue is about associated consts. The issue there is that fails, or maybe we are hitting an , but I have not tried further. The issue is all yours, :)
Great! I'll start investigating.
Never mind, that one is already fixed on beta.
got reverted in , so we have to reopen this.
Change:
/// Exits if the parent directory cannot be determined. fn get_rust_lld_path(current_exe_path: &Path) -> PathBuf { let mut rust_lld_exe_name = "rust-lld".to_owned(); <del> rust_lld_exe_name.push_str(env::consts::EXE_SUFFIX); </del> <ins> rust_lld_exe_name.push_str(EXE_SUFFIX); </ins> let mut rust_lld_path = current_exe_path .parent() .unwrap_or_exit_with("directory containing current executable could not be determined")

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: and this happened: I expected to see this happen: it would compile my crate. Instead, this happened: lld failed. <!-- 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. --: fixed the problem that I reported in There seems to be a new problem with an unknown linker name. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details
Could you post the list of files in the directory in Rust distribution?
I found in the clang invocation:
It looks like maybe clang replaces and changes it from to when calling lld-wrapper?
I can't confirm whether that's the case right now, but if that's true then the fix would be as simple as adding the alternative to in lld-wrapper.
Apple ships its linker as . I couldn't find a file.
I believe the issue is with the usage of in the PR, see: You probably meant to use . Wait. is because of Windows? is the only one that does not play well with it. One solution is to normalise the string or before the match statement.
This is not happening only on osx. I can reproduce this. The path is correct and unchanged by clang, but it's indeed the call that trims too much on unixes because of the weird executable name with a dot. I'll fix it.
The problem still exists, but the error changed to on macos. Need more investigation..