jiebi/CodeConvo huggingface dataset:
Change:
<del> Subproject commit b9b2af9729243ab8d5b02cca2e19ce93cc23c1b1 </del> <ins> Subproject commit b13b79db73e3fa692fc648a8cd70f162a5eade34 </ins>

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. 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!
yes I can work on that :)
that would be great. :) However, there's some amount of urgency here as these Miri failures tend to accumulate.
I am not particularly fast. So maybe someone else should work on that if they want to.
that's okay! Sadly, these Miri breakages are not good opportunities for first-time Miri contribution. Thanks anyway. :) I'll take care of it.
as pointed by it seems simple enough I can do it now
Change:
Error, File, FileType, <ins> Fn, FnMut, FnOnce, </ins> FormatSpec, Formatter, From,

Discussion:
It feels like rustc should be able to determine that a trait followed by a is a -family trait bound and be able to suggest this behavior. If that is too general it could just check for , , . Very similar is if parenthesis are missing from regular declarations: Also happens on nightly according to Rust Playground. I'd like to try my hand at implementing this diagnostic, but I'll likely need a little bit of locational guidance. A naive code search show that the message is emitted by this code is the parser diagnostics, but I'm not sure if the adjustment would need to be made within that or from where it is invoked in this case. Edit: Updated to use the wording "-family trait bounds" rather than "HRTBs"._
Where this function is invoked. Try looking for the code that parses .
If you end up writing a fix, note that those trait bounds are usually called -family trait bounds, not “HRTBs”. The latter would require at least one higher-rank parameter to be involved (e.g. ).
It seems this diagnostic contextually comes from which does this token search by . As corroboration it also seems that declaring a regular without parenthesis causes a similar if more contextually understandable error: I naively think that the adjustment point should probably be rather than ... However I don't understand how the output gets multiple possibilities e.g. and in this output: or the whole list of Since it's only calling with from ... I guess this requires catching the result in and handling this result type somehow?
Any time you call , it stashes the token type you tried probing for and it'll present that in a list whenever you get to . (Or something like that).
Anyways, it shouldn't matter -- in the caller to (when parsing ), you could add a check for before calling and handle the token specifically.
Just chiming in to mention: in any parser change you make here make sure you don't start accepting new code and add tests for all combinations you can think of.
Change:
use syntax::codemap::{CodeMap, FileLoader, RealFileLoader}; use syntax::feature_gate::{GatedCfg, UnstableFeatures}; use syntax::parse::{self, PResult}; <del> use syntax_pos::{hygiene, DUMMY_SP, MultiSpan, FileName}; </del> <ins> use syntax_pos::{DUMMY_SP, MultiSpan, FileName}; </ins> #[cfg(test)] mod test;

Discussion:
Rustdoc seems to fail on async syntax in some situations. With in , the following is a sample of some apparent issues. This should build fine, but fails when running rustdoc: Tested with a few different nightlies (rustc 1.30.0-nightly ( 2018-08-05)) and latest master ().
This is a bug between rustdoc and , where the only place that is handed to libsyntax is this specific all-in-one entry point to the compiler: However, since rustdoc manages the phases of compilation itself, this line is never hit, and thus the global state telling libsyntax what edition to use is not set. We use this call manually for building doctests (see ), but not anywhere else. I propose moving the call from to , right before it sets up the parse session. That way, rustdoc can continue to set the edition in the session options, and other consumers of aren't caught by this gotcha.
Change:
let rust_type_regexes = vec![ "^(alloc::([a-z_]+::)+)String$", <del> "^&str$", "^&[.+]$", </del> <ins> "^&(mut )?str$", "^&(mut )?[.+]$", </ins> "^(std::ffi::([a-z_]+::)+)OsString$", "^(alloc::([a-z_]+::)+)Vec<.+>$", "^(alloc::([a-z_]+::)+)VecDeque<.+>$",

Discussion:
Currently, support for pretty-printing slice types is missing for rust-gdb.
Can you describe in more detail?
provides pretty-printing function for some Rust types, such as , , , etc. This allows gdb to display values of some types in a more readable way. I think it is implemented in the following files: , , Currently, slices can only be displayed as a pointer and a length value in the debugger. I hope rust-gdb can support displaying slices. I also noticed that already supports pretty-printing const slices (), but not mutable slices (). Maybe rust-lldb can also add pretty-printing support fur mutable slices.
label A-slice C-enhancement T-dev-tools
Change:
finished_map } <del> pub fn is_of_param(&self, substs: &Substs<'_>) -> bool { if substs.is_noop() { return false; } </del> <ins> fn is_param_no_infer(&self, substs: &Substs<'_>) -> bool { return self.is_of_param(substs.type_at(0)) && !substs.types().any(|t| t.has_infer_types()); } </ins> <del> return match substs.type_at(0).sty { </del> <ins> pub fn is_of_param(&self, ty: Ty<'_>) -> bool { return match ty.sty { </ins> ty::Param(_) => true, <del> ty::Projection(p) => self.is_of_param(p.substs), </del> <ins> ty::Projection(p) => self.is_of_param(p.self_ty()), </ins> _ => false, }; } <ins> fn is_self_referential_projection(&self, p: ty::PolyProjectionPredicate<'_>) -> bool { match p.ty().skip_binder().sty { ty::Projection(proj) if proj == p.skip_binder().projection_ty => { true }, _ => false } } </ins> pub fn evaluate_nested_obligations< 'b, 'c,

Discussion:
When I tried to build docs for , I got a panic. Here is the reduced test case: With the above code, when I run I get this panic: rustc 1.27.0-nightly ( 2018-04-18) binary: rustc commit-hash: commit-date: 2018-04-18 host: x86_64-pc-windows-msvc release: 1.27.0-nightly LLVM version: 6.0
Strange... Will take a look as soon as possible.
So the call is performed . I'll need help from (or anyone in the team who knows about the type) in order to fix this issue.
Reduced further:
I'd like to work on this.
Thank you so much! I verified that with the latest Rust Nightly I no longer get any errors.
Change:
#[suggestion(code = ": ", applicability = "machine-applicable")] pub between: Span, } <ins> #[derive(Diagnostic)] #[diag(parser_fn_ptr_with_generics)] pub(crate) struct FnPtrWithGenerics { #[primary_span] pub span: Span, #[subdiagnostic] pub sugg: Option<FnPtrWithGenericsSugg>, } #[derive(Subdiagnostic)] #[multipart_suggestion(suggestion, applicability = "maybe-incorrect")] pub(crate) struct FnPtrWithGenericsSugg { #[suggestion_part(code = "{snippet}")] pub left: Span, pub snippet: String, #[suggestion_part(code = "")] pub right: Span, pub arity: usize, pub for_param_list_exists: bool, } </ins>

Discussion:
Newcomers might attempt to write a “generic” function pointer like . In such case, the compiler should provide a better error message. Inspired by a recent Reddit thread I sadly cannot find anymore. Given the following code: The compiler should mention that function pointers may not be generic or […] may not have generic parameters, suggest to move the lifetime(s) to a parameter list (this should be machine-applicable in my judgement) and be able to recover: For later reference, the current output is: Given the following code: The compiler should mention that function pointers may not be generic or […] may not have generic parameters and be able to recover emitting two diagnostics, one for each line. The compiler could also suggest moving the generic parameter list further up to the owning function, struct, etc. if available. Note that this might not be what the user intended (since there is a semantic difference between hypothetical higher-ranked generics and normal ones) and therefore shouldn't be machine-applicable. For later reference, the current output is: label A-parser A-suggestion-diagnostics D-newcomer-roadblock <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
# Unix binary installer tarballs ###################################################################### <del> NON_INSTALLED_PREFIXES=COPYRIGHT,LICENSE-APACHE,LICENSE-MIT,README.md,version </del> define DEF_INSTALLER $$(eval $$(call DEF_PREPARE,dir-$(1)))

Discussion:
There are a few issues of polish that I want to fix here: Although the installer internally supports multiple components there is no interface for actually selecting individual components. This is important because it allows to not install docs, which are 250 MB of the 50 MB install. Uninstallation can only be done through the original installer, which in many cases means the user is going to have to download the installer again. I want to put an uninstall script in the installation. This will require some refactoring and an upgrade of the installer manifest format.
This is a prereq for my plan to fix the .pkg uninstall issue
cc
cc
Change:
return '' def build_bootstrap(self): <ins> build_dir = os.path.join(self.build_dir, "bootstrap") if self.clean and os.path.exists(build_dir): shutil.rmtree(build_dir) </ins> env = os.environ.copy() <del> env["CARGO_TARGET_DIR"] = os.path.join(self.build_dir, "bootstrap") </del> <ins> env["CARGO_TARGET_DIR"] = build_dir </ins> env["RUSTC"] = self.rustc() env["LD_LIBRARY_PATH"] = os.path.join(self.bin_root(), "lib") env["DYLD_LIBRARY_PATH"] = os.path.join(self.bin_root(), "lib")

Discussion:
Errors like are happening on the bots, e.g.: This is under the covers, but rustbuild's command should blow away the build system directory ahead of time to be more resilient to bugs like this.
Change:
use rustc_lint_defs::builtin::NAMED_ARGUMENTS_USED_POSITIONALLY; use rustc_lint_defs::{BufferedEarlyLint, BuiltinLintDiagnostics, LintId}; <del> use rustc_parse_format::{Count, FormatSpec}; </del> <ins> use rustc_parse_format::Count; </ins> use std::borrow::Cow; use std::collections::hash_map::Entry;

Discussion:
Running clippy or build on the Vaultwarden code-base using breaks. It is broken since and still works on Tried to run before running this without luck. If you need any more information, please let me know. Vaultwarden: Working: Broken since: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Looks like this is a duplicate of , , , , , and Sorry for the clutter ;)

<!-- 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. --Upon running , the compiler panics when having as a dependency. and complete without error. Probably this is related to ? <!-- 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. --: and : : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p: </p</details
Appears to be a duplicate of
Change:
use crate::middle::cstore::{ExternCrate, ExternCrateSource}; <del> use crate::mir::interpret::{sign_extend, truncate, AllocId, ConstValue, Pointer, Scalar}; </del> <ins> use crate::mir::interpret::{ sign_extend, truncate, AllocId, ConstValue, GlobalAlloc, Pointer, Scalar, }; </ins> use crate::ty::layout::IntegerExt; use crate::ty::subst::{GenericArg, GenericArgKind, Subst}; use crate::ty::{self, DefIdTree, ParamConst, Ty, TyCtxt, TypeFoldable};

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. --Command: This code is 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. --: The compiler is at revision <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
This , too. Cc
This happens on stable, too. Not very surprising imo since the original corresponding tickets ( , ) are only ~2 weeks old.
Those tickets report different ICEs, from what I can see. Same source code, but different assertion hit in the compiler.
Reduced: when I use an underscore binding instead of , the ICE no longer occurs:
The same ICE also triggers on this file in the miri submodule: (with --emit mir) I'm guessing it's so we need to match on the result of the and print different output depending on it
PR to fix this is up at
I'm getting a similar ice when checking with . I'm wondering if that's fixed as well.
That's a bit hard to tell based on a backtrace without line numbers. But with my patch, there is no more in that entire file, so I'd say -- probably. There's still an though, so I suspect there are still ICEs when a function pointer points to a non-function...
Btw it would be great if someone could review that PR. :) Looks like is pretty busy.
Can confirm this fixed the ICE :+1: :)
Change:
use crate::core::config::TargetSelection; use crate::utils::channel::GitInfo; use crate::utils::exec::BootstrapCommand; <ins> use crate::utils::helpers::output; </ins> use crate::utils::helpers::{add_dylib_path, exe, t}; use crate::Compiler; use crate::Mode;

Discussion:
Spawned off of I'm not 100% sure what would be involved in such a check here, but it seems like a good thing to investigate, because the nature of the resulting bootstrap failures is super frustrating. (I'll admit, I don't know if the right thing would be to hard error out of all uses of download-ci-llvm for potentially-incompatible libstdc++, or only to hard error out for defaulting uses... but a warning seems warranted in any such cases.
I guess the problem here is that we're compiling the locally and linking that against the downloaded toolchain. A check like suggested here makes sense to me in the meantime, but I suppose long-term the "right" fix here is to get rid of any C++ code we need to separately compile by upstreaming C bindings into LLVM proper, and then we can just call those on the Rust side without any ABI issues. (FWIW, I was initially confused since we explicitly statically link in the stdcpp in the distributed I guess maybe we could also fix this by skipping linking to a local stdcpp while compiling the Rust wrapper code? Not sure if that works out.)
This is the particular line which leads to failure with download-ci-llvm when there is an ABI mismatch. In my experiment removing it resulted in linking errors on rustcdriver. I agree, this solves the problem completely without applying hacks (in my opinion, there is no simple or clean way of comparing ABI or libstd versions) on bootstrap. Maybe, for now, we should just print a warning when downloading ci llvm?
You mean always print a warning? I don't think that's a good idea, it's noisy and we generally expect that people are happy using download CI LLVM. I don't think a warning is helpful here if we can't scope it down to where it matters (in which case it can probably be an error).
Not always, only once while downloading it.
I think that falls in the same "not particularly helpful" case. Most users will miss the message, and even if they don't it's not clear how they should respond. I at least don't know how to check whether my machine has everything setup right. If we could check then we could limit the warning, in which case I'm broadly in favor of making it perhaps even a hard error.
Change:
// Obviously makes no sense but... unsafe { g_free(std::ptr::null_mut()); <ins> g_free2(std::ptr::null_mut()); </ins> } left + right }

Discussion:
Hi there, In we use to try and keep our crate's linking instructions up-to-date across supported platforms. We've noticed that in some build configurations the output can change in surprising ways. For instance, using rustc nightly (1.70.0) on Windows (x8664-pc-windows-msvc) in a configuration driven by we see many consecutive duplicate libraries in the output. I understand duplicates are to be expected, and can be meaningful on some platforms, but seeing so many consecutive repeats seems unexpected and unlikely to be meaningful for the build process. Is this perhaps a regression? Or are we making a mistake by relying on the stability of this output across versions/build configurations? This feature is as having a known prefix to "make it easier to fetch the output." leading to the idea that it is expected to be machine consumable. I tried this code: I expected to see this happen: A list produced, with some duplicates (e.g. multiple ), but not many consecutive duplicates. E.g.: Instead, this happened: A list with many consecutive duplicates is produced: </detailsrustc nightly (1.70.0) on Windows (x8664-pc-windows-msvc) in a configuration. rustc nightly (1.70.0) on Windows (x8664-pc-windows-msvc) in a configuration. Project: Build task: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Hm, I thought we usually removed consecutive duplicates but apparently only in release. A workaround would be to do so manually. For the msvc targets all duplicates can be removed so long as the order is preserved. This isn't true of many other targets though. It would be much better to have a proper fix though.
Thanks for the quick reply :-) That's we landed on for the short term :+1: Great, thanks for clarifying.
WG-prioritization assigning priority (). label -I-prioritize +P-medium
claim
Error: Parsing assign command in failed: ...' assign' ''... Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
Thanks !
Change:
} return 0; }); <ins> var savedCrate = getCurrentValue("rustdoc-saved-filter-crate"); </ins> for (var i = 0; i < crates_text.length; ++i) { var option = document.createElement("option"); option.value = crates_text[i]; option.innerText = crates_text[i]; elem.appendChild(option); <ins> // Set the crate filter from saved storage, if the current page has the saved crate // filter. // // If not, ignore the crate filter -- we want to support filtering for crates on sites // like doc.rust-lang.org where the crates may differ from page to page while on the // same domain. if (crates_text[i] === savedCrate) { elem.value = savedCrate; } </ins> } }

Discussion:
Right now it is allowed to select whether we want to search within all crates or in the specific ones (e.g. core, std, etc). It would be really useful to remember the selected option, because in most cases we want to search in the std crate only. cc
Good idea!
Does not work, neither in stable nor nightly. Go to Choose the "std" option. Type Option, click on it We still see the "All crates" on the , and if we try to search something else, results will be from all sources anyway.
Indeed, will take a look quickly.
Works perfectly now. Thanks!
Change:
<ins> Copyright © 2011-2014 The Rust Project Developers. Licensed under the href{http://www.apache.org/licenses/LICENSE-2.0}{Apache License, Version 2.0} or the href{http://opensource.org/licenses/MIT}{MIT license}, at your option. This file may not be copied, modified, or distributed except according to those terms. </ins>

Discussion:
Per we should have the docs licensed correctly. Nominating.
I can have a look at this.
Change:
} } <ins> pub fn with_capacity(n: usize) -> SnapshotVec<D> { SnapshotVec { values: Vec::with_capacity(n), undo_log: Vec::new(), } } </ins> fn in_snapshot(&self) -> bool { !self.undo_log.is_empty() }

Discussion:
This is an 8% regression with incremental enabled, 1% without it.
Interestingly if you you'll see: An 8% regression due to A 4% improvement due to A 7% improvement due to A 7% regression due to May be worth looking into as well?
Specifically before/after , -- I've only included the peak snapshot in the output there.
Looks like basically all of the memory , aka we have a bigger dep graph. Turns out adding more queries makes a bigger dep graph :)
I cashed in some easy savings in , but it doesn't actually fix the "regression", but we likely shouldn't call it a regression as it also fixed a number of would-be bugs!
Looks like we've and this particular peak may also , so closing.
Change:
<del> Subproject commit 43ac9416d935942d6c7d2b2e0c876c551652c4ec </del> <ins> Subproject commit 920cdb59e1edf2c4cb2f266fa521f12c1b97a499 </ins>

Discussion:
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! cc the PR reviewer, and nominating for compiler team prioritization.
Change:
note = "if you want to iterate between `start` until a value `end`, use the exclusive range  syntax `start..end` or the inclusive range syntax `start..=end`" ), <ins> on( _Self = "{float}", note = "if you want to iterate between `start` until a value `end`, use the exclusive range  syntax `start..end` or the inclusive range syntax `start..=end`" ), </ins> label = "`{Self}` is not an iterator", message = "`{Self}` is not an iterator" )]

Discussion:
rust version: Do you think it would be useful to add a hint here? Something in the lines of <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
i was hoping this to be my first PR to the compiler, if accepted as necessary. :D I need some guidance as to where this code might be though...
claim
hups sorry
I was testing the bot feature
The 'is not an iterator' message comes from the attribute. One solution would be to add a new case to that attribute which detects literals of the form (where both sides are numeric) and suggests the iterator syntax.
thanks!
is this in the right direction?
Change:
// @has foo/index.html '//h2[@id="keywords"]' 'Keywords' // @has foo/index.html '//a[@href="keyword.match.html"]' 'match' <ins> // @has foo/index.html '//div[@class="block items"]//a/@href' '#keywords' </ins> // @has foo/keyword.match.html '//a[@class="keyword"]' 'match' // @has foo/keyword.match.html '//span[@class="in-band"]' 'Keyword match' // @has foo/keyword.match.html '//section[@id="main"]//div[@class="docblock"]//p' 'this is a test!'

Discussion:
As per : Add the following link () next to the existing ones: See all std's items Re-exports Primitive Types Modules Macros <-- this one. cc
Thanks for opening the issue! I'll send the PR tomorrow (but if you want to do it, please go ahead ).
Change:
if type_implements_negative_copy_modulo_regions(cx.tcx, ty, param_env) { return; } <ins> if def.is_variant_list_non_exhaustive() || def.variants().iter().any(|variant| variant.is_field_list_non_exhaustive()) { return; } </ins> // We shouldn't recommend implementing `Copy` on stateful things, // such as iterators.

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 have the following minimal example: It does as I expect and gives the error: However, since this enum is going to have more options to it in the future, for example, I go ahead and label it as : I would expect that this would disable the lint in this case. This is because, otherwise adding a implementation, e.g.: would then break when, in the future, I add my variant: with: In short, I would expect that adding would disable the lint as it's not future-proof, and the whole point of the attribute is to say "that a type or variant may have more fields or variants in the future". <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim