jiebi/CodeConvo huggingface dataset:
Change:
("x86_64", "tvos") => "appletvsimulator", ("arm", "ios") => "iphoneos", ("aarch64", "ios") if llvm_target.contains("macabi") => "macosx", <ins> ("aarch64", "ios") if llvm_target.contains("sim") => "iphonesimulator", </ins> ("aarch64", "ios") => "iphoneos", ("x86", "ios") => "iphonesimulator", ("x86_64", "ios") if llvm_target.contains("macabi") => "macosx",

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:
<ins> error: this file contains an un-closed delimiter --> $DIR/issue-62554.rs:5:53 | LL | fn foo(u: u8) { if u8 macro_rules! u8 { (u6) => { fn uuuuuuuuuuu() { use s loo mod u8 { |               -                       -         -                  -                  - un-closed delimiter |               |                       |         |                  | |               |                       |         |                  un-closed delimiter |               |                       |         un-closed delimiter |               un-closed delimiter     un-closed delimiter LL | LL | |                                                     ^ error: expected `{`, found `macro_rules` --> $DIR/issue-62554.rs:3:23 | LL | fn foo(u: u8) { if u8 macro_rules! u8 { (u6) => { fn uuuuuuuuuuu() { use s loo mod u8 { |                 --    ^^^^^^^^^^^ expected `{` |                 | |                 this `if` statement has a condition, but no block help: try placing this code inside a block | LL | fn foo(u: u8) { if u8 { macro_rules! u8 { (u6) => { fn uuuuuuuuuuu() { use s loo mod u8 { LL | LL | LL |  } | error: aborting due to 2 previous errors </ins>

Discussion:
I'm seeing the following error on the channel, but not on or : Found with the help of .
triage: P-medium. Leaving nominated so that team double-checks that priority assignment.
This is triggered here It should be possible to use the span snippet instead. I believe it was introduced in
Change:
= note: see issue #37854 <https://github.com/rust-lang/rust/issues/37854> for more information = help: add `#![feature(exclusive_range_pattern)]` to the crate attributes to enable = note: this compiler was built on YYYY-MM-DD; consider upgrading it if it is out of date <ins> = help: use an inclusive range pattern, like N..=M </ins> error[E0658]: exclusive range pattern syntax is experimental --> $DIR/range_pat_interactions3.rs:14:17

Discussion:
Came across this when a beginner was very confused about what was wrong with their ; the words "is experimental" and the link to the issue was not sufficient for their discovering what the problem/solution was. The suggested inclusive range pattern doesn't need to contain the actual matching value if producing it is hard or impossible, printing something like is still better than nothing. This issue may of course be ignored/closed if this nightly feature is just about ready to be stabilized or something. No response label +D-terse +C-enhancement +F-exclusiverangepattern <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
| = note: values in a scope are dropped in the opposite order they are created <del> error: aborting due to previous error </del> <ins> error: aborting due to 2 previous errors </ins> For more information about this error, try `rustc --explain E0597`.

Discussion:
Code shows a case where doesn't stay borrowed for long enough allowing it to be mutated while a reference to it exists. I think treating generators as if they implement would fix this, but I'm not sure if this will end up causing incorrect errors in other places.
Change:
#![feature(doc_auto_cfg)] #![crate_name = "foo"] // @has foo/fn.foo.html <del> // @has - '//*[@class="item-info"]/*[@class="stab portability"]' 'non-doctest' #[cfg(not(doctest))] </del> <ins> // @has - '//*[@class="item-info"]/*[@class="stab portability"]' 'non-meowmeow' #[cfg(not(meowmeow))] </ins> pub fn foo() {} // @has foo/fn.bar.html <del> // @has - '//*[@class="item-info"]/*[@class="stab portability"]' 'doc' </del> <ins> // @has - '//*[@class="item-info"]/*[@class="stab portability"]' 'meowmeow' </ins> // @!has - '//*[@class="item-info"]/*[@class="stab portability"]' 'test' <del> #[cfg(any(test, doc))] </del> <ins> // @!has - '//*[@class="item-info"]/*[@class="stab portability"]' 'doc' // @!has - '//*[@class="item-info"]/*[@class="stab portability"]' 'doctest' #[cfg(any(meowmeow, test, doc, doctest))] </ins> pub fn bar() {} <ins> // @has foo/fn.appear_1.html // @has - '//*[@class="item-info"]/*[@class="stab portability"]' 'meowmeow' // @!has - '//*[@class="item-info"]/*[@class="stab portability"]' 'doc' // @!has - '//*[@class="item-info"]/*[@class="stab portability"]' 'non-test' #[cfg(any(meowmeow, doc, not(test)))] pub fn appear_1() {} // issue #98065 // @has foo/fn.appear_2.html // @has - '//*[@class="item-info"]/*[@class="stab portability"]' 'meowmeow' // @!has - '//*[@class="item-info"]/*[@class="stab portability"]' 'doc' // @!has - '//*[@class="item-info"]/*[@class="stab portability"]' 'test' #[cfg(any(meowmeow, doc, all(test)))] pub fn appear_2() {} // issue #98065 // @has foo/fn.appear_3.html // @has - '//*[@class="item-info"]/*[@class="stab portability"]' 'meowmeow' // @!has - '//*[@class="item-info"]/*[@class="stab portability"]' 'doc' #[cfg(any(meowmeow, doc, all()))] pub fn appear_3() {} // issue #98065 </ins>

Discussion:
Context: CC
Thanks for opening this issue! Someone from the rustdoc team will try to get back to it whenever possible.
It doesn't look too difficult. I'm going to try to make a PR for it myself, and I'll update here with or without progress.
Even better! :smile: I'll assign you to the issue in the meantime then.
Change:
[[package]] name = "compiletest_rs" <del> version = "0.3.26" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "d7d8975604ebad8b6660796802377eb6495045c5606168fc1b8d19a4dd9bfa46" dependencies = [ "diff", "filetime", "getopts", "libc", "log", "miow 0.3.3", "regex", "rustfix", "serde", "serde_derive", "serde_json", "tempfile", "tester 0.6.0", "winapi 0.3.8", ] [[package]] name = "compiletest_rs" </del> version = "0.4.0" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "d7b678957210a00ba0fbeacc23d38cbfbf29895564da1616564634351e1dac5e"

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and nominating for compiler team prioritization.
triage: P-medium, removing nomination label.
Change:
// Closures are handled by their owner, if it has a body if tcx.is_closure(def.did.to_def_id()) { <del> let owner = tcx.hir().local_def_id_to_hir_id(def.did).owner; let owner_hir_id = tcx.hir().local_def_id_to_hir_id(owner); if tcx.hir().maybe_body_owned_by(owner_hir_id).is_some() { tcx.ensure().thir_check_unsafety(owner); return; } </del> <ins> let hir = tcx.hir(); let owner = hir.enclosing_body_owner(hir.local_def_id_to_hir_id(def.did)); tcx.ensure().thir_check_unsafety(hir.local_def_id(owner)); return; </ins> } let (thir, expr) = tcx.thir_body(def);

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 with : I expected to see this happen: It compiles, as it does under the MIR checker Instead, this happened: <!-- 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. --: </p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Reduced (either of the following two functions reproduces the issue): This is caused by the fact that closures are handled by their owner: claim
Change:
return (err, candidates); } <del> let mut fallback = self.suggest_trait_and_bounds(&mut err, source, res, span, &base_error); </del> <ins> if self.suggest_shadowed(&mut err, source, path, following_seg, span) { // if there is already a shadowed name, don'suggest candidates for importing candidates.clear(); } </ins> <del> // if we have suggested using pattern matching, then don't add needless suggestions // for typos. </del> <ins> let mut fallback = self.suggest_trait_and_bounds(&mut err, source, res, span, &base_error); </ins> fallback |= self.suggest_typo(&mut err, source, path, following_seg, span, &base_error); if fallback {

Discussion:
(A better title would be appreciated) I like this part: It could have a suggestion like , especially because are very close to each other on a US keyboard and could very well be a typo. Applying the suggestion will result in a compile error. No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I think the label might be fitting as well.
Error: Parsing assign command in failed: ...' claim' ' +D-invali'... Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
Change:
match *ctor { ConstantValue(ref value) => { let to = cmp_to(value)?; <del> let end = (to != Ordering::Greater) || (end == RangeEnd::Excluded && to == Ordering::Equal); </del> <ins> let end = (to == Ordering::Less) || (end == RangeEnd::Included && to == Ordering::Equal); </ins> Ok(cmp_from(value)? && end) }, ConstantRange(ref from, ref to, RangeEnd::Included) => { let to = cmp_to(to)?; <del> let end = (to != Ordering::Greater) || (end == RangeEnd::Excluded && to == Ordering::Equal); </del> <ins> let end = (to == Ordering::Less) || (end == RangeEnd::Included && to == Ordering::Equal); </ins> Ok(cmp_from(from)? && end) }, ConstantRange(ref from, ref to, RangeEnd::Excluded) => {

Discussion:
With rust nightly compiler, the result on the screen is even though the compiler warning that 11 case is unreachable. Link to rust playground:
Change:
/// Pushes the obligations required for `trait_ref` to be WF into /// `self.out`. <del> fn compute_trait_ref(&mut self, trait_ref: &ty::TraitRef<'tcx>) { </del> <ins> fn compute_trait_ref(&mut self, trait_ref: &ty::TraitRef<'tcx>, elaborate: Elaborate) { </ins> let obligations = self.nominal_obligations(trait_ref.def_id, trait_ref.substs); <del> self.out.extend(obligations); </del> let cause = self.cause(traits::MiscObligation); let param_env = self.param_env; <ins> if let Elaborate::All = elaborate { let predicates = obligations.iter() .map(|obligation| obligation.predicate.clone()) .collect(); let implied_obligations = traits::elaborate_predicates(self.infcx.tcx, predicates); let implied_obligations = implied_obligations.map(|pred| { traits::Obligation::new(cause.clone(), param_env, pred) }); self.out.extend(implied_obligations); } self.out.extend(obligations); </ins> self.out.extend( trait_ref.substs.types() .filter(|ty| !ty.has_escaping_regions())

Discussion:
First reported in cc - let's discuss this when you are back from vacation (unless can come up with a solution?)
Associated types variant, which bypasses some fixes based only on supertraits:
Chalk's strategy will solve this, but I guess that shouldn't be extremely difficult to fix even with the current strategy. The first impl is valid: since indeed implies that . The second however, is not: the impl declaration should be able to prove that holds (ok because of the first impl), but also that is well-formed, i.e. that holds. Same thing in the second example, this impl declaration: should prove that (ok) and that is well-formed, i.e. . The latter is not being proved currently.
triage: P-high -- has pending fix
Change:
<ins> // aux-build:issue-104884.rs use std::collections::BinaryHeap; #[macro_use] extern crate issue_104884; #[derive(PartialEq, Eq, PartialOrd, Ord)] struct PriorityQueueEntry<T> { value: T, } #[derive(PartialOrd, AddImpl)] //~^ ERROR can't compare `PriorityQueue<T>` with `PriorityQueue<T>` //~| ERROR the trait bound `PriorityQueue<T>: Eq` is not satisfied //~| ERROR can't compare `T` with `T` struct PriorityQueue<T>(BinaryHeap<PriorityQueueEntry<T>>); fn main() {} </ins>

Discussion:
Given the following code: current output is: The last part of the suggestion is not valid Rust code and therefore should not be suggested like this. This problem occurs on the Playground on both stable and nightly with basically identical error messages. serde v1.0.147 requires such that will be . Otherwise the problem does not seem serde specific. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
do you know how to create a minimal case without ? so we may add it to unit testing. I give a fix and verified it's OK with my local testing, but I'm struggle to construct a minimal case without to reproduce it.
I assume this reproduces when using the same setup of derive macro implementing a trait while the implementation is missing bounds. I don't know if it is relevant that the derive macro produces a trait. Something along these lines, with the proc macro crate omitted.
yes, it's caused by derive macro.
emmmet this error
Change:
<ins> // Copyright 2012-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. #![feature(rustc_private)] extern crate rustc_back; use std::fs::File; use std::io::{Read, Write}; use rustc_back::tempdir::TempDir; #[cfg(unix)] fn switch_stdout_to(file: File) { use std::os::unix::prelude::*; extern { fn dup2(old: i32, new: i32) -> i32; } unsafe { assert_eq!(dup2(file.as_raw_fd(), 1), 1); } } #[cfg(windows)] fn switch_stdout_to(file: File) { use std::os::windows::prelude::*; extern "system" { fn SetStdHandle(nStdHandle: u32, handle: *mut u8) -> i32; } const STD_OUTPUT_HANDLE: u32 = (-11i32) as u32; unsafe { let rc = SetStdHandle(STD_OUTPUT_HANDLE, file.into_raw_handle() as *mut _); assert!(rc != 0); } } fn main() { let td = TempDir::new("foo").unwrap(); let path = td.path().join("bar"); let f = File::create(&path).unwrap(); println!("foo"); std::io::stdout().flush().unwrap(); switch_stdout_to(f); println!("bar"); std::io::stdout().flush().unwrap(); let mut contents = String::new(); File::open(&path).unwrap().read_to_string(&mut contents).unwrap(); assert_eq!(contents, "barn"); } </ins>

Discussion:
Over time the value of may change (e.g. see ) and we should likely reload the value over time instead of caching the return value to catch cases like this.
There's very little value in caching the result. takes 3 nanoseconds for me according to a quick bench.
Change:
use rustc_ast::token::{self, Delimiter, Token}; use rustc_ast::tokenstream::{DelimSpan, Spacing, TokenStream, TokenTree}; use rustc_ast_pretty::pprust::token_to_string; <del> use rustc_errors::PErr; </del> <ins> use rustc_errors::{Applicability, PErr}; use rustc_span::symbol::kw; </ins> pub(super) struct TokenTreesReader<'a> { string_reader: StringReader<'a>,

Discussion:
Unmatched delimiters are hard to deal with by taking consideration of surrounding code because they actually occur during lexing. Still, it'd be nice if we detected some common sources of issues like this one. No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
<ins> error[E0597]: `*cell` does not live long enough --> $DIR/dropck.rs:19:40 | LL |     let ref_ = Box::leak(Box::new(Some(cell.borrow_mut()))); |                                        ^^^^ borrowed value does not live long enough ... LL | } | - `*cell` dropped here while still borrowed | = note: values in a scope are dropped in the opposite order they are created </ins> error[E0597]: `ref_` does not live long enough <del> --> $DIR/dropck.rs:23:18 </del> <ins> --> $DIR/dropck.rs:24:18 </ins> | LL |     gen = || { |           -- capture occurs here

Discussion:
Code shows a case where doesn't stay borrowed for long enough allowing it to be mutated while a reference to it exists. I think treating generators as if they implement would fix this, but I'm not sure if this will end up causing incorrect errors in other places.
Change:
parser.add_argument('--build') parser.add_argument('--color', choices=['always', 'never', 'auto']) parser.add_argument('--clean', action='store_true') <ins> parser.add_argument('--json-output', action='store_true') </ins> parser.add_argument('-v', '--verbose', action='count', default=0) return parser.parse_known_args(sys.argv)[0]

Discussion:
I think this is one of the reasons (maybe not the only one?) that introducing a build failure in src/bootstrap means that rust-analyzer doesn't show red squigglies in the IDE. Mentoring instructions: add a new flag to around and pass to cargo around if it's set. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc https://rust-
claim
Solving this may also solve
Change:
<ins> // no-prefer-dynamic // compile-flags: --crate-type=rlib pub use impl_mod::TraitImplementer as Implementer; pub use trait_mod::get_assoc; mod impl_mod { use crate::trait_mod::TraitWithAssocType; pub struct TraitImplementer {} pub struct AssociatedType {} impl AssociatedType { pub fn method_on_assoc(&self) -> i32 { todo!() } } impl TraitWithAssocType for TraitImplementer { type AssocType = AssociatedType; } } mod trait_mod { use crate::Implementer; pub fn get_assoc() -> <Implementer as TraitWithAssocType>::AssocType { todo!() } pub trait TraitWithAssocType { type AssocType; } } </ins>

Discussion:
This is a pretty common use case, so this bug has probably already been registered, but I couldn't find anything while searching around, so I'm reporting this here just in case. I ran this code: When running this code, I expect to simply get a not yet implemented error on the function. Instead, I get this: : returns an , and is not a trait method–it's just a regular method. Therefore, AFAIK, this should compile. Notably, making either or as makes it compile fine.
Regression in . cc
oli's on leave so cc-ing PR 's reviewer
WG-prioritization assigning priority (). label -I-prioritize +P-high
Change:
let args: Vec<_> = args.into_iter().filter_map(|x| x).collect(); <del> if c_variadic && args.is_empty() { </del> <ins> if c_variadic && args.len() <= 1 { </ins> self.span_err(sp, "C-variadic function must be declared with at least one named argument"); }

Discussion:
This ICEs (see title) because of the call: That's because the definition of errored in 1.34, but doesn't since 1.35: cc (found while working on )
<details<summaryBacktrace</summary</details
Ah, the problem is that this wasn't updated ( now contains a ): Thankfully, at the same time, the ICE was , so calls wouldn't have been possible to such functions.
Good catch
Change:
<ins> warning: unreachable pattern --> $DIR/issue-43253.rs:36:9 | 36 |         9 => {}, |         ^ | = note: #[warn(unreachable_patterns)] on by default warning: unreachable pattern --> $DIR/issue-43253.rs:42:9 | 42 |         8...9 => {}, |         ^^^^^ warning: unreachable pattern --> $DIR/issue-43253.rs:48:9 | 48 |         9...9 => {}, |         ^^^^^ </ins>

Discussion:
With rust nightly compiler, the result on the screen is even though the compiler warning that 11 case is unreachable. Link to rust playground:
Change:
<ins> #![feature(generic_associated_types)] #![allow(unused)] pub trait Trait  { type Assoc<'a> where Self: 'a; fn f(&self) -> Self::Assoc<'_>; // Disallow elision in return position, for now fn g(&self) -> Self::Assoc; //~^ ERROR missing generics for associated type `Trait::Assoc` } pub struct Struct { item: f32 } pub struct GenericStruct<'a> { ref_item: &'a f32 } impl Trait for Struct { type Assoc<'a> = GenericStruct<'a>; fn f(&self) -> Self::Assoc<'_> { Self::Assoc { ref_item: &self.item } } // Disallow elision in return position, for now fn g(&self) -> Self::Assoc { //~^ ERROR missing generics for associated type `Trait::Assoc` todo!() } } fn main() {} </ins>

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: I expected to see this happen: the lifetime is correctly inferred when using Instead, this happened: I have to use one of the work arounds described in the linked code. Swap from GAT lifetime to the trait parameterized by a lifetime it works: <!-- 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. --: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Interested in fixing this. I think all we need to do is treat like other paths with elided lifetimes (e.g. ). you're the go-to person for GATs, right? If so, does that sound correct? Secondly I might also put up a PR that suggests adding when parsing since that's also what's wrong with the second solution. claim
ah yes, good catch, the second solution does work with . In the way I had originally encountered this it didn't work without more nightly features () - a GAT, on a trait, on a , which parametrized a trait. Which left the type alias way the only way around.
I don't know if I've looked at this code before. But seems about right. I'm wondering if something like works and there's just code somewhere that doesn't take into account that the associated type itself can have substs.
This might be a little bit difficult though. When using a concrete struck like , we can infer that lifetime because we know how it's used in the struct itself. With associated types, we don't know, necessarily. In a way, I would expect that to be somewhat opaque, tbh. I'm not sure how I feel about this tbh. If you can fix it, I'd probably want to get some second thoughts before merging.