jiebi/CodeConvo huggingface dataset:
Change:
You can create an empty io-reader with , which returns an . That doesn't implement the trait. However, I don't see any reason why it shouldn't.
I don't understand how a reader which is always at EOF should be seekable. Can you please explain more about it?
You can think of a reader which is always at EOF as a reader which is always at position 0 with a stream end of position 0. I don't think there is any disadvantage of having implemented for . It allows it to be passed to more generic code.
Did you hit a case where you actually wanted to do this?
In is discussing ways to implement a 307/308 HTTP redirect. Those two codes (in contrast to 301/302/303) require the payload to be sent after the redirect. However, parts of the payload may already have been sent to the server, before the server responds with the redirect. With a generic API taking an as Payload, it's not possible to seek back to the beginning. Thus, one suggestion is to use instead. To allow an empty body (e.g. for a GET request), it would be nice to keep using . While will probably decide to follow a different way for those redirects, I still think this pattern makes sense to support.

Discussion:
mod tests; use crate::fmt; <del> use crate::io::{self, BufRead, Initializer, IoSlice, IoSliceMut, Read, Write}; </del> <ins> use crate::io::{self, BufRead, Initializer, IoSlice, IoSliceMut, Read, Seek, SeekFrom, Write}; </ins> /// A reader which is always at EOF. ///

fn consume(&mut self, _n: usize) {} } <ins> #[stable(feature = "empty_seek", since = "1.51.0")] impl Seek for Empty { fn seek(&mut self, _pos: SeekFrom) -> io::Result<u64> { Ok(0) } fn stream_len(&mut self) -> io::Result<u64> { Ok(0) } fn stream_position(&mut self) -> io::Result<u64> { Ok(0) } } </ins> #[stable(feature = "std_debug", since = "1.16.0")] impl fmt::Debug for Empty { fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {

use crate::io::prelude::*; <del> use crate::io::{copy, empty, repeat, sink, Empty, Repeat, Sink}; </del> <ins> use crate::io::{copy, empty, repeat, sink, Empty, Repeat, SeekFrom, Sink}; </ins> #[test] fn copy_copies() {

} #[test] <ins> fn empty_seeks() { let mut e = empty(); assert!(matches!(e.seek(SeekFrom::Start(0)), Ok(0))); assert!(matches!(e.seek(SeekFrom::Start(1)), Ok(0))); assert!(matches!(e.seek(SeekFrom::Start(u64::MAX)), Ok(0))); assert!(matches!(e.seek(SeekFrom::End(i64::MIN)), Ok(0))); assert!(matches!(e.seek(SeekFrom::End(-1)), Ok(0))); assert!(matches!(e.seek(SeekFrom::End(0)), Ok(0))); assert!(matches!(e.seek(SeekFrom::End(1)), Ok(0))); assert!(matches!(e.seek(SeekFrom::End(i64::MAX)), Ok(0))); assert!(matches!(e.seek(SeekFrom::Current(i64::MIN)), Ok(0))); assert!(matches!(e.seek(SeekFrom::Current(-1)), Ok(0))); assert!(matches!(e.seek(SeekFrom::Current(0)), Ok(0))); assert!(matches!(e.seek(SeekFrom::Current(1)), Ok(0))); assert!(matches!(e.seek(SeekFrom::Current(i64::MAX)), Ok(0))); } #[test] </ins> fn repeat_repeats() { let mut r = repeat(4); let mut b = [0; 1024];
Change:
I recently to in my local repository. In particular, this enables: When running the full test suite with I get three errors similar to this: Maybe the packaging of LLVM downloaded from CI needs to be fixed to include ?
Cc since you're the one who implemented this :)
Yes, that seems right. I did not know we relied on the LLVM tooling -- probably there's a few more tools we need too, will need to check. I imagine it's mostly a matter of just adding them to this section: , they should already be built. I would be happy to take a PR for this.
I can make a patch adding a couple lines for like the ones there for , but can I test it without landing it and waiting for the next Nightly? (I assume testing locally involves compiling LLVM, so I might wait to do that until I have access again to a many-cores desktop rather than just my laptop.)
Hm, sort of. So you will need to post a PR, but then bors try will generate sufficient artifacts to test. You will want to replace with the sha of the try build that bors posts.
might also be necessary but I'm not sure.
I’ll find out! I’ve already started a try build with just : I can temporarily hard-code in for the purpose of testing, but for everyone else the logic is still picking the last commit that touched the submodule, which after lands will still be some commit that does not include Would it make sense to have a "timestamp-ish" file, and pick the last commit that touched either the submodule or that file? That would only be useful until the next LLVM update, though. (Unless we need to tweak thepackaging of the component again.)

Discussion:
llvm_sha = subprocess.check_output([ "git", "log", "--author=bors", "--format=%H", "-n1", "-m", "--first-parent", <del> "--", "src/llvm-project" </del> <ins> "--", "src/llvm-project", "src/bootstrap/download-ci-llvm-stamp", </ins> ]).decode(sys.getdefaultencoding()).strip() llvm_assertions = self.get_toml('assertions', 'llvm') == 'true' if self.program_out_of_date(self.llvm_stamp(), llvm_sha + str(llvm_assertions)):

let dst_bindir = image.join("bin"); t!(fs::create_dir_all(&dst_bindir)); <del> let exe = builder.llvm_out(target).join("bin").join(exe("llvm-config", target)); builder.install(&exe, &dst_bindir, 0o755); </del> <ins> let src_bindir = builder.llvm_out(target).join("bin"); let install_bin = |name| builder.install(&src_bindir.join(exe(name, target)), &dst_bindir, 0o755); install_bin("llvm-config"); install_bin("llvm-ar"); install_bin("llvm-objdump"); install_bin("llvm-profdata"); install_bin("llvm-bcanalyzer"); install_bin("llvm-cov"); </ins> builder.install(&builder.llvm_filecheck(target), &dst_bindir, 0o755); // Copy the include directory as well; needed mostly to build

<ins> Change this file to make users of the `download-ci-llvm` configuration download a new version of LLVM from CI, even if the LLVM submodule hasn’t changed. Last change is for: https://github.com/rust-lang/rust/pull/78131 </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. --From <!-- 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. --It fails at version: It worked before at version: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Sorry there's no code, but I've narrowed it to somewhere between (working) and (broken).
Likely cause: cc
MCVE: The ICE occurs (inside async blocks or functions) if you're using a match guard and binding the same variable name in both sides of an "or" in a match pattern.
finds a regression in which does correspond to
Assigning .
This ICE is caused here: According to the docs: As we're using a set and a vec in parallel, the ID is pushed twice but stored "only once". Then, we remove it once, and it still exists in the vec but not in the set:

Discussion:
let mut scope_var_ids = self.guard_bindings.pop().expect("should have pushed at least one earlier"); for var_id in scope_var_ids.drain(..) { <del> assert!( self.guard_bindings_set.remove(&var_id), "variable should be placed in scope earlier" ); </del> <ins> self.guard_bindings_set.remove(&var_id); </ins> } } self.visit_expr(body);

<ins> // Regression test for issue #78115: "ICE: variable should be placed in scope earlier" // check-pass // edition:2018 #[allow(dead_code)] struct Foo { a: () } async fn _bar() { let foo = Foo { a: () }; match foo { Foo { a: _a } | Foo { a: _a } if true => {} _ => {} } } fn main() {} </ins>
Change:
This should compile without warnings (): Yet it warns: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Note that this only occurs in const patterns. This produces no warnings (): Output:
Cc – this only occurs with inline const expressions; no warning is triggered with const items.
claim

Discussion:
use rustc_middle::ty::{self, DefIdTree, TyCtxt}; use rustc_session::lint; use rustc_span::symbol::{sym, Symbol}; <ins> use std::mem; </ins> // Any local node that may call something in its body block should be // explored. For example, if it's a live Node::Item that is a

} fn visit_anon_const(&mut self, c: &'tcx hir::AnonConst) { <ins> // When inline const blocks are used in pattern position, paths // referenced by it should be considered as used. let in_pat = mem::replace(&mut self.in_pat, false); </ins> self.live_symbols.insert(self.tcx.hir().local_def_id(c.hir_id)); intravisit::walk_anon_const(self, c); <ins> self.in_pat = in_pat; </ins> } }

<ins> // check-pass #![feature(inline_const)] #![allow(incomplete_features)] #![deny(dead_code)] const fn one() -> i32 { 1 } const fn two() -> i32 { 2 } const fn three() -> i32 { 3 } fn inline_const() { // rust-lang/rust#78171: dead_code lint triggers even though function is used in const pattern match 1 { const { one() } => {} _ => {} } } fn inline_const_range() { match 1 { 1 ..= const { two() } => {} _ => {} } } struct S<const C: i32>; fn const_generic_arg() { match S::<3> { S::<{three()}> => {} } } fn main() { inline_const(); inline_const_range(); const_generic_arg(); } </ins>
Change:
The control characters seem to cause strange artifacts so colors are disabled.
I don't think is correct, for reasons I left on the commit.
We could just hunt down all the tests that log to error or print to stdout and make them log to debug instead, then call it a day. Seeing the pretty colors is super nice. Probably should still be reverted though, unless there's something about it I'm missing.
Sorry. I'll revert the commits.
Added far-future milestone
Bug triage. Far-future still seems right.
Triage bump. There's been no change.
Triage bump. Still relevant.
I believe the test runner captures stdio now. It should be safe to print colors carefully.

Discussion:
fn use_color(opts: &TestOpts) -> bool { match opts.color { <del> AutoColor => get_concurrency() == 1 && stdout_isatty(), </del> <ins> AutoColor => !opts.nocapture && stdout_isatty(), </ins> AlwaysColor => true, NeverColor => false, }
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</detailsI think I'm an ICE magnet; this is my fourth one.
I'd like to note that it only ICEs with the wrong return type. The following does not ICE

Discussion:
ty::Adt(def, _) => format!("{} `{}`", def.descr(), tcx.def_path_str(def.did)).into(), ty::Foreign(def_id) => format!("extern type `{}`", tcx.def_path_str(def_id)).into(), ty::Array(t, n) => { <ins> if t.is_simple_ty() { return format!("array `{}`", self).into(); } </ins> let n = tcx.lift(n).unwrap(); <del> match n.try_eval_usize(tcx, ty::ParamEnv::empty()) { _ if t.is_simple_ty() => format!("array `{}`", self).into(), Some(n) => format!("array of {} element{}", n, pluralize!(n)).into(), None => "array".into(), </del> <ins> if let ty::ConstKind::Value(v) = n.val { if let Some(n) = v.try_to_machine_usize(tcx) { return format!("array of {} element{}", n, pluralize!(n)).into(); } </ins> } <ins> "array".into() </ins> } ty::Slice(ty) if ty.is_simple_ty() => format!("slice `{}`", self).into(), ty::Slice(_) => "slice".into(),

tcx: TyCtxt<'tcx>, key: ty::ParamEnvAnd<'tcx, GlobalId<'tcx>>, ) -> ::rustc_middle::mir::interpret::EvalToConstValueResult<'tcx> { <del> // see comment in const_eval_raw_provider for what we're doing here </del> <ins> // see comment in eval_to_allocation_raw_provider for what we're doing here </ins> if key.param_env.reveal() == Reveal::All { let mut key = key; key.param_env = key.param_env.with_user_facing();

<ins> #![feature(const_generics, const_evaluatable_checked)] #![allow(incomplete_features)] // This test is a minimized reproduction for #79518 where // during error handling for the type mismatch we would try // to evaluate std::mem::size_of::<Self::Assoc> causing an ICE trait Foo { type Assoc: PartialEq; const AssocInstance: Self::Assoc; fn foo() where [(); std::mem::size_of::<Self::Assoc>()]: , { Self::AssocInstance == [(); std::mem::size_of::<Self::Assoc>()]; //~^ Error: mismatched types } } fn main() {} </ins>

<ins> error[E0308]: mismatched types --> $DIR/issue-79518-default_trait_method_normalization.rs:16:32 | LL |         Self::AssocInstance == [(); std::mem::size_of::<Self::Assoc>()]; |                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected associated type, found array `[(); _]` | = note: expected associated type `<Self as Foo>::Assoc` found array `[(); _]` = help: consider constraining the associated type `<Self as Foo>::Assoc` to `[(); _]` or calling a method that returns `<Self as Foo>::Assoc` = note: for more information, visit https://doc.rust-lang.org/book/ch19-03-advanced-traits.html error: aborting due to previous error For more information about this error, try `rustc --explain E0308`. </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. --: This bug also exists at . <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Output on 1.46: Changing the closure argument type to compiles successfully on both verions. modify labels: +A-diagnostics +A-lifetimes +regression-from-stable-to-stable
With instead of it compiles successfully too. <details<summaryCode</summary</details
We probably have to check for closures in here.
Assigning as and removing I-prioritize.

Discussion:
) if **sub_r == RegionKind::ReStatic => { // This is for an implicit `'static` requirement coming from `impl dyn Trait {}`. if let ObligationCauseCode::UnifyReceiver(ctxt) = &cause.code { <ins> // This may have a closure and it would cause ICE // through `find_param_with_region` (#78262). let anon_reg_sup = tcx.is_suitable_region(sup_r)?; let fn_returns = tcx.return_type_impl_or_dyn_traits(anon_reg_sup.def_id); if fn_returns.is_empty() { return None; } </ins> let param = self.find_param_with_region(sup_r, sub_r)?; let lifetime = if sup_r.has_name() { format!("lifetime `{}`", sup_r)

<ins> error[E0308]: mismatched types --> $DIR/issue-78262.rs:12:28 | LL |     let f = |x: &dyn TT| x.func(); |                            ^^^^ lifetime mismatch | = note: expected reference `&(dyn TT + 'static)` found reference `&dyn TT` note: the anonymous lifetime #1 defined on the body at 12:13... --> $DIR/issue-78262.rs:12:13 | LL |     let f = |x: &dyn TT| x.func(); |             ^^^^^^^^^^^^^^^^^^^^^ = note: ...does not necessarily outlive the static lifetime error: aborting due to previous error For more information about this error, try `rustc --explain E0308`. </ins>

<ins> error[E0521]: borrowed data escapes outside of closure --> $DIR/issue-78262.rs:12:26 | LL |     let f = |x: &dyn TT| x.func(); |              -           ^^^^^^^^ `x` escapes the closure body here |              | |              `x` is a reference that is only valid in the closure body error: aborting due to previous error </ins>

<ins> // revisions: nll default // ignore-compare-mode-nll //[nll]compile-flags: -Z borrowck=mir trait TT {} impl dyn TT { fn func(&self) {} } fn main() { let f = |x: &dyn TT| x.func(); //[default]~ ERROR: mismatched types //[nll]~^ ERROR: borrowed data escapes outside of closure } </ins>
Change:
Repro: Clear local-storage for Set system theme to light Visit change theme to Visit note that the theme has been set to following the system Visit see that the theme changes back to because the stored theme was never updated Visit then change the system theme to dark, updating the displayed theme to , and then change the system theme back to light, updating the displayed theme to Visit see that the theme is now because the stored theme was updated This affects the plan we have for to follow rustdoc's theme setting, , I assumed that rustdoc would update the stored theme whenever it changes so we could synchronize off that. Missing the initial setting based on the fact that is the "default" theme loaded before the JS runs seems like a bug. cc
Error: Label rustdoc-ui can only be set by Rust team members Please let know if you're having trouble with this bot.
I'll implement this

Discussion:
var fullNewTheme = newTheme + resourcesSuffix + ".css"; var newHref = mainStyleElem.href.replace(fullBasicCss, fullNewTheme); <ins> // If this new value comes from a system setting or from the previously // saved theme, no need to save it. if (saveTheme === true) { updateLocalStorage("rustdoc-theme", newTheme); } </ins> if (styleElem.href === newHref) { return; }

}); if (found === true) { styleElem.href = newHref; <del> // If this new value comes from a system setting or from the previously // saved theme, no need to save it. if (saveTheme === true) { updateLocalStorage("rustdoc-theme", newTheme); } </del> } }
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</detailsNOTE: The bug is found by our work-in-progress compiler testing tool Kira, and the test program is reduced/minimized by
Seems to have regressed in Rust 1.33 based on testing in Godbolt.
With only the errors relevant to the ICE:
I'll fix this.
Fixed in

Discussion:
use rustc_hir::def::{self, DefKind, NonMacroAttrKind}; use rustc_hir::def_id; use rustc_middle::middle::stability; <del> use rustc_middle::{span_bug, ty}; </del> <ins> use rustc_middle::ty; </ins> use rustc_session::lint::builtin::UNUSED_MACROS; use rustc_session::Session; use rustc_span::edition::Edition;

initial_res: Option<Res>, res: Res| { if let Some(initial_res) = initial_res { <del> if res != initial_res && res != Res::Err && this.ambiguity_errors.is_empty() { </del> <ins> if res != initial_res { </ins> // Make sure compilation does not succeed if preferred macro resolution // has changed after the macro had been expanded. In theory all such <del> // situations should be reported as ambiguity errors, so this is a bug. span_bug!(span, "inconsistent resolution for a macro"); </del> <ins> // situations should be reported as errors, so this is a bug. this.session.delay_span_bug(span, "inconsistent resolution for a macro"); </ins> } } else { // It's possible that the macro was unresolved (indeterminate) and silently

<ins> macro_rules! define_other_core { ( ) => { extern crate std as core; //~^ ERROR macro-expanded `extern crate` items cannot shadow names passed with `--extern` }; } fn main() { core::panic!(); } define_other_core!(); </ins>

<ins> error: macro-expanded `extern crate` items cannot shadow names passed with `--extern` --> $DIR/issue-78325-inconsistent-resolution.rs:3:9 | LL |         extern crate std as core; |         ^^^^^^^^^^^^^^^^^^^^^^^^^ ... LL | define_other_core!(); | --------------------- in this macro invocation | = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info) error: aborting due to previous error </ins>
Change:
When debugging a large Miri trace, I like to put the trace into a file that I can analyze and search through in an editor. Unfortunately, since the recent logging changes, that leads to a lot of garbage in the file: Looks like the color escape sequences are printed even when redirecting to a file. This makes working with the logfile much harder than it was before. Is there a way to fix that? Cc
This is the fault of I should be checking for whether the terminal supports colors before activating colors
A workaround until then is to use
How can I run miri from the rust repo? (i.e. built using )
You can run the test suite with , but that's not what you were asking... that's not supported yet unfortunately:
Until then, . Some of the commands might need adjusting though as changed.
Ah, thanks! I forgot about that part of the docs :)
Hmm, I'm getting this error: I'm using the latest master rustc and the latest miri. Is miri broken right now? EDIT: Oh, I think I need .
Yeah looks like you are using the wrong stage or so. The docs are from back when stage 2 was the default...
I'm afraid the problem was not solved by that PR. When I run Miri like this locally I still get all the ANSI codes in that logfile, which makes the file very hard to work with.
Looks like the code tests , but logging goes to stderr so this is the wrong test.
Hmm, I guess I didn't notice any issues because I always redirect stderr to stdout and then view that.
Working on a fix.
Yeah, for now using to redirect both to the logfile is an okay work-around.
FYI you can view the original color with , which prints them directly to the terminal. That doesn't work in an editor, though.

Discussion:
Ok(s) if s.is_empty() => return, Ok(_) => {} } <ins> let color_logs = match std::env::var(String::from(env) + "_COLOR") { Ok(value) => match value.as_ref() { "always" => true, "never" => false, "auto" => stdout_isatty(), _ => early_error( ErrorOutputType::default(), &format!( "invalid log color value '{}': expected one of always, never, or auto", value ), ), }, Err(std::env::VarError::NotPresent) => stdout_isatty(), Err(std::env::VarError::NotUnicode(_value)) => early_error( ErrorOutputType::default(), "non-Unicode log color value: expected one of always, never, or auto", ), }; </ins> let filter = tracing_subscriber::EnvFilter::from_env(env); let layer = tracing_tree::HierarchicalLayer::default() .with_indent_lines(true) <del> .with_ansi(true) </del> <ins> .with_ansi(color_logs) </ins> .with_targets(true) .with_thread_ids(true) .with_thread_names(true)

arg.into_string().unwrap_or_else(|arg| { early_error( ErrorOutputType::default(), <del> &format!("Argument {} is not valid Unicode: {:?}", i, arg), </del> <ins> &format!("argument {} is not valid Unicode: {:?}", i, arg), </ins> ) }) })