jiebi/CodeConvo huggingface dataset:
Change:
), ), }, <del> Err(std::env::VarError::NotPresent) => stdout_isatty(), </del> <ins> Err(std::env::VarError::NotPresent) => stderr_isatty(), </ins> Err(std::env::VarError::NotUnicode(_value)) => early_error( ErrorOutputType::default(), "non-Unicode log color value: expected one of always, never, or auto",

Discussion:
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.
Change:
fn main() { assert_eq!(2, std::mem::size_of_val(&base())); <del> assert_eq!(8, std::mem::size_of_val(&await1_level1())); assert_eq!(12, std::mem::size_of_val(&await2_level1())); assert_eq!(12, std::mem::size_of_val(&await3_level1())); assert_eq!(24, std::mem::size_of_val(&await3_level2())); assert_eq!(36, std::mem::size_of_val(&await3_level3())); assert_eq!(48, std::mem::size_of_val(&await3_level4())); assert_eq!(60, std::mem::size_of_val(&await3_level5())); </del> <ins> assert_eq!(3, std::mem::size_of_val(&await1_level1())); assert_eq!(4, std::mem::size_of_val(&await2_level1())); assert_eq!(5, std::mem::size_of_val(&await3_level1())); assert_eq!(8, std::mem::size_of_val(&await3_level2())); assert_eq!(11, std::mem::size_of_val(&await3_level3())); assert_eq!(14, std::mem::size_of_val(&await3_level4())); assert_eq!(17, std::mem::size_of_val(&await3_level5())); </ins> assert_eq!(1,   wait(base())); assert_eq!(1,   wait(await1_level1()));

Discussion:
Currently they use a hardcoded discriminant, which is quite a lot of room considering that generators don't typically have billions of states. They should be able to use the smallest unsigned integer type that fits all states instead (so in the vast majority of cases).
The discriminant is also never marked with a valid range, meaning that it never provides any niches that could be used to store other values. Not sure if doing that has any drawbacks, but it seems like a somewhat easy size optimization on first glance.
Fixing this was way easier than I expected, but I'd appreciate help with benchmarking the runtime impact of the fix in . So if anyone knows any async/await benchmarks that are not I/O heavy (so that they mostly test CPU overhead of async/await), I'd be happy to run them.
Change:
use super::potentially_plural_count; use crate::errors::LifetimesOrBoundsMismatchOnTrait; use hir::def_id::{DefId, LocalDefId}; <del> use rustc_data_structures::fx::{FxHashMap, FxIndexSet}; </del> <ins> use rustc_data_structures::fx::{FxHashMap, FxHashSet, FxIndexSet}; </ins> use rustc_errors::{ pluralize, struct_span_err, Applicability, DiagnosticId, ErrorGuaranteed, MultiSpan, };

Discussion:
The lint is triggered by the following code (from , cc : In the environment , the type surprisingly requires for well-formedness (see ), but this constraint is not used in implied bounds, so I believe it can't be exploited for unsoundness. The lint was upgraded to deny-by-default in the current beta (1.68.0-beta.5 2023-02-15 ). So this counts as regression? cc label C-bug T-types T-compiler regression-from-stable-to-beta
:facepalm: I think this is due to us preferring param-env candidates for .
So the issue here is that requires . We try to prove that in the hybrid param-env of the impl's WC + trait method's WC, being after substituting . Due to some frustrating precedence rules around candidate assembly in the trait solver, we try to match against the param-env candidate and get . We also assemble a built-in sized bound, but always prefer the param-env candidate over that. That requires us to prove , which is not known to be true in the hybrid param-env, triggering the lint.
I wonder if we could get away with not checking , but just the implied lifetime bounds or something :thinking:
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Been thinking about this a little bit. One thought I had was to check that the impl method is WF given only the trait method, but I think that would break this example: I wonder if we could get away with not checking WF(return-type), but just the implied lifetime bounds or something This is annoying difficult, because it's not straightforward to get "just the implied lifetime bounds" of a type. I'm playing around with using and filtering outlives bounds, but that can generate more predicates (which, I thought we had somewhere a function that recurses though those). We'll see if this works...
Change:
return None; } self.head = wrap_index(self.head - 1, self.cap); <del> unsafe { Some(&mut *self.ptr.offset(self.head as int)) } </del> <ins> unsafe { Some(&mut *self.ptr.offset(self.head as int)) } </ins> } } impl<'a, T> ExactSize<&'a mut T> for MutItems<'a, T> {} <ins> // A by-value RingBuf iterator pub struct MoveItems<T> { inner: RingBuf<T>, } impl<T> Iterator<T> for MoveItems<T> { #[inline] fn next(&mut self) -> Option<T> { self.inner.pop_front() } #[inline] fn size_hint(&self) -> (uint, Option<uint>) { let len = self.inner.len(); (len, Some(len)) } } impl<T> DoubleEndedIterator<T> for MoveItems<T> { #[inline] fn next_back(&mut self) -> Option<T> { self.inner.pop_back() } } impl<T> ExactSize<T> for MoveItems<T> {} </ins> impl<A: PartialEq> PartialEq for RingBuf<A> { fn eq(&self, other: &RingBuf<A>) -> bool { self.len() == other.len() &&

Discussion:
There's currently no method on . This might have been missed during collections reform, or was never implemented.
Change:
let module = self.new_module(parent_link, Some(def), true, is_public); self.try_define(new_parent, name, TypeNS, (module, DUMMY_SP)); } <del> Def::AssociatedTy(..) => { </del> <ins> Def::TyAlias(..) | Def::AssociatedTy(..) => { </ins> debug!("(building reduced graph for external crate) building type {}", final_ident); self.try_define(new_parent, name, TypeNS, (def, DUMMY_SP, modifiers));

Discussion:
Code that compiles fine with rustc is causing an internal compiler error: unexpected panic with rustdoc. I tried this code (): The second line is essentially a typo, which can happen if used to be an Enum for instance. Again, the following works fine (although I'm not sure why, can you even add anything to the namespace?): However, if I run: I get the error: This actually happened on a version of a package already pushed to (hdf5-sys 0.3.0), so anything that depends on the erroneous version and runs will see this error. Run on . Backtrace:
This is easy to fix in rustdoc, but should this even compile?
Whoa kinda crazy... cc (resolve weridness, longstanding though!)
Change:
} pub type LPBY_HANDLE_FILE_INFORMATION = *mut BY_HANDLE_FILE_INFORMATION; <del> pub type LPCVOID = *const c_void; </del> pub const HANDLE_FLAG_INHERIT: DWORD = 0x00000001;

Discussion:
<!-- 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. --Building std library (-Zbuild-std) with nightly for uwp-windows-msvc targets has been failing with compile errors since around after 17/10/22 I expected to see this happen: Last successeful build on 16/10: Instead, this happened: Lastest failed build: It most recently worked on: rustc 1.66.0-nightly ( 2022-10-14) : <!-- Did the compiler crash? If so, please provide a backtrace. --<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details<!-- 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-{channel} -regression-untriaged --
Hey, is anyone looking into this because ALXR ci (uwp) builds are failing for over a week. Should this issue be posted in another repo?
This is the right repo, but it fell through the cracks for whatever reason. I can get to it this weekend.
Thank you :)
Oh, sorry I missed this! Since 10.0. console functions are available on UWP (see ). So I think the thing to do here is to simply stop making the function conditionally imported.
Change:
/// Iterates over the language items in the given crate. pub fn get_lang_items(&self) -> Vec<(DefId, usize)> { <del> self.root .lang_items .decode(self) .map(|(def_index, index)| (self.local_def_id(def_index), index)) .collect() </del> <ins> if self.proc_macros.is_some() { // Proc macro crates do not export any lang-items to the target. vec![] } else { self.root .lang_items .decode(self) .map(|(def_index, index)| (self.local_def_id(def_index), index)) .collect() } </ins> } /// Iterates over each child of the given item.

Discussion:
: : Steps to reproduce: This is failing when the crate attempts to import the crate (which is a crate). That is, if I modify 's file to only contain: rustc will ICE. <details<summaryBacktrace:</summary</details
I suspect this is a duplicate of , but I only count 2 #[procmacro] and 1 #[procmacro_attribute] in the repository.
The crate only has 1 and 1 . If I comment both of them out, the compiler still ICEs. The crate used to compile a couple weeks ago, so this was a fairly recent change.
To give some bounds on this: the crate compiles with . It fails with . I would bisect this with rustup to determine which nightly the issue started with, but .
Derp, I just remembered I could remove the component. Okay, doing that, I was able to bisect the nightlies: Last working version: First failing version:
I just did a git bisect, and it looks like commit (from PR ) is the source of the breakage. cc
visited for triage. Going to try to followup with . Assigning to self to keep myself honest about that claim.
also, P-high
Am looking at this.
Minified: // #[allow(unused)] // enum ProcMacroHack { // Input = (stringify!(ARGS), 0).1, // } // The problem is caused by containing "host" defids and being used in [trans]. I don't think that this field has any business containing host libraries when compiling a proc macro, but I'll ask for confirmation. [trans]:
visited for triage. Seems like PR handles this. Leaving as P-high
Change:
use std::env; <del> unsafe fn unsafe_fn() {} </del> <ins> #[deny(unsafe_op_in_unsafe_fn)] unsafe fn unsafe_fn() { env::set_var("FOO", "BAR"); //[e2024]~^ ERROR call to unsafe function `std::env::set_var` is unsafe env::remove_var("FOO"); //[e2024]~^ ERROR call to unsafe function `std::env::remove_var` is unsafe if false { unsafe_fn(); //~^ ERROR call to unsafe function `unsafe_fn` is unsafe } } </ins> fn safe_fn() {} #[deny(unused_unsafe)]

Discussion:
<!-- 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. --I tried this code: I expected to see this happen: will become in Rust 2024, the above code is using Rust 2021, so this should compile with no issue. Instead, this happened: <!-- 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<summaryBacktrace</summary<pNot needed </p</detailsI think the root cause is the lint , commenting it out would make the code compile: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Thanks for the report! That should not happen. We did a so I don't know how this is even possible... any ideas? This seems to be some bad interaction with .
claim Hmmm, weird that crater run didn't catch this.
I posted a PR fixing this: . Does crater maybe restrict lints?
I don't think it does. Is this code part of the "nix" crate?
If you are asking if this problem originates from the nix crate, then yes, see
I am wondering whether the nix crate as published on fails to build with latest nightly due to this issue.
I think yes, the has been in Nix for a long time. One should be able to reproduce the build failure on a UNIX platform other than: I am currently on Linux, will try reproducing it on my mac tomorrow.
Looks like crater tested nix 0.26.4 and that failed already before the removevar/setvar change (). That's due to the which makes the build fail even when there are just warnings. I guess we can add this to the list of why having deny(warnings) in the code is considered bad practice.
I created an issue and a PR against nix-rust.
Yeah, we can reproduce this on macOS
The reason this was missed is a combination of and
WG-prioritization assigning priority (). label -I-prioritize +P-high
Fix already exists, just needs a review: .
Change:
use rustc_errors::emitter::{Emitter, EmitterWriter}; use rustc_errors::Handler; use rustc_parse::maybe_new_parser_from_source_str; <ins> use rustc_parse::parser::ForceCollect; </ins> use rustc_session::parse::ParseSess; use rustc_span::source_map::FilePathMapping;

Discussion:
We have a Rust-2015 doc test which has an which started failing to build on nightly 2021-11-21 (but passes on stable/2021-11-20). It now fails with
Probably caused by (; no rollup?).
That seems unlikely, is more plausible. doesn't affect doctests.
Oh, I think I got misled by the "rustdoc" bit.
I can't reproduce this. I tried /// extern crate inner; /// and running , but all the tests passed fine. can you link the original code?
The failure is You can see the first failure in CI at
The following seems like a minimal reproduction when used with 2015: /// extern crate mycrate; /// mycrate::foo(); /// Bisected to .
cc , I think it might make sense to revert temporarily unless you already have an idea for a fix.
Change:
) -> Option<(ty::ParamEnv<'tcx>, ty::ParamEnv<'tcx>)> { let tcx = infcx.tcx; <ins> // Don't try to proess any nested obligations involving predicates // that are already in the `ParamEnv` (modulo regions): we already // know that they must hold. for predicate in param_env.caller_bounds() { fresh_preds.insert(self.clean_pred(infcx, predicate)); } </ins> let mut select = SelectionContext::with_negative(&infcx, true); let mut already_visited = FxHashSet::default();

Discussion:
rustc panic when running . The crate otherwise seems to test, run & work fine. Checkout rev . Run . <!-- 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
somewhat minified:
Somewhat interesting: nightly-2018-01-17 gives me: and cargo check as gives me the same error message. On nightly-2019-01-17 on the other hand cargo doc panics and cargo check does not complain any more: Edit: nightly-2018-12-01 gives me exactly no output. No warning, no ICE. That is weird as well...
Regression in nightly-2018-12-08 (...) (nightly-2018-12-07 is not available) The "no output" regression (from rejecting the program as such and giving no output at all) is in nightly-2018-09-13 (...)
The latter is an intended change caused by
This is still occurring, the panic seems to come from . Updated info: : <details<summary<strongBacktrace</strong</summary<p</p</details
Assigning as and removing .
Change:
self.r.define(parent, ident, TypeNS, imported_binding); } <del> ItemKind::GlobalAsm(..) => {} </del> ItemKind::Mod(..) if ident.name == kw::Invalid => {} // Crate root ItemKind::Mod(..) => {

Discussion:
<short summary of the bugI tried this code: Running on a project that has as its direct or indirect dependency. I expected to see this happen: All packages documented. Instead, this happened: — also fails on . : Does also happen for older nightlies, though I forgot to capture the versions before updating in hope it'd fix the issue. There are more ICE issues pointing at , but none on this line here. Backtrace:
I can confirm that this ICE does not occur on Rust 1.37.0 stable, as shown in This might be a regression that slipped through the stable release somehow.
This still happens on 1.39 stable.
cc
It also does it when documenting a project with on nightly. I had no trouble documenting all deps more than 2 weeks ago though.
This happened on our recent build rust 1.39.0 as well.
cc please triage regressions! If anyone would like to help out here: This is in need of a minimal example that reproduces the issue, as well as a bisection to pinpoint the PR that introduced this regression.
Sorry for not getting to this earlier. I've reduced down to: The is coming from the path inside which is messed up somehow by the macro. Bisecting this pointed to which almost certainly means it was caused by (cc. This is an issue in rustc as well because if you try to use the method from another crate like this for example: rather than the expected new` error since it now produces an ICE: <details<summarybacktrace</summary</detailsAnother interesting case comes from removing the inner module: This compile before but now somehow. Also the regressions in and are a similar but newer regression which I've made a new issue for: .
I guess I'll take a look since it's been a week. Thanks for the minimal code case!
Was this not fixed by ?
I don't know. If so then we're all good?
No, I can confirm there's still an ICE.
Is the nonrustdoc example from still ICEing or is it just the rustdoc issue left?
I'll see what happens.
Similarly to the case in this ICE in rustdoc may mean that a bug or error is silently ignored in rustc. So hiding it like does is not a good idea.
Fixed in
Change:
LhsExpr::AttributesParsed(attrs) => Some(attrs), _ => None, }; <del> if [token::DotDot, token::DotDotDot, token::DotDotEq].contains(&self.token.kind) { </del> <ins> if self.token.is_range_separator() { </ins> return self.parse_prefix_range_expr(attrs); } else { self.parse_prefix_expr(attrs)?

Discussion:
<!-- 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: is a valid expression (a  literal), so this error is misleading. It should at a minimum have a suggestion to replace with the valid version , and probably should just work. It also imho ideally shouldn't be a hard parser error blocking semantic passes; the parse of is fairly unambiguously intended, even if we decide we should still require the parenthesis. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I'm interested! Where should I look first? (I have no experience in rustc, some general experience in compilers tho)
The is a good place to start. If you have some compiler development experience already, that should get you going quickly enough. One specifically relevant section is is likely to be where you'll need to change. Also, ; you can to assign yourself to the issue to track that you're working on it.
For extra context, is accepted in expression position at least for both , , and obviously , so I have absolutely no idea what makes different that it causes a parser error in this case.
claim
Change:
<ins> #![feature(const_generics)] //~^ WARN the feature `const_generics` is incomplete and may cause the compiler to crash pub struct MyArray<const COUNT: usize>([u8; COUNT + 1]); //~^ ERROR constant expression depends on a generic parameter impl<const COUNT: usize> MyArray<COUNT> { fn inner(&self) -> &[u8; COUNT + 1] { //~^ ERROR constant expression depends on a generic parameter &self.0 } } fn main() {} </ins>

Discussion:
The code: It produced error: Although RFC not yet implemented, this code must work already. Or I'm wrong and this syntax does not supported by const-generics?
Not sure where you see the ICE, removing that.
This is glitch after the previous 2 issues.. It is not ICE.
To Minimal code: produce error: The variant also give this error.
Now it is ICE:
It's back to the original error.
Now it produce this errors:
The behaviour is now as expected. We just need a test now.
Const Generic RFC leads the code as possible: Is there another issue that is tracking it?
Yes, there are some subtle issues about making sure that constants in types are well-formed. The tracking issue for this is
Change:
<ins> #![feature(const_generics)] //~^ WARN the feature `const_generics` is incomplete and may cause the compiler to crash pub struct MyArray<const COUNT: usize>([u8; COUNT + 1]); //~^ ERROR constant expression depends on a generic parameter impl<const COUNT: usize> MyArray<COUNT> { fn inner(&self) -> &[u8; COUNT + 1] { //~^ ERROR constant expression depends on a generic parameter &self.0 } } fn main() {} </ins>

Discussion:
This code ran in the latest nightly(2019-11-19) does not compile: And it prints this error message
Reduced:
that gives a different error, because isn't defined. Perhaps you meant something like:
This appears to be working now.
Change:
if let Some(ref s) = build.config.ccache { cmd_finder.must_have(s); } <ins> // this warning is useless in CI, // and CI probably won't have the right branches anyway. if !build_helper::ci::CiEnv::is_ci() { if let Err(e) = warn_old_master_branch(&build.config.git_config(), &build.config.src) .map_err(|e| e.to_string()) { eprintln!("unable to check if upstream branch is old: {e}"); } } </ins> }

Discussion:
I have my master branch set up to track the master branch of my fork (mainly because i don't want to accidentally pull in every git tag into my shallow clone), so doesn't updated when i run (presumably the remote was created by ? i don't remember creating it, and lots of code needs it (or another branch pointing to this repo) to work). as it turns out, uses the state of to determine if a file has been modified. so instead of it formatting every file that i modified, it formats every file anyone has modified in the last few months. at no point did anything warn me that i need to be updating a remote i didn't add. it should probably do that. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
this could be addressed by checking the timestamp on .git/refs/remotes/upstream/master and warning if it is very old
claim
I ran into a similar issue where was building llvm from source instead of using the prebuilt ci version due to an outdated branch. Would it make sense to solve both issues in one go?
should be pretty easy, just call the same warning method for both build steps maybe it should be used for all build steps?