jiebi/CodeConvo huggingface dataset:
Change:
Found via and seems like a different issue than with rustdoc JSON is built labels +A-rustdoc-json +T-rustdoc +I-ICE +requires-nightly +E-needs-mcve
MCVE: ` modify labels: -E-needs-mcve

Discussion:
} types::ItemEnum::Method(_) <ins> | types::ItemEnum::Module(_) </ins> | types::ItemEnum::AssocConst { .. } | types::ItemEnum::AssocType { .. } | types::ItemEnum::PrimitiveType(_) => true, <del> types::ItemEnum::Module(_) | types::ItemEnum::ExternCrate { .. } </del> <ins> types::ItemEnum::ExternCrate { .. } </ins> | types::ItemEnum::Import(_) | types::ItemEnum::StructField(_) | types::ItemEnum::Variant(_)

<ins> //! Regression test for <https://github.com/rust-lang/rust/issues/100531> #![feature(no_core)] #![no_core] #![crate_name = "export_extern_crate_as_self"] // ignore-tidy-linelength // @is export_extern_crate_as_self.json "$.index[*][?(@.kind=='module')].name" "export_extern_crate_as_self" pub extern crate self as export_extern_crate_as_self; // Must be the same name as the crate already has </ins>
Change:
Found in : https://crater- Looking briefly into the code it's doing something pretty weird (e.g., transmutes ), but at the very least this diagnostic seems unfortunate.
searched nightlies: from nightly-2022-04-01 to nightly-2022-08-11 regressed nightly: nightly-2022-07-28 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.3</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsThis regressed in cc
Maybe "regressed" is better here, maybe it's a legitimate reason to fail. Haven't looked into it.
I'm going to look into this later, but it seems like a case of wf checks requiring const bounds.
Repro:
Just to be sure I understood: is the regression about code that should compile in the next Rust 1.64 or is that code now invalid code and the regression is just a bad diagnostic? thanks!
The code is valid. It should compile in the next Rust 1.64. Hope that helps.
WG-prioritization assigning priority (). label -I-prioritize +P-medium

Discussion:
) { let cause = traits::ObligationCause::new(span, self.body_id, ObligationCauseCode::WellFormed(loc)); <ins> // for a type to be WF, we do not need to check if const trait predicates satisfy. let param_env = self.param_env.without_const(); </ins> self.ocx.register_obligation(traits::Obligation::new( cause, <del> self.param_env, </del> <ins> param_env, </ins> ty::Binder::dummy(ty::PredicateKind::WellFormed(arg)).to_predicate(self.tcx()), )); }

assert_eq!(predicates.predicates.len(), predicates.spans.len()); let wf_obligations = iter::zip(&predicates.predicates, &predicates.spans).flat_map(|(&p, &sp)| { <del> traits::wf::predicate_obligations(infcx, wfcx.param_env, wfcx.body_id, p, sp) </del> <ins> traits::wf::predicate_obligations( infcx, wfcx.param_env.without_const(), wfcx.body_id, p, sp, ) </ins> }); let obligations: Vec<_> = wf_obligations.chain(default_obligations).collect();

<ins> // revisions: nn ny yn yy // check-pass #![feature(const_trait_impl, associated_type_defaults, const_mut_refs)] #[cfg_attr(any(yn, yy), const_trait)] pub trait Index { type Output; } #[cfg_attr(any(ny, yy), const_trait)] pub trait IndexMut where Self: Index { const C: <Self as Index>::Output; type Assoc = <Self as Index>::Output; fn foo(&mut self, x: <Self as Index>::Output) -> <Self as Index>::Output; } impl Index for () { type Output = (); } impl const IndexMut for <() as Index>::Output { const C: <Self as Index>::Output = (); type Assoc = <Self as Index>::Output; fn foo(&mut self, x: <Self as Index>::Output) -> <Self as Index>::Output where <Self as Index>::Output:, {} } const C: <() as Index>::Output = (); fn main() {} </ins>
Change:
<!-- 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: <!-- Please provide a link to --The current output is: The error is correct, but I think the diagnostic is wrong. The second recommendation to call is sound, but the first one () seems like bad advice. This reproduces on 1.61 (on my workstation), as well as 1.63 (stable channel in playground), 1.64 (beta channel in playground), and 1.65 (nightly channel in playground). <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Intresting.. This code also make wrong help, The current output is: Using is a bad advice.
claim

Discussion:
diag.span_suggestion( span, *msg, <del> format!("{}.as_ref()", snippet), </del> <ins> // HACK: fix issue# 100605, suggesting convert from &Option<T> to Option<&T>, remove the extra `&` format!("{}.as_ref()", snippet.trim_start_matches('&')), </ins> Applicability::MachineApplicable, ); }

<ins> fn takes_option(_arg: Option<&String>) {} fn main() { takes_option(&None); //~ ERROR 4:18: 4:23: mismatched types [E0308] let x = String::from("x"); let res = Some(x); takes_option(&res); //~ ERROR 8:18: 8:22: mismatched types [E0308] } </ins>

<ins> error[E0308]: mismatched types --> $DIR/issue-100605.rs:4:18 | LL |     takes_option(&None); |     ------------ ^^^^^ expected enum `Option`, found `&Option<_>` |     | |     arguments to this function are incorrect | = note:   expected enum `Option<&String>` found reference `&Option<_>` note: function defined here --> $DIR/issue-100605.rs:1:4 | LL | fn takes_option(_arg: Option<&String>) {} |    ^^^^^^^^^^^^ --------------------- help: you can convert from `&Option<T>` to `Option<&T>` using `.as_ref()` | LL |     takes_option(None.as_ref()); |                  ~~~~~~~~~~~~~ help: consider removing the borrow | LL -     takes_option(&None); LL +     takes_option(None); | error[E0308]: mismatched types --> $DIR/issue-100605.rs:8:18 | LL |     takes_option(&res); |     ------------ ^^^^ |     |            | |     |            expected enum `Option`, found `&Option<String>` |     |            help: you can convert from `&Option<T>` to `Option<&T>` using `.as_ref()`: `res.as_ref()` |     arguments to this function are incorrect | = note:   expected enum `Option<&String>` found reference `&Option<String>` note: function defined here --> $DIR/issue-100605.rs:1:4 | LL | fn takes_option(_arg: Option<&String>) {} |    ^^^^^^^^^^^^ --------------------- error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0308`. </ins>
Change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri 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!

Discussion:
<del> Subproject commit 50ef22af522f2545295090cc1ad3e4bd4aa8632c </del> <ins> Subproject commit b8f617897a66953b9026c02f7a8f93a2e9611f63 </ins>
Change:
If you try to compile the crate with , it fails with the following error: This seems to be a regression from to , and my best guess for the change that caused it is this pull request: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Filed to fix this. FYI, a short-term workaround is to enable the target feature (). claim
Possibly related: This is seen cross-compiling from Linux to Windows. Giant 1MB linker error message related to atomicload, only in release mode, for target x8664-pc-windows-gnu. Failing in rustc 1.67.1 stable. Currently asking for help comments; will file an issue in a day or two if nobody reports a known fix.
Since native atomic ops exist in x86_64, I don't believe this and are related to your problem. Given that rend3 has enabled , your problem may be related to

Discussion:
linker_flavor: LinkerFlavor::Ld, linker: Some("arm-none-eabi-ld".into()), asm_args: cvs!["-mthumb-interwork", "-march=armv4t", "-mlittle-endian",], <del> features: "+soft-float,+strict-align".into(), </del> <ins> // Force-enable 32-bit atomics, which allows the use of atomic load/store only. // The resulting atomics are ABI incompatible with atomics backed by libatomic. features: "+soft-float,+strict-align,+atomics-32".into(), </ins> main_needs_argc_argv: false, atomic_cas: false, has_thumb_interworking: true,

asm_args: cvs!["-mthumb-interwork", "-march=armv4t", "-mlittle-endian",], // minimum extra features, these cannot be disabled via -C <del> features: "+soft-float,+strict-align".into(), </del> <ins> // Also force-enable 32-bit atomics, which allows the use of atomic load/store only. // The resulting atomics are ABI incompatible with atomics backed by libatomic. features: "+soft-float,+strict-align,+atomics-32".into(), </ins> panic_strategy: PanicStrategy::Abort, relocation_model: RelocModel::Static,
Change:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --I tried this code: I expected to see this happen: Rustdoc compiles the documentation as for older toolchains (stable, < nightly-2022-08-10) or as it is happening for / Instead, this happened: Rustdoc reports an compiler error <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: nightly-2022-08-09 : : points to as merge that introduced this regression which is a roll-up PR. and are included there and seems to be rustdoc releated. Pinging and as authors of these PR's. <!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-nightly -regression-untriaged --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I think the bug is coming from cc EDIT: also, would be quite useful to have a minimum code that we can use as a regression test.
Reducing compiler errors coming from diesel is quite hard and takes a lot of time. Diesel is already part of the rust compiler tests-suite, although in an older version. So it might be easier to just update this version to a current diesel version.
This is due to my PR. claim
is not documented inside the compiler so it wouldn't be very helpful unfortunately. Also, I didn't ask you specifically, just thought it might be useful to say it, so don't worry if you don't have time for it. :wink: Thanks !
The corresponding test code is here: I think it did not catch this issue as it uses an older diesel version (and it does not enable the corresponding feature flag).
I minimized this: And fix PR incoming.
This apparently was not fixed.
I can confirm that this is fixed for . Thank you all for the fast fix :tada:

Discussion:
}); tcx.infer_ctxt().ignoring_regions().enter(|ref infcx| { <del> let mut fulfill_ctxt = <dyn TraitEngine<'_>>::new(tcx); fulfill_ctxt.register_predicate_obligations(infcx, predicates_for_trait); !fulfill_ctxt.select_all_or_error(infcx).is_empty() </del> <ins> for obligation in predicates_for_trait { // Ignore overflow error, to be conservative. if let Ok(result) = infcx.evaluate_obligation(&obligation) && !result.may_apply() { return true; } } false </ins> }) }

<ins> pub trait Bar<S> {} pub trait Qux<T> {} pub trait Foo<T, S> { fn bar() where T: Bar<S>, { } } pub struct Concrete; impl<S> Foo<(), S> for Concrete {} impl<T, S> Bar<S> for T where S: Qux<T> {} impl<T, S> Qux<T> for S where T: Bar<S> {} </ins>
Change:
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.

Discussion:
[[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", ]

[dependencies] # tidy-alphabetical-start bitflags = "2.4.1" <del> pulldown-cmark = { version = "0.9.3", default-features = false } </del> <ins> pulldown-cmark = { version = "0.9.6", default-features = false } </ins> rustc_arena = { path = "../rustc_arena" } rustc_ast = { path = "../rustc_ast" } rustc_ast_pretty = { path = "../rustc_ast_pretty" }

<ins> #![crate_name = "foo"] //! Reference to footnotes A[^1], B[^2] and C[^3]. //! //! [^1]: Footnote A. //! [^2]: Footnote B. //! [^3]: Footnote C. // @has 'foo/index.html' // @has - '//*[@class="docblock"]/*[@class="footnotes"]/ol/li[@id="fn1"]/p' 'Footnote A' // @has - '//li[@id="fn1"]/p/a/@href' '#fnref1' // @has - '//*[@class="docblock"]/*[@class="footnotes"]/ol/li[@id="fn2"]/p' 'Footnote B' // @has - '//li[@id="fn2"]/p/a/@href' '#fnref2' // @has - '//*[@class="docblock"]/*[@class="footnotes"]/ol/li[@id="fn3"]/p' 'Footnote C' // @has - '//li[@id="fn3"]/p/a/@href' '#fnref3' </ins>
Change:
The suggestion that rustc gives is incorrect and seems to not take into account what characters are in the format argument. I tried this code: I expected to see this happen: Instead, this happened: Using beta.2/nightly : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label -C-bug +A-diagnostics +T-compiler
claim

Discussion:
if let Some(positional_arg_to_replace) = position_sp_to_replace { let name = if is_formatting_arg { named_arg_name + "$" } else { named_arg_name }; <ins> let span_to_replace = if let Ok(positional_arg_content) = self.sess().source_map().span_to_snippet(positional_arg_to_replace) && positional_arg_content.starts_with(":") { positional_arg_to_replace.shrink_to_lo() } else { positional_arg_to_replace }; </ins> db.span_suggestion_verbose( <del> positional_arg_to_replace, </del> <ins> span_to_replace, </ins> "use the named argument by name to avoid ambiguity", name, Applicability::MaybeIncorrect,

<ins> // When build the suggesttion take in consideration the `:?` // https://github.com/rust-lang/rust/issues/100648 #![deny(warnings)] fn main () { println!("hello {:?}", world = "world"); //~^ ERROR named argument `world` is not used by name //~| HELP use the named argument by name to avoid ambiguity //~| SUGGESTION world } </ins>

<ins> error: named argument `world` is not used by name --> $DIR/sugg_with_positional_args_and_debug_fmt.rs:6:28 | LL |     println!("hello {:?}", world = "world"); |                     ----   ^^^^^ this named argument is referred to by position in formatting string |                     | |                     this formatting argument uses named argument `world` by position | note: the lint level is defined here --> $DIR/sugg_with_positional_args_and_debug_fmt.rs:3:9 | LL | #![deny(warnings)] |         ^^^^^^^^ = note: `#[deny(named_arguments_used_positionally)]` implied by `#[deny(warnings)]` help: use the named argument by name to avoid ambiguity | LL |     println!("hello {world:?}", world = "world"); |                      +++++ error: aborting due to previous error </ins>
Change:
If you , you get a normal error like but if you try to at the same time: rust will panic which is a bit weird. Mayne that panic should be demoted to a regular error? <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
To reproduce: `
claim

Discussion:
//! The various pretty-printing routines. <ins> use crate::session_diagnostics::UnprettyDumpFail; </ins> use rustc_ast as ast; use rustc_ast_pretty::pprust; use rustc_errors::ErrorGuaranteed;

(src, src_name) } <del> fn write_or_print(out: &str, ofile: Option<&Path>) { </del> <ins> fn write_or_print(out: &str, ofile: Option<&Path>, sess: &Session) { </ins> match ofile { None => print!("{}", out), Some(p) => { if let Err(e) = std::fs::write(p, out) { <del> panic!("print-print failed to write {} due to {}", p.display(), e); </del> <ins> sess.emit_fatal(UnprettyDumpFail { path: p.display().to_string(), err: e.to_string(), }); </ins> } } }

_ => unreachable!(), }; <del> write_or_print(&out, ofile); </del> <ins> write_or_print(&out, ofile, sess); </ins> } pub fn print_after_hir_lowering<'tcx>(

_ => unreachable!(), }; <del> write_or_print(&out, ofile); </del> <ins> write_or_print(&out, ofile, tcx.sess); </ins> } // In an ideal world, this would be a public function called by the driver after

_ => unreachable!(), }; <del> write_or_print(&out, ofile); </del> <ins> write_or_print(&out, ofile, tcx.sess); </ins> Ok(()) }

#[derive(SessionDiagnostic)] #[diag(driver::rlink_no_a_file)] pub(crate) struct RlinkNotAFile; <ins> #[derive(SessionDiagnostic)] #[diag(driver::unpretty_dump_fail)] pub(crate) struct UnprettyDumpFail { pub path: String, pub err: String, } </ins>

driver_rlink_rustc_version_mismatch = .rlink file was produced by rustc version `{$rustc_version}`, but the current version is `{$current_version}` driver_rlink_no_a_file = rlink must be a file <ins> driver_unpretty_dump_fail = pretty-print failed to write `{$path}` due to error `{$err}` </ins>

<ins> // normalize-stderr-test "error `.*`" -> "$$ERROR_MESSAGE" // compile-flags: -o/tmp/ -Zunpretty=ast-tree fn main() {} </ins>

<ins> error: pretty-print failed to write `/tmp/` due to $ERROR_MESSAGE error: aborting due to previous error </ins>
Change:
this compiles with because we now assume unnormalized types in the impl header to be well formed when computing implied bounds. We don't check that when using the impl so we should be able to transmute lifetimes with this, though I haven't tried that yet. Going to fix that myself once I am back home in 2 weeks. cc
assigning after a very long and deep discussion in https://rust-
(FYI I also nominated PR for discussion at T-compiler meeting, essentially because of this associated issue; I hadn't seen that this was tagged as P-critical at that time. I'm leaving it nominated for now, just to ensure doubly that we discuss the matter.)
this is an existing issue on stable if we prevent the projection from normalizing in the impl while normalizing it when using the impl: that's the same issue as , which has been only fixed for function signatures edit: that's

Discussion:
let hir_id = tcx.hir().local_def_id_to_hir_id(def_id); let cause = ObligationCause::misc(span, hir_id); for ty in assumed_wf_types { <del> implied_bounds.insert(ty); </del> <ins> // FIXME(@lcnr): rustc currently does not check wf for types // pre-normalization, meaning that implied bounds are sometimes // incorrect. See #100910 for more details. // // Not adding the unnormalized types here mostly fixes that, except // that there are projections which are still ambiguous in the item definition // but do normalize successfully when using the item, see #98543. // // Anyways, I will hopefully soon change implied bounds to make all of this // sound and then uncomment this line again. // implied_bounds.insert(ty); </ins> let normalized = self.normalize(cause.clone(), param_env, ty); implied_bounds.insert(normalized); }

<ins> struct Foo<T>(T); trait GoodBye { type Forget; } impl<T> GoodBye for T { type Forget = (); } trait NeedsWf<'a, 'b> { type Assoc; } impl<'a, 'b> NeedsWf<'a, 'b> for Foo<<&'a &'b () as GoodBye>::Forget> { type Assoc = &'a &'b (); //~^ ERROR in type `&'a &'b ()`, reference has a longer lifetime than the data it references } fn needs_wf<'a, 'b, T: NeedsWf<'a, 'b>>() {} fn foo<'a: 'a, 'b: 'b>(_: &'b String) { needs_wf::<'a, 'b, Foo<()>>(); } fn main() { let x = String::from("hello"); foo::<'static, '_>(&x); } </ins>

<ins> error[E0491]: in type `&'a &'b ()`, reference has a longer lifetime than the data it references --> $DIR/impl-header-unnormalized-types.rs:15:18 | LL |     type Assoc = &'a &'b (); |                  ^^^^^^^^^^ | note: the pointer is valid for the lifetime `'a` as defined here --> $DIR/impl-header-unnormalized-types.rs:14:6 | LL | impl<'a, 'b> NeedsWf<'a, 'b> for Foo<<&'a &'b () as GoodBye>::Forget> { |      ^^ note: but the referenced data is only valid for the lifetime `'b` as defined here --> $DIR/impl-header-unnormalized-types.rs:14:10 | LL | impl<'a, 'b> NeedsWf<'a, 'b> for Foo<<&'a &'b () as GoodBye>::Forget> { |          ^^ error: aborting due to previous error For more information about this error, try `rustc --explain E0491`. </ins>
Change:
<!-- 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. --<!-- 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
Reduced: `
Regression in
The assert was in I MENT (sorry, I should no do this on the phone... :roll_eyes: ) cc

Discussion:
let symbol = if value { kw::True } else { kw::False }; (token::Bool, symbol, None) } <del> LitKind::Err => unreachable!(), </del> <ins> // This only shows up in places like `-Zunpretty=hir` output, so we // don't bother to produce something useful. LitKind::Err => (token::Err, Symbol::intern("<bad-literal>"), None), </ins> }; token::Lit::new(kind, symbol, suffix)

<ins> // compile-flags: -Zunpretty=hir // check-fail // In #100948 this caused an ICE with -Zunpretty=hir. fn main() { 1u; //~^ ERROR invalid suffix `u` for number literal } </ins>

<ins> error: invalid suffix `u` for number literal --> $DIR/bad-literal.rs:6:5 | LL |     1u; |     ^^ invalid suffix `u` | = help: the suffix must be one of the numeric types (`u32`, `isize`, `f32`, etc.) error: aborting due to previous error </ins>

<ins> #[prelude_import] use ::std::prelude::rust_2015::*; #[macro_use] extern crate std; // compile-flags: -Zunpretty=hir // check-fail // In #100948 this caused an ICE with -Zunpretty=hir. fn main() { <bad-literal>; } </ins>