jiebi/CodeConvo huggingface dataset:
Change:
[[package]] name = "pulldown-cmark" <del> version = "0.9.3" </del> <ins> version = "0.9.6" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" <del> checksum = "77a1a2f1f0a7ecff9c31abbe177637be0e97a0aef46cf8738ece09327985d998" </del> <ins> checksum = "57206b407293d2bcd3af849ce869d52068623f19e1b5ff8e8778e3309439682b" </ins> dependencies = [ <del> "bitflags 1.3.2", </del> <ins> "bitflags 2.4.1", </ins> "memchr", "unicase", ]

Discussion:
Footnote lines, when written on adjacent lines, squish into a single footnote: ! -paste the following snippet at the top of a new module: . that the footnotes have been incorrectly rendered as a single footnote. No response One workaround is to separate the footnotes with empty lines: It's not pretty, though.
Transferring to Rust as it is an issue with doc generation.
I think this is somewhat working as intended. Footnote definitions need to be separated by blank lines. That is not ideal, and I think is the closest thing tracking this issue.
This is the expected behaviour from commonmark as you can see . Closing then.
Hi CommonMark does not support footnotes at all. RustDoc is very explicit that it does, so the behaviour of RustDoc's footnotes should probably be based on whatever library it uses for Markdown parsing rather than actual CommonMark. You can see from this simple example that : But :
Oh I see, my apologies. Reopening the issue then.
Triage: Still an issue.
Taking a look.
Change:
self.cx.force_mode = orig_force_mode; // Finally incorporate all the expanded macros into the input AST fragment. <del> let mut placeholder_expander = PlaceholderExpander::default(); </del> <ins> let mut placeholder_expander = PlaceholderExpander::new(self.cx, self.monotonic); </ins> while let Some(expanded_fragments) = expanded_fragments.pop() { for (expn_id, expanded_fragment) in expanded_fragments.into_iter().rev() { placeholder_expander

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. --Context: "regression" caught by future-proofing CI from After working on reducing the code, I've identified the root cause of the ICE. For context: this patterns stem from "old" Rust code wanting to support proc-macros emitting item definitions in "statement" position for Rust: the trick is to use the to wrap an item-defs-emitting proc-macro call inside a function so that Rust doesn't interpret it as a statement, refusing the then-unstable stmt-emitting proc-macro call (). <!-- 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. --: Bonus: the ICE seems to have been introduced in between today's () and yesterday's nightly. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</detailscc I suspect this is up your alley
searched nightlies: from nightly-2021-08-01 to nightly-2021-08-10 regressed nightly: nightly-2021-08-07 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
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high +A-macros
Thanks nice job
Change:
<ins> // Copyright 2014 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. // Check that we check fns appearing in constant declarations. // Issue #22382. const MOVE: fn(&String) -> String = { fn broken(x: &String) -> String { return *x //~ ERROR cannot move } broken }; fn main() { } </ins>

Discussion:
Functions defined inside of declarations seem to ignore all lifetimes and mutability. This allows for massively violating the safety guarantees of Rust:
Nominating, this seems incredibly serious.
According to it seems that the borrowck isn't bothering to walk statics/consts (see ). Presumably this code was never updated when it became possible to use blocks as the initializer expression.
Um, yeah, not good. I'll investigate soonish, presuming doesn't get there first.
P-back-compatlang, 1.0 beta
Change:
TypeAlias(InternedObligationCauseCode<'tcx>, Span, DefId), } <ins> /// Whether a value can be extracted into a const. /// Used for diagnostics around array repeat expressions. #[derive(Copy, Clone, Debug, PartialEq, Eq, HashStable, TyEncodable, TyDecodable)] pub enum IsConstable { No, /// Call to a const fn Fn, /// Use of a const ctor Ctor, } crate::TrivialTypeTraversalAndLiftImpls! { IsConstable, } </ins> /// The 'location' at which we try to perform HIR-based wf checking. /// This information is used to obtain an `hir::Ty`, which /// we can walk in order to obtain precise spans for any

Discussion:
I'm basing this suggestion on two things. One, that if you follow it, the code compiles: and two, that the diagnostic help you get when you try to use a in the repeat position suggests something very similar, see "other cases." It would require the compiler to know that a value that is attempted to be repeated is able though, which I don't know whether it can, but I figured I'd suggest this, and you can reject it if it isn't possible to do. Alternatively, the help text could say something like "if the value can be made , consider creating [...]" I was inspired to make this issue based on the output you get when you try to use a as an array initializer. For instance, the code produces the output No response
hey why im getting this error message all over my github repository ! whenever i commit some changes, The first changes i able to create pull request but after some other changes im not able to do that why im getting these error ! Please help
I don't think your comment is related to this issue? If this is a problem you've encountered while trying to fix this issue, please reach out on instead.
Change:
# Unless you're developing for a target where Rust CI doesn't build a compiler # toolchain or changing LLVM locally, you probably want to set this to true. # <del> # It's currently false by default due to being newly added; please file bugs if # enabling this did not work for you on x86_64-unknown-linux-gnu. # Other target triples are currently not supported; see #77084. </del> <ins> # This is false by default so that distributions don't unexpectedly download # LLVM from the internet. # # All tier 1 targets are currently supported; set this to `"if-supported"` if # you are not sure whether you're on a tier 1 target. </ins> # # We also currently only support this when building LLVM for the build triple. #

Discussion:
From Switching to static linking would preclude any of the improvements from , so it would be better to use dynamic linking instead which would allow any contributor to get started without building LLVM from source or using system LLVM. That said, it sounds like dynamic linking will be very hard to do on other platforms. cc
Cc - do we know what the right way to bring the issues (bugs?) I found to LLVM developers? Are there active maintainers of LLVMs build system?
LLVM’s bugzilla is pretty much the only place for bug reports. If its something less defined than a precise bug report, talking it out on the mailing lists is the way to go.
In which way is static linking making downloaded LLVM impossible?
I don't think it's impossible to download/ship the statically linked LLVM, it's something I want to explore. That said, we want to move to dynamically linking LLVM because we ideally want to be applying ThinLTO to LLVM everywhere, not just on x86_64-unknown-linux-gnu, and since LTO happens at link-time, we want that to happen once, not on the multiple LLVM links occurring during CI.
Change:
/// [Reference]: ../reference/statements.html#let-statements mod let_keyword { } <ins> #[doc(keyword = "while")] // /// Loop while a condition is upheld. /// /// A `while` expression is used for predicate loops. The `while` expression runs the conditional /// expression before running the loop body, then runs the loop body if the conditional /// expression evaluates to `true`, or exits the loop otherwise. /// /// ```rust /// let mut counter = 0; /// /// while counter < 10 { ///     println!("{}", counter); ///     counter += 1; /// } /// ``` /// /// Like the [`for`] expression, we can use `break` and `continue`. A `while` expression /// cannot break with a value and always evaluates to `()` unlike [`loop`]. /// /// ```rust /// let mut i = 1; /// /// while i < 100 { ///     i *= 2; ///     if i == 64 { ///         break; // Exit when `i` is 64. ///     } /// } /// ``` /// /// As `if` expressions have their pattern matching variant in `if let`, so too do `while` /// expressions with `while let`. The `while let` expression matches the pattern against the /// expression, then runs the loop body if pattern matching succeeds, or exits the loop otherwise. /// We can use `break` and `continue` in `while let` expressions just like in `while`. /// /// ```rust /// let mut counter = Some(0); /// /// while let Some(i) = counter { ///     if i == 10 { ///         counter = None; ///     } else { ///         println!("{}", i); ///         counter = Some (i + 1); ///     } /// } /// ``` /// /// For more information on `while` and loops in general, see the [reference]. /// /// [`for`]: keyword.for.html /// [`loop`]: keyword.loop.html /// [reference]: ../reference/expressions/loop-expr.html#predicate-loops mod while_keyword { } </ins> #[doc(keyword = "loop")] // /// Loop indefinitely.

Discussion:
I noticed the keyword seems to be missing from the [official documentation][docs]. Keywords like and are documented. Nor does come up when searching at the top. Is there a reason for it missing? [docs]:
These are probably just missing because nobody documentation for them yet, so feel free to send a PR.
If anyone is interested, you need to add documentation here:
I will take care of this one :)
Cool! Wanted to do it, but haven't been able to start on it yet. Perfect if you can take it over.
In that case, it will be nice to have you review the PR:
Partially resolved by I think this can be closed in favor of . What do you think ?
will close this when merged, and it addresses specifically, so we can also wait for that to land
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. // hopefully this doesn't cause an ICE pub fn foo() { extern crate std; } </ins>

Discussion:
On the latest nightly ( 2017-11-25) there's an ICE when generating the docs for the crate. Presumably somewhere along the line internal bookkeeping got confused and an invalid was generated (or a valid one was deleted), resulting in a panic during the phase 3 analysis passes. It looks like this is a regression in the latest nightly because it was works just fine on the build. Minimal Example: This was on an up-to-date Arch Linux machine.
For reference: ...
Simplified repro, no dependency needed:
Hold on, something's wrong. Edit: I've inverted the failure condition when bisecting The actual regressing commit is
The issue here is likely due to the everybody-loops pass moved to a different place. Previously it was called immediately after phase 1, now it is called in the middle of phase 2. I'm now trying to see if putting it at the end of phase 2 would help. If not we'd put it back to the beginning of phase 2. Edit: neither is working.
Also happens to
Can we prioritize fixing this? It looks like a relatively widespread problem...
Sure. Will take a look in the next days.
Minimized: I believe I see what's going on, will try to make a fix.
I've posted a fix for this issue at
Change:
<ins> // run-rustfix pub fn func<F>() where F: FnOnce -> () {} //~^ ERROR expected one of //~| NOTE expected one of //~| NOTE `Fn` bounds require arguments in parentheses fn main() {} </ins>

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:
} } <del> query is_impossible_method(key: (DefId, DefId)) -> bool { </del> <ins> query is_impossible_associated_item(key: (DefId, DefId)) -> bool { </ins> desc { |tcx| <del> "checking if `{}` is impossible to call within `{}`", </del> <ins> "checking if `{}` is impossible to reference within `{}`", </ins> tcx.def_path_str(key.1), tcx.def_path_str(key.0), }

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. --The command causes an ICE error. This happens when we use the features of () in different workspaces. workspace- : workspace- : <!-- 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 --
label T-rustdoc
label -needs-triage A-cross-crate-reexports Ah lol, just noticed that we're also leaking the desugared form of RPITITs (the assoc ty) for a slightly altered non-icing version of this code (still cross-crate tho). Also needs to be addressed at some point, taking a mental note. claim
Change:
let res = test::run_tests_console(&opts, tests); match res { Ok(true) => {} <del> Ok(false) => panic!("Some tests failed"), </del> <ins> Ok(false) => { // We want to report that the tests failed, but we also want to give // some indication of just what tests we were running. Especially on // CI, where there can be cross-compiled tests for a lot of // architectures, without this critical information it can be quite // easy to miss which tests failed, and as such fail to reproduce // the failure locally. eprintln!( "Some tests failed in compiletest suite={}{} mode={} host={} target={}", config.suite, config.compare_mode.map(|c| format!(" compare_mode={:?}", c)).unwrap_or_default(), config.mode, config.host, config.target ); std::process::exit(1); } </ins> Err(e) => { // We don't know if tests passed or not, but if there was an error // during testing we don't want to just suceeed (we may not have // tested something), so fail. <ins> // // This should realistically "never" happen, so don't try to make // this a pretty error message. </ins> panic!("I/O failure during tests: {:?}", e); } }

Discussion:
When compiletest fails, it prints an error summary like this at the end: However, there is one very important bit of information that I cannot gleam from this information: what are the host and target architectures that were tested! Figuring this out requires scrolling up quite a bit to where this test beings (and carefully not scrolling up too far because then one might look at the wrong test). See for an example where this confused people. I have also been confused by this multiple times in the past, e.g. using the name of the CI runner to incorrectly deduce what the architecture(s) are (and not realizing that some of our runners run tests for quite a few different targets). So I think in case of a failure, that summary at the end should repeat the important information that is printed at the top of the test run:
Cc
And also it would be nice if when it ignored a test because it was the wrong platform, it showed some indication of that, because otherwise it looks like it ran the test and it passed. Perhaps show a question mark ()? (We already use for tests that were ignored because they were already run and passed.)
AFAIK should already be used for all kinds of "ignored", including directives.
Turns out these messages are printed by bootstrap, not compiletest: However, detecting failures and exiting is done a few layers deeper: In case of failure, never returns or unwinds (except if fail-fast is off). I am not sure how to best adjust this to print an error before exiting (or to always print an error after the process finished, whether it succeeded or failed). any advice? If we just want this to happen when fail-fast is off, that would be easy, but I am not sure if that ever applies.
Change:
<ins> // check-pass #![feature(const_generics)] //~^ WARN the feature `const_generics` is incomplete and may cause the compiler to crash fn takes_closure_of_array_3<F>(f: F) where F: Fn([i32; 3]) { f([1, 2, 3]); } fn takes_closure_of_array_3_apit(f: impl Fn([i32; 3])) { f([1, 2, 3]); } fn returns_closure_of_array_3() -> impl Fn([i32; 3]) { |_| {} } fn main() {} </ins>

Discussion:
() Gives the error: This compiles fine with const_generics not enabled, and is a regression cc
(discovered by
cc Simplified:
Isn't this expected fallout?
This is an expected consequence of
Seems like is what's supposed to eventually fix this?
triage: P-medium (nightly-only regression on feature that is known to have bugs)
I think we've discussed this before, but what do you think of special-casing literals, to unblock at least some common usecases like this?
I can't reproduce on master, this may have gotten fixed? (Note that the playground is severely outdated, a fix is underway for that though)
pointed out that most likely fixed this.
Change:
<ins> //! Verify that the `decls` module implicitly added by the compiler does not cause `missing_docs` //! warnings. // compile-pass // force-host // no-prefer-dynamic #![crate_type = "proc-macro"] #![deny(missing_docs)] extern crate proc_macro; use proc_macro::*; /// Foo1. #[proc_macro] pub fn foo1(input: TokenStream) -> TokenStream { input } </ins>

Discussion:
crates, when compiled with , generate invalid warnings about missing documentation. The following simple crate demonstrates the error. : : I expect this to compile cleanly since there is a crate-level doc comment and a doc comment for the public function. Instead, compiling gives: which makes no sense since line 1 is a comment. Compiler version - latest stable, but fails on yesterday's nightly (2017-05-14) too: :
cc (tracking issue)
I am hitting the same problem. This issue is preventing for proc-macro crates (I haven't found a work around). That's pretty annoying :-/ Rust 1.24.1.
Same here. Is there a fix for this?
Seems to still be happening.
Fails on stable, beta, and nightly still.
On a proc-macro crate in , I'm getting two warnings: and with no line numbers.
shows that the compiler is inserting a with a . I didn't find the code that does the insertion in a very brief search.
So I guess the low-effort fix here is slapping on that ? EDIT: Looks like the code that generates that is ?
Thanks Turns out my working copy wasn't updated like I thought so searching through it didn't work. PR just submitted.
Change:
<ins> error[E0432]: unresolved import `Foo` --> $DIR/issue-38054-do-not-show-unresolved-names.rs:11:5 | 11 | use Foo; |     ^^^ no `Foo` in the root error[E0432]: unresolved import `Foo1` --> $DIR/issue-38054-do-not-show-unresolved-names.rs:13:5 | 13 | use Foo1; |     ^^^^ no `Foo1` in the root error: aborting due to 2 previous errors </ins>

Discussion:
Sometimes it is very useful when rustc figures out that the faulty module use you just made is probably just a typo and directs you a potential match (thanks for that!). However it also directs you to potential matches which haven't been found either in certain cases, for example compiling currently (2016-11-28) yields with both stable and nightly the following output: While this is merely a suggestion displayed and shouldn't cause any harm at all maybe it might still be worth to check if what is suggested was actually found in the current scope. Or would that be too expensive (e.g. overhead in tracking what was already successfully imported and what not) and is thus left as is by design?
Is this easy to fix ? If so - maybe worth marking as so and mentioning on Rust Weekly ?
Yeah, I believe this can be fixed by replacing with .
I think I can take this, if it hasn't been worked on so far!
go for it
How can I assign myself?
Not sure if you can via github, due to permissions, but you can just start working on it :) There's a trace in the comments, anyone looking for more work would see them hopefully here in this issue.
Change:
<del> error[E0267]: `break` inside of an `async` block </del> <ins> error[E0267]: `break` inside `async` block </ins> --> $DIR/async-block-control-flow-static-semantics.rs:32:9 | LL | /     async { LL | |         break 0u8; <del> | |         ^^^^^^^^^ cannot `break` inside of an `async` block </del> <ins> | |         ^^^^^^^^^ cannot `break` inside `async` block </ins> LL | |     }; | |_____- enclosing `async` block <del> error[E0267]: `break` inside of an `async` block </del> <ins> error[E0267]: `break` inside `async` block </ins> --> $DIR/async-block-control-flow-static-semantics.rs:39:13 | LL | /         async { LL | |             break 0u8; <del> | |             ^^^^^^^^^ cannot `break` inside of an `async` block </del> <ins> | |             ^^^^^^^^^ cannot `break` inside `async` block </ins> LL | |         }; | |_________- enclosing `async` block

Discussion:
Same issue as which was for blocks. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim