jiebi/CodeConvo huggingface dataset:
Code change:
<ins> // run-pass #![feature(or_patterns)] fn main() { assert!(f("", 0)); assert!(f("a", 1)); assert!(f("b", 1)); assert!(!f("", 1)); assert!(!f("a", 0)); assert!(!f("b", 0)); assert!(!f("asdf", 32)); //// assert!(!g(true, true, true)); assert!(!g(false, true, true)); assert!(!g(true, false, true)); assert!(!g(false, false, true)); assert!(!g(true, true, false)); assert!(g(false, true, false)); assert!(g(true, false, false)); assert!(g(false, false, false)); //// assert!(!h(true, true, true)); assert!(!h(false, true, true)); assert!(!h(true, false, true)); assert!(!h(false, false, true)); assert!(!h(true, true, false)); assert!(h(false, true, false)); assert!(h(true, false, false)); assert!(h(false, false, false)); } fn f(s: &str, num: usize) -> bool { match (s, num) { ("", 0) | ("a" | "b", 1) => true, _ => false, } } fn g(x: bool, y: bool, z: bool) -> bool { match (x, y, x, z) { (true | false, false, true, false) => true, (false, true | false, true | false, false) => true, (true | false, true | false, true | false, true) => false, (true, true | false, true | false, false) => false, } } fn h(x: bool, y: bool, z: bool) -> bool { match (x, (y, (x, (z,)))) { (true | false, (false, (true, (false,)))) => true, (false, (true | false, (true | false, (false,)))) => true, (true | false, (true | false, (true | false, (true,)))) => false, (true, (true | false, (true | false, (false,)))) => false, } } </ins>

Related discussion:
text: When using the feature, attempting to match on a tuple creates a compiler panic. The following code causes the panic. (Also available at the ) This occurs both on the playground and on my local machine on a previous version (details below). Rust version from the playground: Local version: Playground backtrace: Local backtrace: EDIT: Added local machine backtrace too
It looks like the problem is here in . The call to seems to rely on the invariant that the match pairs have been fully simplified at this point, but are a special case and can still show up here.
Reproducible with recent nightlies too: : Triggered by more than 3 pattern condition with this compiler version.
I would have assumed that the implementation merely desugars into a bunch of top-level or-patterns. Is that not the case? Why are tuples special cased? If it isn't too involved, I could take a crack at this with some guidance... very much want to see this over the finish line.
Code change:
<del> Subproject commit d9e7d2696e41983b6b5a0b4fac604b4e548a84d3 </del> <ins> Subproject commit c7a16bd57c2a9c643a52f0cebecdaf0b6a996da1 </ins>

Related discussion:
text: Was looking at the printout of llvm passes when I noticed that the functions that was inlined everywhere, and due to this was dead code, was optimized more after inlining. So as a test I at the line and this reduces the compile time of release build in racer by an average of 23%. I do not know if this is a good place to add this extra pass but maybe someone that knows how llvm works can use this information to speedup the compilation of release builds. was also wondering how this works in MIR I see that there is an inline pass but I can not find any dead code elimination
the stage1 compilation of rustc went from 828.89 to 691.75 secs with this fix on my computer but that is only a 15% improvement
15% is pretty significant.
Wow, great work!
That's some nice improvements! If you feel up to it, go ahead an submit a pull request with your suggested changes. That way someone with experience with LLVM is guaranteed to look at the patch and it won't get lost.
I believe the PR should be targeted at
:+1: If you want to push through this patch the general process works like this: Submit the patch against the currently active branch of (which is at the moment) Wait for it to get reviewed & merged Submit a pull request against which updates the submodule. If you have any questions about the process or want someone else to do this, just mention it here or contact me or someone else on one of the .
cc
cc
Ideally, the process should include discussion with upstream LLVM too.
Unfortunately it looks like we were a bit too eager to close this in :(
From what I have learned from the llvm maintainers I think that we have received the improvement that can be expected. The to good to be true improvements I measured was probably due to less optimizations was possible and resulted in less optimized code.
Code change:
/// # Example /// /// ```rust <ins> /// # #![allow(deprecated)] </ins> /// use url::get_scheme; /// /// let scheme = match get_scheme("https://example.com/") {

Related discussion:
text: The common fix for , , and is to rewrite the module based on the spec at and the tests at (Note: the tests assume the API, designed for JavaScript in web browsers. We do not necessarily want the same API for Rust outside of testing code.)
I'm interested in this
I have a work-in-progress implementation. I’ll publish it later today so you can pick it up if you want.
Here it is: Note that I’m targeting Rust , the version used in Servo. (Though there is an upgrade being worked on.) IDNA and the actual URL parser are not there yet, but everything else (host/domain/ipv6, , percent encoding, test harness) is there. This should start being useful as soon as the URL parser is . The host parser returns an error on non-ASCII domains. This is good enough for now, IDNA support can be later. also made an in-progress implementation: It has some known bugs ( is incorrect with non-ASCII input, at least) but the parser code can probably be reused.
Also, be aware that the URL spec itself is still moving and has a number of open bugs:
I Punycode encoding and decoding (with tests) to but not Nameprep, which is the other big part of IDNA.
is now (IMHO) ready to replace . It is not "done" yet (some bugs remain, including in the spec!), but at this point it has more than feature-parity and is probably correct in more corner cases. Given the current tendency to move things out of , rust-url probably shouldn’t move in. It could be distributed with rustc like the rest of the modules moving out of extra, but this has the downside of tying rust-url upgrades to compiler upgrades, and only weak advantages IMO. So, whenever the Rust team decides it’s appropriate, I suggest removing and recommending rust-url as a replacement.
I would generally be in favor of a in the distribution for now. This would certainly not be a package in long-term, but for now putting everything in this repo is the ad-hoc solution we have until we get a real package manager.
In that case, I’d like to iterate a bit on rust-url (port rust-http and Servo to it, …) before it moves into the distribution. Also, rust-url depends on rust-encoding, which I guess would have to move as well.
Code change:
/// # Example /// /// ```rust <ins> /// # #![allow(deprecated)] </ins> /// use url::get_scheme; /// /// let scheme = match get_scheme("https://example.com/") {

Related discussion:
text: I’d say rust-url is now in "beta" state. I have branches of rust-http and Servo using it: It builds with Cargo. It depends on rust-encoding (which also builds with Cargo), but for something non-essential that could be deactivated if avoiding the additional dependency helps. I’d like people to start using it and give feedback. I think the best way to do that is to get rid of the old liburl. I’ll go through the RFC process, but before that, what would you prefer? Replace liburl with snapshots[] of rust-url. You were in favor of this in February, but Cargo has reached alpha since then. Just remove liburl, and tell people to use rust-url through Cargo. Something else? [] In any case, I’d like to keep a separate rust-url repository that I can update in Servo independently of language upgrades.
+1 on removing liburl. Thanks
Perhaps we can deprecate all of liburl for one release cycle.
This seems like a great place to let cargo shine.
Deprecating sounds reasonable. That means emitting warnings by default, right?
awesome work! I agree with and that I think this is where cargo shines, and we can probably just remove liburl entirely without re-adding rust-url. We can also try to grow more official support for it in terms of documentation and automation (not present currently). We can mark liburl as with a message to use instead which should ferry everyone along quickly.
Code change:
<ins> // check-pass trait Identity<Q> { type T; } impl<Q, T> Identity<Q> for T { type T = T; } trait Holds { type Q; } struct S; struct X(S); struct XHelper; impl Holds for X { type Q = XHelper; } impl<Q> Clone for X where <S as Identity<Q>>::T: Clone, X: Holds<Q = Q>, { fn clone(&self) -> Self { Self(self.0.clone()) } } fn main() {} </ins>

Related discussion:
text: <!-- 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. --./src/test/ui/impl- or ./src/test/ui/impl-trait/issues/issue- <!-- 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</detailscc I believe this might be caused by
I'll look into it regardless
I was unable to reproduce same error perhaps it already fixed on stable channel try updating your rust compiler onto stable channel
the nightly that contains suspicious commit has not been released yet, there is no point in trying to reproduce this with nightly (or even stable). You'll need something that contains
This is the same issue that I identified in , but the bug identified and fixed in actually caused it to not be triggered until now. The issue here is a "trivial bound" () causing us to not select but in the MIR inliner. The caching bug actually caused the latter branch to happen everywhere, so when that bug was fixed, we started to normalize to in some places, causing this ICE. I bet I could trigger an ICE with a slight modification to this code using the inliner even with reverted. This is probably only triggered by the inliner, but the MIR inliner isn't enabled without being explicitly provided, right?
Code change:
<ins> // check-pass trait Identity<Q> { type T; } impl<Q, T> Identity<Q> for T { type T = T; } trait Holds { type Q; } struct S; struct X(S); struct XHelper; impl Holds for X { type Q = XHelper; } impl<Q> Clone for X where <S as Identity<Q>>::T: Clone, X: Holds<Q = Q>, { fn clone(&self) -> Self { Self(self.0.clone()) } } fn main() {} </ins>

Related discussion:
text: Trying to emulate trivial bounds via generics & associated types panics on stable, beta and nightly. <!-- 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. --: Reproducible on beta and nightly <!-- 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 --
Bug is not present in 1.51 and appears in 1.52. More precisely, it appeared somewhere between and .
Seems like introduces the regression Probably is the culprit
It seems to affect only traits that are checked by . Changing to fixes the panic.
I wonder if this could be fixed by normalizing the caller-bounds when checking for trivial bounds in WF. Hmm.... might think about this issue later tonight.
I'm putting up a PR soon to fix a whole bunch of impossible-bounds related things. So I'll claim this for the time being. claim
Code change:
.any(|build_llvm_ourselves| build_llvm_ourselves); let need_cmake = building_llvm || build.config.any_sanitizers_enabled(); if need_cmake { <del> cmd_finder.must_have("cmake"); </del> <ins> if cmd_finder.maybe_have("cmake").is_none() { eprintln!( " Couldn't find required command: cmake You should install cmake, or set `download-ci-llvm = true` in the `[llvm]` section section of `config.toml` to download LLVM rather than building it. " ); std::process::exit(1); } </ins> } build.config.python = build

Related discussion:
text: I tried to build on a new machine. Got this message: Which I'm used to. I googled a bit, installed , figured out how to get PATH set up, et cetera. Then I built again. And got this: I'm not sure, but: Isn't solely necessary in our build for building LLVM? if that's the case, then shouldn't both the failure and the failure be providing the same level of feedback (namely, suggesting that one side-step building LLVM altogether as an alternative option to downloading and installing )? (Or is the assumption here that will be used by so many crates, people should just bite bullet and install it? Even so, we could give better guidance up front about where to look for it.) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I don't think cmake intentionally has a worse error, it's just that a bunch of people building from source for the first time have been confused what ninja is and where to get it. If you made a PR improving the error for cmake I'd approve it :)
label: +E-easy
claim
Hello I'd like to claim this issue if you're interested in releasing it.
Sorry about that Gave it a try but got sidetracked and wasn't really interested in doing it anymore
claim
Code change:
<ins> // Copyright 2016 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. // compile-flags:--no-defaults --passes strip-priv-imports // aux-build:empty.rs // ignore-cross-compile // @has issue_27104/index.html // @!has - 'extern crate std' // @!has - 'use std::prelude::' // @has - 'pub extern crate empty' pub extern crate empty; </ins>

Related discussion:
text: Rustdoc defaults to only documented things that are public, i.e. things that the user of a library would care about. This is a good default, but rustdoc can also be useful to people working on large crates by documenting these crates themselves. In that case, it’s preferable to also include private types, fields, functions, and methods. was about this use case, and was closed with this solution: We just tried this on . It’s better than before, but has the unexpected side effect that every item (including non- and the implicit prelude) and every (including the implicit ) is documented under “Reexports”. It can get pretty noisy: ! They’re technically part of the crate, but don’t provide useful information. Could rustdoc split up the pass into one that strips private and , and one for everything else?
Code change:
[[package]] name = "libgit2-sys" <del> version = "0.10.0" </del> <ins> version = "0.11.0+0.99.0" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" <del> checksum = "d9ec6bca50549d34a392611dde775123086acbd994e3fff64954777ce2dc2e51" </del> <ins> checksum = "4d5d1459353d397a029fb18862166338de938e6be976606bd056cf8f1a912ecf" </ins> dependencies = [ "cc", "libc",

Related discussion:
text: Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool clippy-driver 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! And nominating for compiler team prioritization.
Code change:
let _: &dyn BuildHasher<Hasher = DefaultHasher> = &RandomState::new(); } <ins> // just tests by whether or not this compiles fn _build_hasher_default_impl_all_auto_traits<T>() { use std::panic::{RefUnwindSafe, UnwindSafe}; fn all_auto_traits<T: Send + Sync + Unpin + UnwindSafe + RefUnwindSafe>() {} all_auto_traits::<std::hash::BuildHasherDefault<T>>(); } </ins>

Related discussion:
text: Right.. is my own PR; I'm noting this as an issue, mainly so I won't forget this, because I won't do this myself right now / today. Or someone else can do this if they want. I'm not 100% certain where the best place for such a test to go is, and/or whether it makes sense to have them in one place or separated and more close to the respective type's definition. A test to prevent any future regression removing the new auto trait implementations introduced by can look about as follows <s` </sEdit: This code is needlessly complicated, see my comment below. label C-enhancement, A-testsuite, E-easy, E-needs-test, T-libs <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
FYI, somehow I missed the more straightforward way of writing these.
Code change:
} // handled in the `strip-priv-imports` pass <del> clean::ExternCrateItem { .. } | clean::ImportItem(..) => {} </del> <ins> clean::ExternCrateItem { .. } => {} clean::ImportItem(ref imp) => { // Because json doesn't inline imports from private modules, we need to mark // the imported item as retained so it's impls won't be stripped.i // // FIXME: Is it necessary to check for json output here: See // https://github.com/rust-lang/rust/pull/100325#discussion_r941495215 if let Some(did) = imp.source.did && self.is_json_output { self.retained.insert(did.into()); } } </ins> clean::ImplItem(..) => {}

Related discussion:
text: <!-- 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. --Given a public type, I expected all traits implemented by that type to be part of rustdoc JSON output. However, rustdoc JSON output sometimes does not include information about all the traits implemented by a type unless is specified. For example, in this : The following invocation on v3.1.18 generates JSON stating that is implemented for : However, the following invocation has no mention of for at all: Related to: :
cc
modify labels: +E-needs-mcve
Interestingly, rustdoc-json is providing no impls at all: norunn# use clap::{Command, Arg};nlet matches = Command::new("MyApp")n .arg(Arg::new("out")n .long("output")n .required(true)n .takesvalue(true))n .arg(Arg::new("debug")n .short('d')n .multipleoccurrences(true))n .arg(Arg::new("cfg")n .short('c')n .takesvalue(true))n .getmatches(); // builds the instance of ArgMatchesnn// to get information about the "cfg" argument we created, such as the value supplied we usen// various ArgMatches methods, such as ArgMatches::valueofnif let Some(c) = matches.valueof("cfg") {n println!("Value for -c: {}", c);n}nn// The ArgMatches::valueof method returns an Option because the user may not have suppliedn// that argument at runtime. But if we specified that the argument was "required" as we didn// with the "out" argument, we can safely unwrap because verifies that was actuallyn// used at runtime.nprintln!("Value for --output: {}", matches.valueof("out").unwrap());nn// You can check the presence of an argumentnif matches.ispresent("out") {n // Another way to check if an argument was present, or if it occurred multiple times is ton // use occurrencesof() which returns 0 if an argument isn't found at runtime, or then // number of times that it occurred, if it was.
Code change:
} // handled in the `strip-priv-imports` pass <del> clean::ExternCrateItem { .. } | clean::ImportItem(..) => {} </del> <ins> clean::ExternCrateItem { .. } => {} clean::ImportItem(ref imp) => { // Because json doesn't inline imports from private modules, we need to mark // the imported item as retained so it's impls won't be stripped.i // // FIXME: Is it necessary to check for json output here: See // https://github.com/rust-lang/rust/pull/100325#discussion_r941495215 if let Some(did) = imp.source.did && self.is_json_output { self.retained.insert(did.into()); } } </ins> clean::ImplItem(..) => {}

Related discussion:
text: To allow an argument to appear more thann // once, you must use the .multipleoccurrences(true) method, otherwise it will only return 1 or 0.n if matches.occurrences_of("debug") 2 {n println!("Debug mode is REALLY on, don't be crazy");n } else {n println!("Debug mode kind of on");n }n}n
Missing impls is probably a recent regression, see
MCVE produces () and with () modify labels: -E-needs-mcve
This is almost certanly due to searched nightlies: from nightly-2022-07-01 to nightly-2022-08-08 regressed nightly: nightly-2022-07-17 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
More minimal (no_core) Is correct in html ! and wrong in json
Code change:
} // handled in the `strip-priv-imports` pass <del> clean::ExternCrateItem { .. } | clean::ImportItem(..) => {} </del> <ins> clean::ExternCrateItem { .. } => {} clean::ImportItem(ref imp) => { // Because json doesn't inline imports from private modules, we need to mark // the imported item as retained so it's impls won't be stripped.i // // FIXME: Is it necessary to check for json output here: See // https://github.com/rust-lang/rust/pull/100325#discussion_r941495215 if let Some(did) = imp.source.did && self.is_json_output { self.retained.insert(did.into()); } } </ins> clean::ImplItem(..) => {}

Related discussion:
text: running produces this record for the type : I would expect "impls" to not be blank, since the matrix implements many traits and has a non-trait implementation as well. The paths entry also does not contain as well as many other types exported by the crate, is this expected ? I know that these paths included all exported types before : :
Now running with produces: So i think there's been a regression since then
Thank you for reporting labels +A-rustdoc-json +T-rustdoc
Seems like this could be another symptom of the regression reported as
This is the same issue as Items in a non-public module (ie accessed only via imports) have no impls
Code change:
--> $DIR/issue-17800.rs:18:28 | LL |         MyOption::MySome { x: 42 } => (), <del> |                            ^^^^^ variant `MyOption::MySome` does not have this field </del> <ins> |                            ^^^^^ |                            | |                            variant `MyOption::MySome` does not have this field |                            help: did you mean: `0` </ins> <del> error[E0027]: pattern does not mention field `0` --> $DIR/issue-17800.rs:18:9 | LL |         MyOption::MySome { x: 42 } => (), |         ^^^^^^^^^^^^^^^^^^^^^^^^^^ missing field `0` | = note: trying to match a tuple variant with a struct variant pattern error: aborting due to 2 previous errors </del> <ins> error: aborting due to previous error </ins> <del> Some errors occurred: E0026, E0027. For more information about an error, try `rustc --explain E0026`. </del> <ins> For more information about this error, try `rustc --explain E0026`. </ins>

Related discussion:
text: With a single typo in a match arm, we generate three separate errors: We should collect all these errors into a single diagnostic:
could you share sample code to exactly reproduce above diagnostic?
I will raise another PR to address the case where we are unnecessarily throwing .