jiebi/CodeConvo huggingface dataset:
Change:
return StdStringProvider(valobj) if rust_type == RustType.STD_OS_STRING: return StdOsStringProvider(valobj) <del> if rust_type == RustType.STD_STR and not rust_enabled: </del> <ins> if rust_type == RustType.STD_STR: </ins> return StdStrProvider(valobj) <ins> if rust_type == RustType.STD_SLICE: return StdSliceProvider(valobj) </ins> if rust_type == RustType.STD_VEC: return StdVecProvider(valobj) if rust_type == RustType.STD_VEC_DEQUE:

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:
return (err, Vec::new()); } <del> let (found, candidates) = self.try_lookup_name_relaxed( </del> <ins> let (found, mut candidates) = self.try_lookup_name_relaxed( </ins> &mut err, source, path,

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:
use std::mem; use std::ops::Range; <del> use crate::clean::{self, Crate, GetDefId, Item, ItemLink, PrimitiveType}; </del> <ins> use crate::clean::{self, Crate, Item, ItemLink, PrimitiveType}; </ins> use crate::core::DocContext; use crate::fold::DocFolder; use crate::html::markdown::markdown_links;

Discussion:
: cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Nearly 100% of that time is spent in . ! Is this even required for intra-doc links? AFAIK this is only for and , which don't have associated items.
... why is taking a quarter of the time?
I think this could be sped up quite a bit by only considering traits that have an associated item of the right name. Then rustdoc wouldn't have to go through the trait system at all, just look at it long enough to see it wouldn't work even if it did apply to the type.
Relevant code: We could change to take a parameter, that wouldn't be too invasive I think.
It probably also doesn't help that simplifies the type to an extent where all generic args are erased and then iterates on all trait implementations of it: If you have gazillions of then that's a problem :) Reducing the number of traits this (rather expensive) search is done is a good idea!
I think the strategy similar to would be helpful here too, but I guess the lower hanging fruit (checking whether the trait contains the name in the first place) should be tried before.
Discussed in Discord with , I'll be trying my hand at this one :rocket: claim
Change:
} else if nanos >= MAX_NANOS_F64 { Err(FromSecsError { kind: FromSecsErrorKind::Overflow }) } else if nanos < 0.0 { <del> Err(FromSecsError { kind: FromSecsErrorKind::Underflow }) </del> <ins> Err(FromSecsError { kind: FromSecsErrorKind::Negative }) </ins> } else { let nanos = nanos as u128; Ok(Duration {

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: The current output is: <!-- The following is not always necessary. --Ideally the output should look like: while the current error message might still give a hint as to what could be going on, if you have genuinely large numbers passed to the function, you may go in a completely wrong path while debugging (testing the input to be within limits, rather than checking if it is negative or not). <!-- If dramatically different output is caused by small changes, consider also adding them here. Occurs in stable, beta and nightly compiler. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
let mut a = 3; let mut b = vec![2]; } <ins> // make sure the lint attribute can be turned off on let statements #[deny(unused_mut)] fn bar() { #[allow(unused_mut)] let mut a = 3; let mut b = vec![2]; //~ ERROR: variable does not need to be mutable } </ins>

Discussion:
seems to be ignored For example: I expected to see no warning about the mut flag of a Instead, this happened: This currently happens on all 3 major branches: stable, beta, nightly: Backtrace: does not give more information.
Note that increasing the scope of the avoids the warning as expected: Unclear whether applying the to the should be sufficient.
I'm guessing that the lint passes were just not updated when attributes were allowed to be attached to statements.
The lint pass runs on functions, not on single statements, since you can't decide whether the should be linted just by looking at the statement. This is a failure of the current lint system and hard to address.
cc
The lint pass runs on functions, not on single statements, since you can't decide whether the should be linted just by looking at the statement. This is a failure of the current lint system and hard to address. is also ignored when statement is located inside of a macro, regardless of whether is located above the statement, macro, or function in which macro is called: ,L235 It would be nice if it did work for single statements inside of a macro. Main channels are still affected: stable: rustc 1.20.0 ( 2017-08-27) beta: rustc 1.21.0-beta.3 ( 2017-09-15) nightly: rustc 1.22.0-nightly ( 2017-09-14)
Change:
Ok(P(ast::Local { ty, pat, init, id: DUMMY_NODE_ID, span: lo.to(hi), attrs, tokens: None })) } <del> /// Parses the RHS of a local variable declaration (e.g., '= 14;'). </del> <ins> /// Parses the RHS of a local variable declaration (e.g., `= 14;`). </ins> fn parse_initializer(&mut self, eq_optional: bool) -> PResult<'a, Option<P<Expr>>> { let eq_consumed = match self.token.kind { token::BinOpEq(..) => {

Discussion:
This code: gives the following error: It's not clear or even close to what the actual problem is. I think it should throw the E0067 error code. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
use rustc_infer::infer::UpvarRegion; use rustc_middle::hir::place::{Place, PlaceBase, PlaceWithHirId, Projection, ProjectionKind}; use rustc_middle::mir::FakeReadCause; <del> use rustc_middle::ty::fold::TypeFoldable; </del> use rustc_middle::ty::{self, Ty, TyCtxt, TypeckResults, UpvarSubsts}; use rustc_session::lint; use rustc_span::sym;

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. --Removing allows the code to compile successfully. <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
cc
I dont have too much context on how type folding works, but my guess is we are calling fold sooner that we should. I have this to the for RFC 2229, I'll bring it up during our sync tomorrow.
We want to use .
assign
Error: Parsing assign command in failed: ...'bot assign' ''... Please let know if you're having trouble with this bot.
claim
Thanks
Change:
LL |     drop(field); |     ~~~~~     + <del> error: non-binding let on a type that implements `Drop` </del> <ins> error: non-binding let on a type that has a destructor </ins> --> $DIR/issue-119697-extra-let.rs:17:5 | LL |     let _ = field;

Discussion:
I tried this code: I got this warning: However, there is no impl on the type, so the error message is misleading. It is true however that there is a destructor, as defined here: That being said, it's insiginificant for all underlying types (only destructor of and type in the ), so ideally the warning still wouldn't even show. : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Well, even if the parameter of is , it still has a side-effect (deallocates memory). I don't think we need this special-casing. I do think the diagnostic is a bit misleading and should just say "has a destructor" or "has side-effects when dropped". Is there a more practical code example for why you'd want to suppress this error? The example you gave is a bit artificial, so it's a hard to motivate why we'd want to suppress this code since it really could be rewritten to be clearer.
claim
Change:
CodeBlockKind::Indented => Default::default(), }; <ins> let lines = origtext.lines().filter_map(|l| map_line(l).for_html()); let text = lines.intersperse("n".into()).collect::<String>(); </ins> compile_fail = parse_result.compile_fail; should_panic = parse_result.should_panic; ignore = parse_result.ignore;

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: text //! #..#.####.#....#.....##.. //! #..#.#....#....#....#..#. //! ####.###..#....#....#..#. //! #..#.#....#....#....#..#. //! #..#.#....#....#....#..#. //! #..#.####.####.####..##.. //! I expected to see this happen: When I run , I expect to see ASCII art in the output that matches the above example. Instead, this happened: In the output, this actually appears: It appears that if a line starts with at least three s, one gets "swallowed" somehow. <!-- 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<summaryBacktrace</summary<p</p</details
It's because of how are handled for rust code blocks. I'll send a PR but we need to ensure that people are not relying on to hide a line for non-rust code blocks.
This is actually a regression. I haven't bisected, but it occurred sometime between 1.50.0 and 1.63.0 based on a quick test. In 1.50.0, the following code block markdown /// # Header /// rendered as , but in 1.63.0 it renders as a blank code block.
Thanks for the information !

The regression is in nightly-2021-07-15 Commits in range: commit[0] 2021-07-13UTC: Auto merge of - camsteffen:hash-lint-resolved, r=oli-obk commit[1] 2021-07-13UTC: Auto merge of - cjgillot:expnhash, r=petrochenkov commit[2] 2021-07-14UTC: Auto merge of - Mark-Simulacrum:edition-no-clone, r=petrochenkov commit[3] 2021-07-14UTC: Auto merge of - tlyu:option-result-overviews, r=joshtriplett commit[4] 2021-07-14UTC: Auto merge of - JohnTitor:rollup-8ltidsq, r=JohnTitor commit[5] 2021-07-14UTC: Auto merge of - michaelwoerister:const-in-debuginfo-type-names-fix, r=oli-obk,wesleywiser commit[6] 2021-07-14UTC: Auto merge of - GuillaumeGomez:rollup-pfz9jbk, r=GuillaumeGomez commit[7] 2021-07-14UTC: Auto merge of - cuviper:fuse-less-specialized, r=joshtriplett Maybe this happened in (merged by ) (cc
Change:
impl<'tcx> MirPass<'tcx> for SimplifyBranchSame { fn run_pass(&self, tcx: TyCtxt<'tcx>, body: &mut Body<'tcx>) { <ins> // This optimization is disabled by default for now due to // soundness concerns; see issue #89485 and PR #89489. if !tcx.sess.opts.debugging_opts.unsound_mir_opts { return; } </ins> trace!("Running SimplifyBranchSame on {:?}", body.source); let finder = SimplifyBranchSameOptimizationFinder { body, tcx }; let opts = finder.find();

Discussion:
Originally found by when experimenting with discriminants starting from 1 in modify labels: +regression-from-stable-to-stable +I-unsound
After a quick it appears that the regression appear with Rust 1.48.0
A bisection seems to lead to , nightly 2020-09-26 from to
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-critical
Looks like it is mostly likely caused by which is supposed to cc
Change:
Node(Symbol, Span, Option<Symbol> /* RFC 2383 reason */), /// Lint level was set by a command-line flag. <del> CommandLine(Symbol), </del> <ins> /// The provided `Level` is the level specified on the command line - /// the actual level may be lower due to `--cap-lints` CommandLine(Symbol, Level), </ins> } impl LintSource {

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. --Simply building the rusty-xinput crate in the dependency chain seems to have triggered it. See <!-- 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. --Rust version from the build <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<pI'm sorry - I don't have access to a windows environment to reproduce this! </p</details
I think is the cause, cc Note that you should set to reproduce it. I don't feel this is Windows-specific but it just depends on the Windows-specific crate, marking . <details<summary<strongBacktrace</strong</summary</details
MCVE: run on:
Assigning and removing .
I got the same error on Linux while compiling lazy_static. https://cirrus- .
This will be fixed by
Change:
target_os = "ios", target_os = "android", all(target_os = "linux", target_arch = "arm"), <del> all(target_os = "windows", target_pointer_width = "32"), </del> target_os = "freebsd", target_os = "dragonfly", target_os = "bitrig",

Discussion:
Backtraces on windows are generated using the function. This will generate incorrect backtraces if any of the frame pointers are omitted due to FPO. This would normally be fine, as debug builds are compiled without FPO enabled. However, even in debug builds, the code will be linked to an optimised build of , so if any frames from libstd are on the top of the stack when the backtrace is generated (which will always be the case for obvious reasons) there's the potential for one or more of those frames to have been optimised out, breaking the backtrace. On , this turns out to always be the case, as triggers FPO. On , it currently works, but I'm unsure if that's just luck, or whether FPO is not used for that target. This was not caught by tests because has been (accidentally?) disabled on all windows targets.
It is due to the Windowx 64-bit calling convention being designed in such a way that FPO can always be done and stack walking always work, unlike 32-bit.
Change:
use crate::collect::PlaceholderHirTyCollector; use crate::middle::resolve_lifetime as rl; use crate::require_c_abi_if_c_variadic; <del> use rustc_ast::ast::ParamKindOrd; use rustc_ast::util::lev_distance::find_best_match_for_name; </del> <ins> use rustc_ast::{ast::ParamKindOrd, util::lev_distance::find_best_match_for_name}; </ins> use rustc_data_structures::fx::{FxHashMap, FxHashSet}; use rustc_errors::ErrorReported; use rustc_errors::{pluralize, struct_span_err, Applicability, DiagnosticId, FatalError};

Discussion:
The current diagnostics are a little ad hoc and rely on counting the number of mismatches (e.g. they will only produce an error for the first mismatch). It would be nice to produce diagnostics like: cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This is follow up work for
Please give more context on this. I am not sure the error message of which test should be improved.
This is more of the kind of issue opened to avoid forgetting about finishing some work, sorry for the confusion. That is, this is leaving a TODO to themselves about improving the diagnostics from .
Ok. I see. Thanks for the explanation.
That said, if is too busy to work on this, you could talk to them on Discord or Zulip to see what their plans were, and maybe turn this into a mentored issue.
The idea is essentially this. We currently emit errors telling the user that the generic arguments they provide are in the wrong order: However, what we'd like to do is suggest reordering the parameters, and let rustfix automatically apply the suggestion. I don't have the bandwidth to work on this at the moment, or any time soon, so if anyone is interested in tackling it, I'll be happy to mentor the issue.
would you mind if I take this up?
you're very welcome to! Let me know if you need any guidance in tackling this issue!
claim
Change:
<ins> error[E0308]: `if` and `else` have incompatible types --> $DIR/expr-type-error-plus-sized-obligation.rs:7:9 | LL |       let (a, _) = if true { |  __________________- LL | |         produce() | |         --------- expected because of this LL | |     } else { LL | |         (Vec::new(), &[]) | |         ^^^^^^^^^^^^^^^^^ expected `(Vec<Foo>, &[Bar])`, found `(Vec<_>, &[_; 0])` LL | |     }; | |_____- `if` and `else` have incompatible types | = note: expected tuple `(Vec<Foo>, &[Bar])` found tuple `(Vec<_>, &[_; 0])` error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0308`. </ins>

Discussion:
It's underlining the wrong argument. No response No response
I'm getting an entirely different and much more helpful error:
Are you sure you minimized the code correctly? Not sure how to repro the example you shared,
Arf, sorry about that... Also important to note, I'm using: I pushed the code with this issue . However it requires a mac to enter this code. Just running is enough to trigger it.
This should be re-minimized by someone who has a Mac then. label +E-needs-mcve
Minimization: Note that: in all cases (including when I ran the original code), there is now a more sensible type error, and the unsized local error is not actually pointing at the wrong thing, it's talking about the type of the part of the tuple unrelated to the if/else type mismatch. It seems like the type mismatch is causing the compiler to fail to properly perform the deref coercion of the , even though it's not the part of the tuple that has the type mismatch. Tested on versions:
label -E-needs-mcve
Change:
}) ``` <del> This looks reasonable, but watch what happens in this example: </del> <ins> Here's a simple use case that goes terribly wrong: </ins> ```text const char *state = "reticulating splines"; <del> LOG(state); </del> <ins> LOG(state) </ins> ``` <del> The program will likely segfault, after it tries to execute </del> <ins> This expands to </ins> ```text <del> printf("log(%d): %sn", state, state); </del> <ins> const char *state = "reticulating splines"; int state = get_log_state(); if (state > 0) { printf("log(%d): %sn", state, state); } </ins> ``` <ins> The second variable named `state` shadows the first one.  This is a problem because the print statement should refer to both of them. </ins> The equivalent Rust macro has the desired behavior. ```rust

Discussion:
As of the original docs on recursive macros are gone. We should have an example that clearly illustrates the increased power vs. the built-in repetition operator.
Change:
/// }; /// ``` /// <ins> /// Note: `move` closures may still implement [`Fn`] or [`FnMut`], even though /// they capture variables by `move`. This is because the traits implemented by /// a closure type are determined by *what* the closure does with captured /// values, not *how* it captures them: /// /// ```rust /// fn create_fn() -> impl Fn() { ///     let text = "Fn".to_owned(); /// ///     move || println!("This is a: {}", text) /// } /// ///     let fn_plain = create_fn(); /// ///     fn_plain(); /// ``` /// </ins> /// `move` is often used when [threads] are involved. /// /// ```rust

Discussion:
states: The second half of the second sentence is plain wrong and . modify labels: T-doc, T-libs, C-enhancement. (Is tagging T-doc ?) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim Yes, it allows for easy searching of doc issue (at least for me), with .
Change:
match x { Ok((_, _, false)) => { if self.eat(&token::Gt) { <del> let turbo_err = e.span_suggestion_verbose( </del> <ins> e.span_suggestion_verbose( </ins> binop.span.shrink_to_lo(), TURBOFISH_SUGGESTION_STR, "::".to_string(), Applicability::MaybeIncorrect, <del> ); if self.check(&TokenKind::Semi) { turbo_err.emit(); *expr = self.mk_expr_err(expr.span); return Ok(()); } else { match self.parse_expr() { Ok(_) => { turbo_err.emit(); *expr = self .mk_expr_err(expr.span.to(self.prev_token.span)); return Ok(()); } Err(mut err) => { turbo_err.cancel(); err.cancel(); } </del> <ins> ) .emit(); match self.parse_expr() { Ok(_) => { *expr = self.mk_expr_err(expr.span.to(self.prev_token.span)); return Ok(()); } Err(mut err) => { *expr = self.mk_expr_err(expr.span); err.cancel(); </ins> } } }

Discussion:
Reproducible at . <details<summaryBacktrace</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Seems to be introduced in :
Thanks for the report! A compiler panic is probably best reported in rust-lang/rust, even though it's being surfaced by a dev tool. I'll check with infra to see if it makes sense to move the issue We actually haven't made any changes to rustfmt in that window and the were highly minimal and certainly don't strike me as anything that would be the root cause. As such I suspect this is due to changes made elsewhere within the compiler mods, and would at least like for those folks to be aware (even if we need to make changes on the rustfmt side to address/work around) Would you be up for trying to boil it down to a more simple repro case?
Sure! Here is a MRE:
I have bisected to . cc I noticed that rustfmt is exiting with 0 even though it panicked. Is that normal?
I'll look into it today or tomorrow! claim
Outside a macro, no, (as was the case in the original full repro), but yes within the context of a macro as in the minimal rerpo. We have our calls to rustcparse internals wrapped in so the panic isn't really surfacing here, but rustfmt is still displaying the underlying error text prior to emitting formatting. This is done partly due to the fact that there are scenarios where those internals panic that we want to wrap to an error type, and partly due to there being some scenarios we want to ignore for the purposes of formatting due to how we attempt to deal with macros in the pre-expansion world where rustfmt lives. The latter being a result of limited macro support and leaving macros it can't handle alone, while carrying on formatting the rest of the file/crate/workspace
It looks like I'm still getting this error with (Coming from that was closed due to this one) Playground seems to produce it also:
I'll take another look then.
Yeah, this continues to ICE even in rustc. Fixed in another PR.