jiebi/CodeConvo huggingface dataset:
Change:
yoo: &'a U } <ins> // https://github.com/rust-lang/rust/issues/105150 struct InferredWhereBoundWithInlineBound<'a, T: ?Sized> { data: &'a T, } </ins> fn main() {}

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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: <!-- Please provide a link to --The current output is: Rustfix will fail to apply this: ` So we need to extend span to include the as well? <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
The relevant code is in , with . The should be computed using in the loop, instead of crafting a specific computation. Likewise, should use method. If using those 2 methods from is not enough to solve the issue, those methods should perhaps be adapted.
claim
release-assignment Haven't been able to focus on this. Releasing assignment.
claim
Progress report: I'm working on it.
claim
Change:
<ins> // run-rustfix enum Enum { Variant(i32), } struct Struct(i32); fn foo(x: Enum) -> i32 { if let Enum::Variant(value) = x { //~ ERROR `if` may be missing an `else` clause value } } fn bar(x: Enum) -> i32 { if let Enum::Variant(value) = x { //~ ERROR `if` may be missing an `else` clause let x = value + 1; x } } fn baz(x: Struct) -> i32 { if let Struct(value) = x { //~ ERROR `if` may be missing an `else` clause let x = value + 1; x } } fn main() { let _ = foo(Enum::Variant(42)); let _ = bar(Enum::Variant(42)); let _ = baz(Struct(42)); } </ins>

Discussion:
The following code () gives the following error: which is weird, since the clause would never be visited even if it was present. The equivalent one-arm match compiles just fine (expectedly). Adding an branch to the is, of course, possible, but unelegant, and really shouldn't be needed, as it can be inferred at compile time.
You can match irrefutably without in this case: though maybe we should give this special diagnostics.
I think this is too niche to deserve a special diagnostics (and I don't think we should substantially work on diagnostics for until let_chains is implemented). is defined by a desugaring: becomes: so what you really wrote is: The block is typed at which does not unify with unless it is also typed at .
I didn't know was a valid syntax. If I did, I probably wouldn't have filed the issue, because of course, in hindsight, that's how you write an infallible . (With that knowledge in mind) I agree that it's only a diagnostics issue and no language change is needed here. And I fully agree that it's a niche low-priority quirk that should maybe be fixed "someday". (I don't know what but even then I'd guess that this one is lower priority than that).
I think the appropriate thing to do here would be to lint on , which would have clarified things.
We already do.
But we do only after typechecking, and we don't if there are any errors before then. Quite a few lints have similar issues related to not happening early enough.
How do you know that the pattern is irrefutable before match checking in HAIR?
You can't, but you can write the lint in such a way that it triggers regardless. We're getting to typechecking, we should be able to detect irrefutability by then. It just can't use the standard linting machinery (like a few other lints already do to avoid being silenced by accident).
Change:
<ins> // check-pass #![feature(exclusive_range_pattern)] #![allow(ellipsis_inclusive_range_patterns)] fn main() { macro_rules! mac_expr { ($e:expr) => { if let 2...$e = 3 {} if let 2..=$e = 3 {} if let 2..$e = 3 {} } } mac_expr!(4); } </ins>

Discussion:
The CI for started to fail today with this error: It appears as though the compiler doesn't see and only sees as the range expression and then generates this error. The expression is inside a expansion. You can reproduce this by cloning the repo and building it: The build succeeds on the stable channel and much older releases, so this appears to be a regression in the nightly. Here's the version on my windows system, but note that this also fails on linux and macos too:
Regression introduced in
More specifically the bug is in: which is called to see whether what follows is a valid start of a range pattern end expression. This is strange tho... in the case of e.g.: the call to in is used successfully to parse but somehow that doesn't work for . cc
Similarly, with: this does not trigger "error: range patterns are not supported" but it should.
Change:
sorted.sort_by(|&l, r| compare_names(l, r)); assert_eq!(names, sorted); } <ins> #[test] fn test_all_types_prints_header_once() { // Regression test for #82477 let all_types = AllTypes::new(); let mut buffer = Buffer::new(); all_types.print(&mut buffer); assert_eq!(1, buffer.into_inner().matches("List of all items").count()); } </ins>

Discussion:
As can be seen when going to , the "List of all items" page generated by rustdoc has a header saying "List of all items List of all items": ! <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Mentoring instructions: remove this line:
I think this regressed in cc do you have time to take a look?
How did that happen... Whoops, I'll fix asap As an aside, that bug should've been "List of List of all items" for a bit of wikipedia-plagiarism. claim
Change:
err: &mut DiagnosticBuilder<'a>, span: Span, ) { <del> let snippet = self.infcx.tcx.sess.source_map().span_to_snippet(span).unwrap(); </del> match error { GroupedMoveError::MovesFromPlace { mut binds_to, move_from, .. } => { <del> err.span_suggestion( span, "consider borrowing here", format!("&{}", snippet), Applicability::Unspecified, ); </del> <ins> if let Ok(snippet) = self.infcx.tcx.sess.source_map().span_to_snippet(span) { err.span_suggestion( span, "consider borrowing here", format!("&{}", snippet), Applicability::Unspecified, ); } </ins> if binds_to.is_empty() { let place_ty = move_from.ty(self.body, self.infcx.tcx).ty;

Discussion:
When trying to compile the tests for my I get this error: <details<summary</summary</detailsMy understanding is that the compiler was trying to tell me about a borrow checker error; but I have no idea where to start minimizing this error(sorry).
I have managed to get it down to two files: It doesn't work with a in the , it has to be a different file. is then needed to trigger the ICE.
modify labels: I-ICE A-macros C-Bug T-compiler
cc
Seems to be related to 2018 edition? If I use the nightly-2018-10-01 and execute it doesn't ICE, but with it does ICE. well...
Most likely related to the fact that NLL is active in Rust 2018 then.
Bisecting: Somewhere in
Confirmed. gave me the ICE on 2015 as well (forgot that in the good ol' days nll was not a thing) Also confirmed, that edition 2015 does ICE with on and not on (like edition 2018 did above).
Also ICE with
Change:
// not any other crate present in the diesel workspace // (This is required to set the feature flags above) manifest_path: Some("diesel/Cargo.toml"), <ins> filters: &[], </ins> }, ];

Discussion:
As part of our CI we run "cargotest" on a variety of ecosystem crates, making sure they successfully build and run tests. Unfortunately, some of use stochastic tests like quickcheck, which means that a crate passing our CI one day may not necessarily mean it passes CI the next. Perhaps we should audit the tests being run and filter out ones like these? See and cc
Yeah I think we've discussed this to some extent previously within infra team as part of our "what to do about cargotest" discussions. cc in particular Not sure that we came to any conclusions though.
Related:
The test from xsv fails occasionally:
This just bit me and took a lot of time as I triple-checked that after bors failing twice (!) in xsv, the same test actually works fine on my system.
The xsv test suite seems to be full of quickcheck tests, so I think the only way to fix this is to remove xsv from cargotest (or to only run a short list of curated tests).
See where there is some discussion fo changing the cargotest set. I think implies dropping xsv.
Hm, that discussion seems to have stalled though. So to fix the immediate problem, I propose we do something like
Change:
} } <ins> // Additionally require the hidden type to be well-formed with only the generics of the opaque type. // Defining use functions may have more bounds than the opaque type, which is ok, as long as the // hidden type is well formed even without those bounds. let predicate = ty::Binder::dummy(ty::PredicateKind::WellFormed(hidden_type.into())).to_predicate(tcx); inh.register_predicate(Obligation::new(misc_cause, param_env, predicate)); </ins> // Check that all obligations are satisfied by the implementation's // version. let errors = inh.fulfillment_cx.borrow_mut().select_all_or_error(&infcx);

Discussion:
() I would’ve expected rustc to complain about the not matching the with a suggestion to turn it into . modify labels: A-typesystem, A-lifetimes, A-traits, A-impl-trait, F-typealiasimpl_trait, T-compiler, requires-nightly and someone please add “I-unsound ” (and/or tell me if there is a way to do it myself).
One thing that is of note here is that we properly enforce type bounds, but not lifetime bounds, as the equivalent program with types fails to compile right where we expect that:
Aha! If we change to have an explicit bound, then we get the right error: so we're just missing a check of the implied bounds on the impl
Change:
/// is largely just a wrapper around `cargo doc`. pub fn test(build: &Build, stage: u32, target: &str, out: &Path) { println!("Documenting stage{} test ({})", stage, target); <ins> t!(fs::create_dir_all(out)); </ins> let compiler = Compiler::new(stage, &build.config.build); let out_dir = build.stage_out(&compiler, Mode::Libtest) .join(target).join("doc");

Discussion:
fails with: Note that there is no directory in Creating that directory fixes this problem but leads to another problem: This is because there is no directory in , which the tool tries to (checked with ). Creating that directory fixes the problem. Note that for stage 2, all directories starting at needed to be created.
Oh dear yeah this isn't tested very well so I wouldn't be surprised if it breaks every now and then, thanks for the report!
oops
Yeah, I expected that (the not very well tested) so when I needed to build the compiler docs I decided to try using rust build by that. By the way, I'm a little confused by the following: The rustbuild configuration includes a key, which is also present in the struct as , however the field .
Oh there should probably be a line in which adds that target to a dependency of the target, probably just got lost along the way somewhere by accident :(
Change:
<ins> -include ../tools.mk all: echo 'fn main(){}' > $(TMPDIR)/main.rs # Make sure that this fails ! $(RUSTC) -Z link-only $(TMPDIR)/main.rs 2> $(TMPDIR)/stderr.txt $(CGREP) "The input does not look like a .rlink file" < $(TMPDIR)/stderr.txt </ins>

Discussion:
This allows giving a better error when attempting to use the original source file with -Zlink-only rather than crashing and allows rejecting rlink files produced by a different rustc version.
To clarify: here's what I thought you had to do: But that gives an inscrutable error like this: The correct way to invoke is actually this If the file has a header, the code that reads it can check for that header. If it's not present (e.g. because somebody passed a file by mistake) then it can give a nice error message like "this doesn't look like a .rlink file".
I tried to look at this. is a struct that is serialized to files using the machinery. I tried to create a wrapper struct that would serialize and deserialize a header to provide nicer messages, but it's not really easy to provide a custom message if decoding of the header fails currently, since you removed the s from methods :sweat_smile: I see several solutions to this: 1) Catch panic that could be caused by invalid decoding of the header and provide a nicer message in that case (seems dubious). 2) Implement serialization and deserialization of the header using manual byte writes/reads, going around the traits. 3) Return sto methods (probably not worth it because of this). What do you suggest, solution 2)?
The crate metadata encodes and decodes the header separately from the contents. For crate metadata the header is of the form "rust" + 32bit be version number (currently 5 I believe) + 32bit offset of the crate root + rustc version string. During decoding the header is checked for "rust", the right version number and then the right rustc version. Only after that is a created to decode the contents. The rlink header could work the same way except omitting the offset of the crate root and using say "rsld" (rust ld) or "rustlink" as start instead of "rust" like the crate metadata.
Thanks for the hint. I checked rmeta decoding and it basically decodes the magic header byte slice with , which should be easy, but then it uses for decoding the rustc version, which will panic if the version is missing. So with this approach we could have a nice error if header magic is missing, nice error if rust version is wrong, but weird error if rust version if missing.

That is basically the same that we get for parsing, so I suppose that's ok?
Yeah, the header magic is supposed to be changed every time the rustc version needs to be decoded in a different way. IMO it is ok.
Change:
} ast::PatIdent(ast::BindByValue(_), _, _) => { let mode = copy_or_move(typer.tcx(), cmt_pat.ty, PatBindingMove); <ins> debug!("walk_pat binding consuming pat"); </ins> delegate.consume_pat(pat, cmt_pat, mode); } _ => {

Discussion:
loops allow moving out of fixed size arrays. This code compiles and should not compile. segfault with channels I don't know how to make this test case smaller, but... This commit introduces a segfault. Seems bad.
From what I'm seeing here(debugger wise) the problem looks to stem from the call to in the function. Inside we enter the loop, make it through the first unsafe match and then the problem appears to occur in the branch when we try to match again.
Can you describe the system that you're running on as well as the cargo/rustc versions you're using? I've been unable to reproduce the segfault on the most recent nightly on both linux and osx.
Oh sorry, I'm running Windows here. Latest installer version. After restarting into Xubuntu and updating I recompiled there and got a segfault. I get rust from the hansjorg/rust PPA. I'm running off of a Toshiba Satellite L875D-S7210 with an AMD A6-4400M APU. Windows is 64bit and Xubuntu is 32bit.
Ah, found it. Nominating and cc this seems bad and related to the recent removal of for-loop desugaring.
Assigning P-backcompat-lang, 1.0 milestone.
Simpler reproduction (it's not related to fixed sized arrays, updating title):
If you want to see a segfault you have to do something in the loop and iterate twice: This prints 1 and 2, then stalls a bit, then segfaults.
Change:
struct FooBPriv; } } <ins> // @has 'foo/trait.PubTrait.html' '//pre' 'pub trait PubTrait' // // @has 'foo/trait.PubTrait.html' '//pre' 'type Type;' // @!has 'foo/trait.PubTrait.html' '//pre' 'pub type Type;' // // @has 'foo/trait.PubTrait.html' '//pre' 'const CONST: usize;' // @!has 'foo/trait.PubTrait.html' '//pre' 'pub const CONST: usize;' // // @has 'foo/trait.PubTrait.html' '//pre' 'fn function();' // @!has 'foo/trait.PubTrait.html' '//pre' 'pub fn function();' pub trait PubTrait { type Type; const CONST: usize; fn function(); } // @has 'foo/struct.FooPublic.html' '//code' 'type Type' // @!has 'foo/struct.FooPublic.html' '//code' 'pub type Type' // // @has 'foo/struct.FooPublic.html' '//code' 'const CONST: usize' // @!has 'foo/struct.FooPublic.html' '//code' 'pub const CONST: usize' // // @has 'foo/struct.FooPublic.html' '//code' 'fn function()' // @!has 'foo/struct.FooPublic.html' '//code' 'pub fn function()' impl PubTrait for FooPublic { type Type = usize; const CONST: usize = 0; fn function() {} } </ins>

Discussion:
The trait on 1.49.0 (current stable) doesn't contain modifier in function declaration of that trait. ! However, on and nightly, there is modifier. ! This is wrong because you cannot use modifier for each method/function in Trait definition. Why is this important? People copy the method/function declaration in the documentation to their code and see the compiler error: . : cc I think this might relate to some changes in visibility around macros ? <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Yes, this needs the same fix as (in particular should work).
Self-assigning because this is a beta regression.
Note that this also occurs for the impl's docs.
Removed since this was fixed.
, trait methods still rendered as : ! Is there something wrong to Rust release or the bug still exists ?
Hmm, maybe it was only fixed for items in the local crate. do you have time to come up with an MCVE? I expect it's related to cross-crate re-exports.
Your guess sounds right. With core link (), things are normal.
I don't think I'll have time to fix this second part soon, so unassigning myself.
Assigning and removing as in the prioritization working group.
Removing E-mentor + E-easy labels since we don't have guides for cross-crate linking: label -E-easy -E-mentor
I think is the cross-crate case.
Fix backported to 1.50.0 and landed in 1.51.0, closing this.
Please reopen. The issue is not entirely fixed for cross-crate trait reexport case.
The cross-crate issue is now on stable. label: +regression-from-stable-to-stable -regression-from-stable-to-beta
claim
Change:
use rustc::mir::{Mir, Place}; use rustc::mir::{Projection, ProjectionElem}; use rustc::ty::{self, TyCtxt}; <ins> use std::cmp::max; </ins> pub(super) fn places_conflict<'gcx, 'tcx>( tcx: TyCtxt<'_, 'gcx, 'tcx>,

Discussion:
I believe the following should work, since and are disjoint, and is just taking a slice into (this would mean that is inaccessible while the result of is kept around): Changing it to (and removing the ):
Generally, multiple in a vector pattern should be allowable:
cc me
An interesting subquestion is whether we also want this to be allowed: In other words, whether the borrow checker should know about and attempt to reason about the disjointness of borrows into a vec beyond the scope of an individual pattern match.
Depending on how we do the implementation, it's likely that both patterns would "just work".
Triage: Nothing has changed here, at least as it pertains to , would be pretty cool if it worked.
This limitation doesn't have anything to do with slice patterns. It is even well-documented as .
I don't think it is the same, e.g. for the first example in the issue, an binding in a slice pattern is actually binding by reference (it has type or , not ), and the second one is completely unrelated.
Updated code: See also:
should be closed after MIR borrowck will be by default
Change:
<ins> #![crate_type = "lib"] #![crate_name = "usr"] // aux-crate:issue_24183=issue-24183.rs // edition: 2021 // @has usr/trait.U.html // @has - '//*[@class="item-decl"]' "pub trait U {" // @has - '//*[@id="method.modified"]'  // "fn modified(self) -> Self // where  //     Self: Sized" // @snapshot method_no_where_self_sized - '//*[@id="method.touch"]/*[@class="code-header"]' pub use issue_24183::U; // @has usr/trait.S.html // @has - '//*[@class="item-decl"]' 'pub trait S: Sized {' pub use issue_24183::S; </ins>

Discussion:
For example  should have a bound, but we're a little too aggressive about pruning out the bounds. For comparison  does indeed have the bound. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This also applies to bounds on traits.
This prompted a question on IRC about whether requires , because the bound is not visible in the libstd documentation. It is visible in the libcore docs though.
Triage: This still happens
This actually ended up biting me today, is there a plan to handle this? I could help implement if I get pointers
did not fix this - it now shows , which is nice, but it doesn't show bounds on traits. For traits it does matter because the default is .
I would start by finding out why this is different between local crates and cross-crate re-exports. I expect is behaving differently from .
Ah, I also hit this today when looking at . Kudos to whoever can figure this one out :)
claim
Change:
} } <ins> #[stable(feature = "read_shared_stdin", since = "CURRENT_RUSTC_VERSION")] impl Read for &Stdin { fn read(&mut self, buf: &mut [u8]) -> io::Result<usize> { self.lock().read(buf) } fn read_buf(&mut self, buf: BorrowedCursor<'_>) -> io::Result<()> { self.lock().read_buf(buf) } fn read_vectored(&mut self, bufs: &mut [IoSliceMut<'_>]) -> io::Result<usize> { self.lock().read_vectored(bufs) } #[inline] fn is_read_vectored(&self) -> bool { self.lock().is_read_vectored() } fn read_to_end(&mut self, buf: &mut Vec<u8>) -> io::Result<usize> { self.lock().read_to_end(buf) } fn read_to_string(&mut self, buf: &mut String) -> io::Result<usize> { self.lock().read_to_string(buf) } fn read_exact(&mut self, buf: &mut [u8]) -> io::Result<()> { self.lock().read_exact(buf) } } </ins> // only used by platform-dependent io::copy specializations, i.e. unused on some platforms #[cfg(any(target_os = "linux", target_os = "android"))] impl StdinLock<'_> {

Discussion:
It is possible to write to a thanks to , but it is not possible to read from a as the corresponding is missing. This seems to be entirely an accident, given that  does work on . Cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Seems reasonable to me. We'd need to FCP the resulting PR, since trait impls are insta-stable.
claim
Sorry, I didn't have time to add it. So see if any other contributors would like to add it. Unassign myself.
claim
claim
Change:
clippy_lint_warn.iter().for_each(|v| clippy_lint_levels.push(format!("-W{}", v))); clippy_lint_forbid.iter().for_each(|v| clippy_lint_levels.push(format!("-F{}", v))); args.extend(clippy_lint_levels); <ins> args.extend(builder.config.free_args.clone()); </ins> args } else { <del> vec![] </del> <ins> builder.config.free_args.clone() </ins> } }

Discussion:
Right now, x.py is pretty inconsistent with cargo's CLI. To pass arguments to compiletest, you use ; to pass arguments to you use ; to pass arguments to cargo you use CARGOFLAGS. I would like to unify these with the same syntax as cargo: would behave the same as today would behave the same as would behave the same as today, except that it would only pass it to cargo commands invoked by bootstrap, not when building bootstrap itself (avoiding the "argument --fix-broken not expected" error you'd get today). <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Looking at the current setup for argument parsing, it appears that getopts::Options struct doesn't have a state engine based parser, so it wont be able to parse -- as a state changing flag. I'm thinking probably parse and translate the args in python then just pass it on to the bootstrap executable, (unless someone here has a better idea).
let's not put any logic in python if we can help it, it's going away soon: . I think it would be ok to switch to or another arg parser if it makes things easier.
Ah, I was thinking something like getting rid of the python script was going to happen someday. will probably do for the functionality we will need from it.
I'm out of town for the rest of the week so if anyone would like to take this issue while I'm away, go for it.