jiebi/CodeConvo huggingface dataset:
Change:
ar: HashMap<TargetSelection, PathBuf>, ranlib: HashMap<TargetSelection, PathBuf>, // Miscellaneous <ins> // allow bidirectional lookups: both name -> path and path -> name </ins> crates: HashMap<Interned<String>, Crate>, <ins> crate_paths: HashMap<PathBuf, Interned<String>>, </ins> is_sudo: bool, ci_env: CiEnv, delayed_failures: RefCell<Vec<String>>,

Discussion:
I tried this code: I expected to see this happen: bootstrap documents the whole compiler, like it does for . Instead, this happened: The problem is that is too naive and expects the name of each crate to match its file path on disk: It needs to map from the path to the name somehow. There's already a way to go from the name to the path: but I don't think there's a way to do the reverse. HEAD is . label +A-bootstrap
label: +A-bootstrap
label: +E-mentor +A-rustbuild
Change:
R: Debug + TypeFoldable<TyCtxt<'tcx>>, Canonical<'tcx, QueryResponse<'tcx, R>>: ArenaAllocatable<'tcx>, { <del> let (infcx, key, canonical_inference_vars) = self.build_with_canonical(DUMMY_SP, canonical_key); </del> <ins> let (infcx, key, canonical_inference_vars) = self .with_opaque_type_inference(DefiningAnchor::Bubble) .build_with_canonical(DUMMY_SP, canonical_key); </ins> let ocx = ObligationCtxt::new(&infcx); let value = operation(&ocx, key)?; ocx.make_canonicalized_query_response(canonical_inference_vars, value)

Discussion:
This used to compile and now ICEs: Compiles on Stable version: 1.70.0 Regressed in 1.71.0-beta.6 (2023-07-08 ) I guess it is , but this shouldn't be in beta? <details<summary<strongBacktrace</strong</summary<p</p</details
Bisection results: searched nightlies: from nightly-2023-05-20 to nightly-2023-07-14 regressed nightly: nightly-2023-06-25 searched commit range: regressed commit: ( -), cc <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.6</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Change:
use rustc_data_structures::captures::Captures; use rustc_arena::TypedArena; <ins> use rustc_data_structures::stack::ensure_sufficient_stack; </ins> use rustc_hir::def_id::DefId; use rustc_hir::HirId; use rustc_middle::ty::{self, Ty, TyCtxt};

Discussion:
The following macro generates a function with 4096 entries in the tuple. () It’s explicitly a stack overflow on stable and AFAIK segfaults can happen on stack overflow in sound rust code, so maybe it isn’t some memory unsafety. label I-crash, T-compiler
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
Digged a bit, this is indeed a stack overflow. Since rustc uses stacker, if we moved to a segemented stack instead of the native stack, std didn't know this is a stack overflow and so it appears as segfault instead. The root cause is that uses recursion.
Change:
] [[package]] <ins> name = "pretty_assertions" version = "1.2.1" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "c89f989ac94207d048d92db058e4f6ec7342b0971fc58d1271ca148b799b3563" dependencies = [ "ansi_term", "ctor", "diff", "output_vt100", ] [[package]] </ins> name = "pretty_env_logger" version = "0.4.0" source = "registry+https://github.com/rust-lang/crates.io-index"

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Tons of test suite failures when testing with mir-opt; probably because the dead stores that cause UB got removed.
claim
I'd like to land before we update the in-tree Miri.
Change:
<ins> error[E0308]: mismatched types --> $DIR/issue-51154.rs:2:30 | LL | fn foo<F: FnMut()>() { |        - this type parameter LL |     let _: Box<F> = Box::new(|| ()); |                              ^^^^^ expected type parameter `F`, found closure | = note: expected type parameter `F` found closure `[closure@$DIR/issue-51154.rs:2:30: 2:35]` = help: every closure has a distinct type and so could not always match the caller-chosen type of parameter `F` error: aborting due to previous error For more information about this error, try `rustc --explain E0308`. </ins>

Discussion:
Minimal example: The error is technically correct. I specified, that I want a box of F, but I create a closure. Because F is generic, it is caller-chosen and I create a new closure, which has a different type. Still, it took me quite some time to find out what was going on in the more complicated real code. I think that it would help to add a note here explaining, that each closure has a different type, and that the inner closure does not match the type F exactly. Maybe additionally a hint could be , stating to use instead (i.e. the traits F is bound to).
Current output: It doesn't handle the closure case in any special way, and it should.
I’m experiencing the same problem
Change:
} // Finally, wrap everything up in a nice tarball! <del> let mut cmd = Command::new("sh"); </del> <ins> let mut cmd = Command::new(SH_CMD); </ins> cmd.arg(sanitize_sh(&build.src.join("src/rust-installer/gen-installer.sh"))) .arg("--product-name=Rust") .arg("--rel-manifest-dir=rustlib")

Discussion:
The configure script begins with: This works on machines where bash implements its own version of sh. But fails on Solaris where sh and bash are separated programs. To fix, I changed that first line into: And after that it ran.
cf. .
If the problem here is that we are using bashisms in the configure script, I would rather fix that.
works for me today. Was this issue fixed? I remember some other issues...
works, but the installer has the same issue. For this reason, doesn't work on Solaris.
According to , as one example, gen- is using bashsims or other shell extensions: But in all honesty, I don't think it's worth it. I would encourage you to either rewrite the script in Python (such that it is compatible with Python 2.x and 3.x) or simply change the scripts to use instead. On Solaris, is the traditional bourne shell, not bash, and is not even POSIX compliant. This is for backwards-compatibility reasons, among others. The posix shell is .
Change:
<ins> // ignore-tidy-linelength #![crate_name = "foo"] //! This is the "start" of the 'document'! How'd you know that "it's" the start? //! //! # Header with "smart punct'" //! //! [link with "smart punct'" -- yessiree!][] //! //! [link with "smart punct'" -- yessiree!]: https://www.rust-lang.org //! //! # Code should not be smart-punct'd //! //! `this inline code -- it shouldn't have "smart punct"` //! //! ``` //! let x = "don't smart-punct me -- please!"; //! ``` //! //! ```text //! I say "don't smart-punct me -- please!" //! ``` // @has "foo/index.html" "//p" "This is the “start” of the ‘document’! How’d you know that “it’s” the start?" // @has "foo/index.html" "//h1" "Header with “smart punct’”" // @has "foo/index.html" '//a[@href="https://www.rust-lang.org"]' "link with “smart punct’” – yessiree!" // @has "foo/index.html" '//code' "this inline code -- it shouldn't have "smart punct"" // @has "foo/index.html" '//pre' "let x = "don't smart-punct me -- please!";" // @has "foo/index.html" '//pre' "I say "don't smart-punct me -- please!"" </ins>

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:
} // accept trailing commas // Parse options <del> if p.eat(&token::Ident(sym::options, false)) { </del> <ins> if p.eat_keyword(sym::options) { </ins> parse_options(&mut p, &mut args)?; allow_templates = false; continue;

Discussion:
The : pointed me to -- cc I see that there were regressions with during that review, but not exactly like what I'm seeing here. searched nightlies: from nightly-2020-09-28 to nightly-2020-10-04 regressed nightly: nightly-2020-09-30 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.2</summaryHost triple: x8664-unknown-linux-gnu Reproduce with: </details
It's probably relevant that the actual token is passed as an arch-conditional parameter here:
Yes, I've missed this case, sorry. Will fix soon.
Fixed in
Works for me, thanks!
Change:
<ins> // Copyright 2015 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. fn main() { match Some(1) { None @ _ => {} //~ ERROR declaration of `None` shadows an enum variant }; const C: u8 = 1; match 1 { C @ 2 => { //~ ERROR only irrefutable patterns allowed here println!("{}", C); } _ => {} }; } </ins>

Discussion:
This is accepted, but probably shouldn't be. (A normal declaration of a variable named None is rejected.)
Related testcase:
That second case is unrelated. (And really weird, I'm not even sure how that's happening!)
Change:
// a .span_bug or .bug call has already printed what // it wants to print. <del> if !info.payload().is::<rustc_errors::ExplicitBug>() { </del> <ins> if !info.payload().is::<rustc_errors::ExplicitBug>() && !info.payload().is::<rustc_errors::GoodPathBug>() { </ins> let mut d = rustc_errors::Diagnostic::new(rustc_errors::Level::Bug, "unexpected panic"); handler.emit_diagnostic(&mut d); }

Discussion:
With beta but nightly does not show backtraces: edits this is with prioritize
can you share your example code, as it doesn't seem that all ICEs are missing backtraces: on the same nightly and beta, and which has a backtrace on both. (if you have the time to do so and a master checkout, it'd be interesting to know whether ThinLTO could be involved like in ; bisection would also be worthwhile)
Hmm interesting, maybe its' something that only happens with :thinking: does not show a backtrace for me ! I also can't force it with or anything :(
This backtrace was removed on purpose in because it's useless. It just points at the place in the error machinery where delayed bugs get flushed, which is either just noise or misleading at worse.
This also affects explicit calls too -- these should be restored in . Regarding s backtraces being useless, see .
Change:
- name: x86_64-msvc-ext env: SCRIPT: python x.py --stage 2 test src/tools/cargotest src/tools/cargo && src/ci/docker/host-x86_64/x86_64-gnu-tools/checktools.sh x.py /tmp/toolstate/toolstates.json windows <ins> HOST_TARGET: x86_64-pc-windows-msvc </ins> RUST_CONFIGURE_ARGS: "--build=x86_64-pc-windows-msvc --enable-lld --save-toolstates=/tmp/toolstate/toolstates.json" DEPLOY_TOOLSTATES_JSON: toolstates-windows.json os: windows-2019-8core-32gb

Discussion:
We currently run Miri on tests a few select targets: However, that's not all tier 1 targets, so e.g. x8664-apple-darwin is not covered, and today's nightly contains a Miri where some APIs are broken on x8664-apple-darwin. It'd be great if we could run (some) Miri tests on all tier 1 targets. Note that Miri tests can be run on any host so this does not require running on more hosts. However we'd probably not want to test all targets on all hosts, so we need some way in to determine which host we are on, and spread the test jobs across the hosts. Also, depending on how tight our time budget is here, we might want to not run all tests -- just running the "pass" tests should generally be sufficient and can save a bunch of time. Cc -- in particular, (a) how can I check for the host in , and (b) how tight is our time budget for the "tools" builders?
Change:
// Just ignore error types. if a.references_error() || b.references_error() { <del> return success(vec![], b, vec![]); </del> <ins> return success(vec![], self.fcx.tcx.types.err, vec![]); </ins> } if a.is_never() {

Discussion:
Because of the method error, doesn't get a type (not even , AFAICT), and then it gets inferred to from another call in the function, which results in the unsized variable error.
cc
I'd expect a simple fix for this would be to actually set as 's type, so it can't be inferred to anything else, although that could make other errors less informative.
I just spent a lot of time looking at a error. The errors were hidden by a couple of screens of "doc comment not used by rustdoc" warnings. Because was unknown, the compiler assumed it implemented no traits at all, leading to misleading errors below and user confusion: "why isn't it when this other similar type similar is?", "how can I find out if a type is " and so on. I don't know if works like that, but in this case it might be better to assume that the type implements any trait it's required to.
That doesn't really work out, since the issue here is that inference gets a free pass instead of inferring which would at least signal anything. The fix seems simple, I really don't know why I haven't tried it yet
I'm not saying that the type should be inferred to something else from the code below (like you said it was happening in the issue description) -- that seems bad. But on the other hand the compiler should probably not report an error every place the type or variable is used.
I just reread, and: That's not relevant here - the problem is inference flows up into the variable, which is correct in other cases but in this case it infers the slice type which is unsized. The error is a mere side-effect.
The underlying cause is that we have two maps for →, a general one and one for locals. When type checking we write to the general one but the one for locals is only written to once, during initialization, and the we read from it. If we kept it up to date or read from the general map, the knock-down error wouldn't appear.
Change:
<ins> // Regression test for the ICE described in #87495. trait T { const CONST: (bool, dyn T); //~^ ERROR: the trait `T` cannot be made into an object [E0038] } fn main() {} </ins>

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. --<!-- 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
I used this to make some warnings/errors go away: Regressed in cc modify labels: regression-from-stable-to-nightly
Change:
ty: shortty(item), name: item.name.clone().unwrap(), path: fqp[..fqp.len() - 1].join("::"), <del> desc: shorter(item.doc_value()), </del> <ins> desc: Escape(&shorter(item.doc_value())).to_string(), </ins> parent: Some(did), search_type: get_index_search_type(&item, parent_basename), });

Discussion:
By escaped, I mean stuff like which renders fine in non-search listings (it looks like , instead of a literal iframe element on the page).
I thought we had an issue for this, but cannot find it.
Relevant to inline summary rendering:
Search result descriptions aren't markdown rendered and read/written unaltered from the search-index to the page. Should these descriptions be markdown rendered or html escaped ()?
Change:
// FIXME(oli-obk): once const generics can have generic types, this assertion // will likely get triggered. Move to `normalize_erasing_regions` at that point. <del> assert_eq!( tcx.erase_regions(a.ty), tcx.erase_regions(b.ty), "cannot relate constants of different types" ); </del> <ins> let a_ty = tcx.erase_regions(a.ty); let b_ty = tcx.erase_regions(b.ty); if a_ty != b_ty { relation.tcx().sess.delay_span_bug( DUMMY_SP, &format!("cannot relate constants of different types: {} != {}", a_ty, b_ty), ); } </ins> let eagerly_eval = |x: &'tcx ty::Const<'tcx>| x.eval(tcx, relation.param_env()); let a = eagerly_eval(a);

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. --<!-- 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
's parameter doesn't have to have an error type; it appears it can be any type (that doesn't trip the full feature gate error.) This version ICEs without any prior diagnostics: Neither version ICEs on beta or stable. (const generics aren't stable on 1.50, but after reporting an error for use of unstable features the compiler reports the same errors as beta and doesn't ICE.) label A-const-generics regression-from-stable-to-nightly
Bisected, this is a weird one:
I've attempted a second bisection using the snippet from the , I got a different result (not sure why, unsure if it helps) searched nightlies: from nightly-2021-02-15 to nightly-2021-03-18 regressed nightly: nightly-2021-03-18 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
I guess that was a lie I'm looking into this
Assigning and removing as in the prioritization working group. label: +P-high -I-prioritize
Change:
ty::Adt(def, _args) => def.sized_constraint(tcx).skip_binder().is_empty(), <del> ty::Alias(..) | ty::Param(_) | ty::Placeholder(..) => false, </del> <ins> ty::Alias(..) | ty::Param(_) | ty::Placeholder(..) | ty::Bound(..) => false, </ins> ty::Infer(ty::TyVar(_)) => false, <del> ty::Bound(..) | ty::Infer(ty::FreshTy(_) | ty::FreshIntTy(_) | ty::FreshFloatTy(_)) => { </del> <ins> ty::Infer(ty::FreshTy(_) | ty::FreshIntTy(_) | ty::FreshFloatTy(_)) => { </ins> bug!("`is_trivially_sized` applied to unexpected type: {:?}", self) } }

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. --<!-- 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
Regression in nightly-2023-02-18 commit[0] 2023-02-16: Auto merge of - matthiaskrgr:rollup-kpzfc6j, r=matthiaskrgr commit[1] 2023-02-16: Auto merge of - Zoxc:arena-query-clean, r=cjgillot commit[2] 2023-02-17: Auto merge of - matthiaskrgr:rollup-bgadak1, r=matthiaskrgr commit[3] 2023-02-17: Auto merge of - kylematsuda:type-of, r=BoxyUwU commit[4] 2023-02-17: Auto merge of - Zoxc:query-ctxtx-byval, r=cjgillot commit[5] 2023-02-17: Auto merge of - BoxyUwU:addconstarghastype_predicate, r=compiler-errors commit[6] 2023-02-17: Auto merge of - matthiaskrgr:rollup-5k2j7cx, r=matthiaskrgr commit[7] 2023-02-17: Auto merge of - WaffleLapkin:de-arena-allocates-you-OwO, r=Nilstrieb
It's just the non-lifetime binders pr:
Change:
<ins> error[E0369]: binary operation `==` cannot be applied to type `A` --> $DIR/issue-62375.rs:7:7 | LL |     a == A::Value; |     - ^^ -------- fn(()) -> A {A::Value} |     | |     A | = note: an implementation of `std::cmp::PartialEq` might be missing for `A` error: aborting due to previous error For more information about this error, try `rustc --explain E0369`. </ins>

Discussion:
Hello, I found a bug while developing a project who produce an internal error. I create this code to reproduce the error: I got this error: ! If you do the same using an Option, for example: But if you do this: You got another internal compiler error: ! And to know: There is a correct way to do this without a match? I try this, but it wasn't accepted: Thank you
Does not panic on nightly-2019-06-17 (playground nightly). Must have been fixed. E-needstest?
you should update your rust :)
Hello, Ok with an update it's fixed: ! Thank you :) But, there is a way to have auto updates on Linux? There is a way to check the enum value type without checking the content wrapped? (with a if, not a match)
You can use the like so: (Or you can say , which I think is better style, but there are scenarios where one must resort to the method.)
For the record: has been fixed in
Ok thank you ! I forgot the "let" before the Some(), I think it's the reason why it's doesn't works.
Change:
&fld.cx.ecfg.features.unwrap()); } <del> if path.segments.len() > 1 { </del> <ins> if path.segments.len() > 1 || path.global || !path.segments[0].parameters.is_empty() { </ins> fld.cx.span_err(path.span, "expected macro name without module separators"); return None; }

Discussion:
is valid syntax and compiles to a regular vector. This is because macros use s, not s as their names. Multi-segment paths are disallowed, but the path can have type parameters. We can move macros to s, however this would not be backwards compatible since anyone using would get a syntax error (even though the original syntax is meaningless). It's still a bug, so perhaps we can get away with this breaking change. Thoughts? cc
I'd say fix it and do a crater run.
Sounds like a plan to me
Ping?
I don't think anyone worked on it. In case someone wants to work on it, the two relevant points are and . It should be possible to error if the path is absolute, has more than one component, or any lifetime/type parameters. We can then do a crater run to see if these are used in the wild for some reason.
cc
I fixed this in .