jiebi/CodeConvo huggingface dataset:
Change:
t("Hard-break  nsummary", "Hard-break summary"); t("hello [Rust] :)nn[Rust]: https://www.rust-lang.org", "hello Rust :)"); t("hello [Rust](https://www.rust-lang.org "Rust") :)", "hello Rust :)"); <del> t("code `let x = i32;` ...", "code <code>let x = i32;</code> ..."); t("type `Type<'static>` ...", "type <code>Type<'static></code> ..."); </del> <ins> t("code `let x = i32;` ...", "code <code>let x = i32;</code> …"); t("type `Type<'static>` ...", "type <code>Type<'static></code> …"); </ins> t("# top header", "top header"); t("## header", "header"); t("first paragraphnnsecond paragraph", "first paragraph");

Discussion:
Split off from . modify labels: T-rustdoc C-enhancement <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Uh, it looks like rustbot is editing my message and adding weird comments:
Cc
It looks like smart punctuation doesn't work in headers: ! wasn't able to reproduce this in pulldown itself; I'm guessing rustdoc is doing something special with headers. Cc
Triagebot does that as a way of easily storing data per-issue (we could do it in the database now, we didn't have one back then). But it's expected and shouldn't really be a problem.
Is this a good thing? Wouldn't keeping things as it is is better?
I think if you want to argue against doing this, giving reasons would be helpful. I personally think given that we already use emoji and otherwise non-ASCII characters readily, it should be reasonable for us to generate smart quotes as well.
I do think emoji and other non-ASCII characters if specified would be good except for smart quote. It's like saying to use greek question mark which is the same as semi-colon when a semi-colon was seen in documentation to make it look a bit cooler. One thing is copying, when others are copying the text, it will copy the utf-8 version of smart quotes which when displayed in terminals which in turn will make it look ugly and hard for text processing. Auto changing text to emoji I am okay with that. But not automatically changing single quotes, double quotes and semi-colons. Personally I don't see much benefit to that, usually if users want it they would specifically type it out but otherwise it would be similar. In my humble opinion, looks wise the smart quotes are more ugly, but easier to distinguish opening and closing quotes, but still when copied and pasted it may not look so good.
Change:
(middle-of-fn3 (16 4)) (middle-of-struct (21 10)) (before-start-of-struct (19 0)) <del> (after-end-of-struct (23 0)))) </del> <ins> (after-end-of-struct (23 0)) (blank-line-indent-start (3 0)) (blank-line-indent-target (3 4)) (closing-brace-indent-start (8 1)) (closing-brace-indent-target (8 5)) (middle-push-indent-start (13 2)) (middle-push-indent-target (13 9)) (after-whitespace-indent-start (13 1)) (after-whitespace-indent-target (13 8)) (middle-pull-indent-start (15 19)) (middle-pull-indent-target (15 12)))) </ins> (defun rust-get-buffer-pos (pos-symbol) "Get buffer position from POS-SYMBOL.

Discussion:
There are several common cases where the emacs mode gets the indentation incorrect. I'll list the examples as I believe they should be formatted. indent after open paren with no argument: with arguments: field names:
Oh, and the motivating example for filing the bug: comments don't work quite right. and also you should be able to hit M-q and have it reflow correctly.
I've found trailing line comments breaks the indentation of the next line: (Not sure if this is worth a separate bug.)
Another example is a pattern relative to an indented match: Also, I believe patterns in general are indented incorrectly, though admittedly I'm not sure what the standard is. My preference is to keep all patterns at the same level of indentation, as shown here:
If we're going to fix , we should try to also take the time to fix the other doc comment variations, namely , if possible.
part of
Change:
<ins> error[E0433]: failed to resolve: maybe a missing crate `clippy`? --> $DIR/tool-mod-child.rs:2:5 | LL | use clippy::a::b; |     ^^^^^^ maybe a missing crate `clippy`? error[E0432]: unresolved import `clippy` --> $DIR/tool-mod-child.rs:1:5 | LL | use clippy::a; |     ^^^^^^ maybe a missing crate `clippy`? error[E0433]: failed to resolve: maybe a missing crate `rustdoc`? --> $DIR/tool-mod-child.rs:5:5 | LL | use rustdoc::a::b; |     ^^^^^^^ maybe a missing crate `rustdoc`? error[E0432]: unresolved import `rustdoc` --> $DIR/tool-mod-child.rs:4:5 | LL | use rustdoc::a; |     ^^^^^^^ maybe a missing crate `rustdoc`? error: aborting due to 4 previous errors Some errors have detailed explanations: E0432, E0433. For more information about an error, try `rustc --explain E0432`. </ins>

Discussion:
Happens on stable and nightly. Compiler crash <details<summary<strongBacktrace</strong</summary<p</p</details
This regression looks to be really old. Could not pinpoint a specific commit while bisecting
I don't think this is a regression, the flag just didn't exist before 1.31 (the panic doesn't occur without ).
Assigning and removing as in the prioritization working group. label: +P-low -I-prioritize
Change:
target_linker = self.get_toml("linker", build_section) if target_linker is not None: env["RUSTFLAGS"] += "-C linker=" + target_linker + " " <ins> if self.get_toml("deny-warnings", "rust") != "false": env["RUSTFLAGS"] += "-Dwarnings -Drust_2018_idioms -Dunused_lifetimes " </ins> env["PATH"] = os.path.join(self.bin_root(), "bin") +  os.pathsep + env["PATH"]

Discussion:
When using 1.38 beta to bootstrap itself, I get:
This is expected and not a supported bootstrapping configuration; if you want to not see these errors you'll want to either bootstrap with N-1 compiler (so, in this case, 1.37) or I believe remove from bootstrap and some other libraries, as well as set deny-warnings in to false. Note that only the 1.37 bootstrap method is officially supported as "guaranteed to work", the deny warnings fix is more of a hack. Closing as won't fix.
Huh? In the past this was always fixed as it's a very common practice for distribution packaging (I don't know of a single packager not doing that). See e.g. or (in which you sort of acknowledged that yourself) deny-warnings is already set to false in , so I guess it somehow doesn't apply to building bootstrap itself.
I hope is an acceptable compromise wrt this. Thanks for pointing out the deny-warnings option which I forgot (since it has been set to false forever for us and never had any effect on the build of bootstrap itself)
Yeah is great; in this case the unsafe block is needed for 1.37 but not on 1.38; if there was an easy way to support both use cases then I'd be happy to accept a PR targeting beta but I'm not personally aware of one -- it looks like we don't seem to have an or similar? We try to support distros and such where possible in this configuration, it's just that this specific case I'm not sure how much we can do. deny-warnings=false is always my recommendation when using a different bootstrap compiler, or manual patches to the code.
Change:
<ins> // Copyright 2017 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. enum P { C(PC), } enum PC { Q, QA, } fn test(proto: P) { match proto { P::C(PC::Q) => (), } } fn main() {} </ins>

Discussion:
The minimum code example: compiling:
Thats a regression from stable → beta/nightly.
Introduced by .
Change:
} assert!(x.try_borrow_mut().is_some()); } <ins> #[test] fn as_unsafe_cell() { let c1: Cell<uint> = Cell::new(0u); c1.set(1u); assert_eq!(1u, unsafe { *c1.as_unsafe_cell().get() }); let c2: Cell<uint> = Cell::new(0u); unsafe { *c2.as_unsafe_cell().get() = 1u; } assert_eq!(1u, c2.get()); let r1: RefCell<uint> = RefCell::new(0u); *r1.borrow_mut() = 1u; assert_eq!(1u, unsafe { *r1.as_unsafe_cell().get() }); let r2: RefCell<uint> = RefCell::new(0u); unsafe { *r2.as_unsafe_cell().get() = 1u; } assert_eq!(1u, *r2.borrow()); } </ins>

Discussion:
This would be useful in cases where we mostly want to enforce guarantees but need to break the rules in one place. (e.g. the Servo interface to html5ever which needs to GC-trace a mutably-borrowed parser)
Similarly, this would be useful for RAII classes that need to be fail-proof in the face of task failure while there are outstanding RefCell borrows.
I don't think that case should be an issue; the / destructors have to run before their 's. They don't right now in some cases due to some unsoundness problems but that will be fixed: .
Same for , please, for
Does the accessor itself need to be ? I don't think so, because the relevant ops are and we're only handing out shared references to it.
Change:
}), }, MetaItemKind::List(ref items) => { <ins> let orig_len = items.len(); </ins> let sub_cfgs = items.iter().filter_map(|i| Cfg::parse_nested(i, exclude).transpose()); let ret = match name { sym::all => sub_cfgs.fold(Ok(Cfg::True), |x, y| Ok(x? & y?)), sym::any => sub_cfgs.fold(Ok(Cfg::False), |x, y| Ok(x? | y?)), sym::not => { <del> let mut sub_cfgs = sub_cfgs.collect::<Vec<_>>(); if sub_cfgs.len() == 1 { Ok(!sub_cfgs.pop().unwrap()?) </del> <ins> if orig_len == 1 { let mut sub_cfgs = sub_cfgs.collect::<Vec<_>>(); if sub_cfgs.len() == 1 { Ok(!sub_cfgs.pop().unwrap()?) } else { return Ok(None); } </ins> } else { Err(InvalidCfgError { msg: "expected 1 cfg-pattern", span: cfg.span }) }

Discussion:
Context: CC
Thanks for opening this issue! Someone from the rustdoc team will try to get back to it whenever possible.
It doesn't look too difficult. I'm going to try to make a PR for it myself, and I'll update here with or without progress.
Even better! :smile: I'll assign you to the issue in the meantime then.
Change:
| LL |         println!("{:?}", take_array_from_mut(&mut arr, i)); |                          ^^^^^^^^^^^^^^^^^^^ cannot infer the value of const parameter `N` declared on the function `take_array_from_mut` <ins> | help: consider specifying the const argument | LL |         println!("{:?}", take_array_from_mut::<N>(&mut arr, i)); |                          ^^^^^^^^^^^^^^^^^^^^^^^^ </ins> error: aborting due to previous error

Discussion:
At the moment, we simply emit errors like: It would be good to suggest to the user how to fix this, like with uninferred type arguments.
cc
Stu over has picked this issue up.
Change:
fn foo(x: bool) -> Result<f64, i32> { if x { Err(42) //~ ERROR mismatched types <ins> //| HELP you might have meant to return this value } Ok(42.0) } async fn bar(x: bool) -> Result<f64, i32> { if x { Err(42) //~ ERROR mismatched types //| HELP you might have meant to return this value </ins> } Ok(42.0) }

Discussion:
Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should look like it does for the : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label +A-async-await +D-papercut
I'm gonna try and take a shot at this. claim
Thanks for putting up a PR so quickly, label +AsyncAwait-Triaged +AsyncAwait-Polish
Change:
// Warn for non-block expressions with diverging children. match expr.node { ExprKind::Block(..) | ExprKind::Loop(..) | ExprKind::Match(..) => {}, <ins> ExprKind::Call(ref callee, _) => self.warn_if_unreachable(expr.hir_id, callee.span, "call"), ExprKind::MethodCall(_, ref span, _) => self.warn_if_unreachable(expr.hir_id, *span, "call"), </ins> _ => self.warn_if_unreachable(expr.hir_id, expr.span, "expression"), }

Discussion:
rustc warns that the entire line is an unreachable expression however the code is clearly executed as can be see If the line was truly unreachable, there would be no panic... This bug appears on stable, beta and nightly
The is the unreachable part, so perhaps the error should be rephrased and pointed at that function call only
Hmm, so the span is wrong?
the order of execution is panic! and then everything else, so in some sense everything but the panic is unreachable. I'm not sure what a good span for that would be.
The method receiver is evaluated first, so the and calls still happen. The span can point just at the .
Ah, hm, I didn't expect that to be the case, but it makes sense. Then this seems relatively straightforward as to what the expected output is at least.
I feel like this should also add a note that the panic is called before everything else. It could also suggest but that seems more like a clippy lint.
Similar case: Maybe we can simply add a note that won't be called because evaluation of its arguments leaves the current code path. I agree that suggestion is indeed too specific and may be better suited to clippy. If this is acceptable, I would like to pick it up! As long as it's fine for me to progress more slowly than normal
GitHub wasn't clever enough to read that the PR said "might close" instead of "close." The PR seems to imply more work can be done on this.
Change:
<ins> #![feature(rustc_attrs)] #[rustc_dummy = b"ﬃ.rs"] //~ ERROR byte constant must be ASCII fn main() {} </ins>

Discussion:
Also tested on and , it errored without ICEing on 1.49 and ICEd on 1.50 so modify labels: +regression-from-stable-to-beta <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Assigning as discussed as part of the and removing .
searched nightlies: from nightly-2020-12-01 to nightly-2021-01-21 regressed nightly: nightly-2020-12-11 searched commits: from ... regressed commit: It's cc <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.2</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
glacier ""
I spent some time looking at this. will not ICE in stable because the assert should be compiled away. What will happen is an incorrect span in the output duplicating a prior error. think this is caused by the double duty that s and have. We sometimes treat as indices into a byte buffer, but there's an additional piece of info in s that isn't carried over with , namely whether the byte position is the beginning or the end of a . This matters because when doing operations being or not being the end is the difference between having to do or not. I believe this is the underlying cause of these issues. if you're taking on this you might want to look at modifying to accept a new stating whether the is the start or end (and depending on that whether we should the assertion and likely other logic or not). are a bunch of small tweaks to these diagnostics that can be done as a separate PR by changing with and even provide a structured suggestion instead of the .
Why would the assert be compiled away in stable but not beta and nightly? I'm pretty sure the issue here is that the PR that causes this ICE was merged for 1.50 (which is the current beta version), not 1.49 (which is the current stable).
Am I wrong to understand that in controls whether ions get evaluated, which in turn is only enabled if ?

Regardless, a small patch to remove that assertion would get around the ICE without major negative impact (the label is shifted one char to the left and nothing else), if we don't cut a more comprehensive PR before the next release.
I'm not sure if that gets rid of calls (it may only get rid of calls). However, what I'm referring to is that you said it wouldn't ICE in stable, whereas my understanding is that if it ICEs in beta, it will ICE in the next stable.
taking over, I've figured out the problem.
Re-opening because this still affects beta and the PR needs to be backported.
The fix landed in 1.51.0, and I cherry-picked a fix for the 1.50.0 stable branch. If the cherry-pick is accepted by CI then we can close this issue!
CI passed on the test runner in the 1.50.0 promotion, but it timed out on an unrelated builder, so the fix worked! Closing this.
Change:
expected: Expectation<'tcx>) -> Ty<'tcx> { let original_callee_ty = self.check_expr(callee_expr); <ins> let expr_ty = self.structurally_resolved_type(call_expr.span, original_callee_ty); </ins> <del> let mut autoderef = self.autoderef(callee_expr.span, original_callee_ty); </del> <ins> let mut autoderef = self.autoderef(callee_expr.span, expr_ty); </ins> let result = autoderef.by_ref().flat_map(|(adj_ty, idx)| { self.try_overloaded_call_step(call_expr, callee_expr, adj_ty, idx) }).next();

Discussion:
This code works: As does placing it in an array: However, using a fails: Instead, it must be explicitly dereferenced: It's even more annoying for :
The fact that this works for arrays, but not Vec suggests that it's probably related to associated types. It's possible that wherever the coercion from to is done sees instead.
This doesn't seem to be fully resolved:
That may be instead.
Change:
*self = snapshot; Err(err) } <ins> /// Get the diagnostics for the cases where `move async` is found. /// /// `move_async_span` starts at the 'm' of the move keyword and ends with the 'c' of the async keyword pub(super) fn incorrect_move_async_order_found( &self, move_async_span: Span, ) -> DiagnosticBuilder<'a> { let mut err = self.struct_span_err(move_async_span, "the order of `move` and `async` is incorrect"); err.span_suggestion_verbose( move_async_span, "try switching the order", "async move".to_owned(), Applicability::MaybeIncorrect, ); err } </ins> }

Discussion:
I tried this code: This should give a suggestion to reorder the keywords to , something like: Right now it gives this error, which is not very helpful: Tested on 1.48.0 and 1.50.0-nightly (2020-12-03 ) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Releasing assignment as I'm not really sure how to fix this at the moment. release-assignment
This could be handled directly in the parser code which generates the above diagnostic.
claim
Change:
<ins> error: this file contains an unclosed delimiter --> $DIR/unused_parens_multibyte_recovery.rs:11:17 | LL | fn f(){(print!(á |       --      - ^ |       ||      | |       ||      unclosed delimiter |       |unclosed delimiter |       unclosed delimiter error: this file contains an unclosed delimiter --> $DIR/unused_parens_multibyte_recovery.rs:11:17 | LL | fn f(){(print!(á |       --      - ^ |       ||      | |       ||      unclosed delimiter |       |unclosed delimiter |       unclosed delimiter error: this file contains an unclosed delimiter --> $DIR/unused_parens_multibyte_recovery.rs:11:17 | LL | fn f(){(print!(á |       --      - ^ |       ||      | |       ||      unclosed delimiter |       |unclosed delimiter |       unclosed delimiter error: format argument must be a string literal --> $DIR/unused_parens_multibyte_recovery.rs:11:16 | LL | fn f(){(print!(á |                ^ | help: you might be missing a string literal to format with | LL | fn f(){(print!("{}", á |                +++++ error: aborting due to 4 previous errors </ins>

Discussion:
Reported by here: (Note that but does not fix this bug.)
searched nightlies: from nightly-2021-01-07 to nightly-2021-12-24 regressed nightly: nightly-2021-09-12 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
This regression was introduced in . cc
Not a fix, but if I make this change then there is no longer an ICE and I get
Thanks for opening the issue If someone finds a fix but doesn't know how to add the test, this pull request which solves a similar ICE has an example of how to add a test when there is a missing newline:
Change:
Vec::from_iter(self.resolver.cstore().trait_impls_in_crate_untracked(cnum)); let all_inherent_impls = Vec::from_iter(self.resolver.cstore().inherent_impls_in_crate_untracked(cnum)); <ins> let all_lang_items = Vec::from_iter(self.resolver.cstore().lang_items_untracked(cnum)); </ins> // Querying traits in scope is expensive so we try to prune the impl and traits lists // using privacy, private traits and impls from other crates are never documented in

Discussion:
(Using + ) (Minimized from ) : <details<summary<strongBacktrace</strong</summary<p</p</detailscc
One thing I forgot to do is check that my minimization is exhaustive. After deleting all the from the original crate it still ICEs, so there must be another way that it is triggering this too.
Could this issue be related/duplicate of (and therefore fixed by )? Also, perhaps replace the team label with ?
I assume you meant ? That was included in which I tested with (we have a collection of failing crates in that I am rebuilding as each fix for the fallout from lands).
Fixed in
Change:
(symbol_visitor.live_symbols, symbol_visitor.ignored_derived_traits) } <del> struct DeadVariant { </del> <ins> struct DeadItem { </ins> def_id: LocalDefId, name: Symbol, level: lint::Level,

Discussion:
At some point between (works) and (does not work) the following stopped compiling: I have not bisected for the exact commit that broke this. I have only tried to reproduce this error using . It's possible that this is also broken for other lints. PR:
Without properly double-checking this, I'm certain that this regressed in (merged April 14) which condensed multiple diagnostics triggered by methods into a single one for readability meddling with the affairs of . I don't know how is implemented but if it only considers the first primary span of a (buffered) lint diagnostic, then one fix will be changing the relevant part of the code to consider all primary spans. label T-compiler A-lint F-lintreasons
Change:
<ins> // aux-build:collect_hidden_types.rs use collect_hidden_types::Service; use std::future::Future; use std::pin::Pin; use std::task::Context; // build-pass // edition:2018 extern crate collect_hidden_types; fn broken(mut a: collect_hidden_types::A, cx: &mut Context<'_>) { let mut fut = a.call(()); let _ = unsafe { Pin::new_unchecked(&mut fut) }.poll(cx); } pub async fn meeb(cx: &mut Context<'_>) { broken(collect_hidden_types::A, cx); } fn main() {} </ins>

Discussion:
This is probably a smaller reproduction of .
If anyone has a quick and dirty idea for how to force an type to resolve, I think I could finish minifying the above pretty easily.
Same ICEs without async:
Updated reproducing code to remove need for .
I'm fairly certain this is related to the visibility of types that appear in an type. Specifically, in the code above, if in is changed to , it compiles fine.
ping icebreakers-cleanup-crew
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rust- cc
triage: P-high until we assess severity (the bug written depends on a feature flag) we want to know if that's really needed for the issue to reproduce.
fwiw, my guess is that the feature flag is not necessary, and that the relevant can be replaced by an .
So, for cleanup crew ICE-breakers who might take a look at this: (a) we should try to get a backtrace with line numbers (b) we should see if this is a regression and track down the cause (maybe jump back a few months and see if the corresponding nightly from that time works?) (c) it'd be interesting to see if we can remove the from the impl and thus reproduce on something that builds on stable. As noted, an inherent on could trigger it, or perhaps something like:
Downgrading priority for now until we can reproduce without the gate.
related
Interestingly enough, an inherent method like that does not reproduce the issue, so it appears the existential type in associated type position is also needed.
I just hit the same issue on nightly: Reproduction is huge though: Just it. This happened after I upgraded dependency from to . I don't see feature used in .
That is which was fixed two days ago. Try updating rustc.
Indeed, thanks!