jiebi/CodeConvo huggingface dataset:
Change:
pub(crate) is_json_output: bool, } <del> impl<'a> Stripper<'a> { // We need to handle this differently for the JSON output because some non exported items could // be used in public API. And so, we need these items as well. `is_exported` only checks if they // are in the public API, which is not enough. #[inline] fn is_item_reachable(&self, item_id: ItemId) -> bool { if self.is_json_output { self.access_levels.is_reachable(item_id.expect_def_id()) } else { self.access_levels.is_exported(item_id.expect_def_id()) } </del> <ins> // We need to handle this differently for the JSON output because some non exported items could // be used in public API. And so, we need these items as well. `is_exported` only checks if they // are in the public API, which is not enough. #[inline] fn is_item_reachable( is_json_output: bool, access_levels: &AccessLevels<DefId>, item_id: ItemId, ) -> bool { if is_json_output { access_levels.is_reachable(item_id.expect_def_id()) } else { access_levels.is_exported(item_id.expect_def_id()) </ins> } }

Discussion:
cc label +A-docs +A-rustdoc-ui +C-enhancement +T-rustdoc This is technically a regression, but it doesn't feel appropriate to label it as such.
Here is an example of a block that should be hidden when is not passed:
Change:
output_base_dir(config, testpaths, revision).join("stamp") } <ins> /// Return an iterator over timestamps of files in the directory at `path`. fn collect_timestamps(path: &PathBuf) -> impl Iterator<Item=FileTime> { WalkDir::new(path) .into_iter() .map(|entry| entry.unwrap()) .filter(|entry| entry.metadata().unwrap().is_file()) .map(|entry| mtime(entry.path())) } </ins> fn up_to_date( config: &Config, testpaths: &TestPaths,

Discussion:
If I modify a file in the rustc source code (), is smart enough to rerun all tests. However, if I modify something in , then still ignores the tests that completed successfully in the previous run. Steps to reproduce: tests: . For example, replace the function in  with: tests again: Expected output: some tests fail. Actual output:
I would be interested in fixing this issue myself if someone could give me some guidance on how to do that. The main thing that I do not understand is how understands that was changed. It seems that it does not use files for this because they include only the hash of the configuration options which do not include version. cc
The most likely culprit (that ignores the test files) is in module. It is called from and will set the flag for the test depending on its output.
That being said, I find it hard to see how to adjust compiletest itself to take the dependencies into account. rustbuild should probably have some sort of dependency edge and delete the stamp files if/when stuff like compiletest changes.
Compiletest source code has only 9 files. Would it be acceptable to check that their timestamps are newer than the timestamp of the stamp file? PR:
Change:
FunctionSections: bool, DataSections: bool, TrapUnreachable: bool, <del> Singlethread: bool) </del> <ins> Singlethread: bool, AsmComments: bool) </ins> -> Option<&'static mut TargetMachine>; pub fn LLVMRustDisposeTargetMachine(T: &'static mut TargetMachine); pub fn LLVMRustAddAnalysisPasses(T: &'a TargetMachine, PM: &PassManager<'a>, M: &'a Module);

Discussion:
clang -S produces nicely commented .s files. It would be nice if rustc did this too. e.g. simd shuffles are commented .loc directives have the corresponding line number comment .loc 1 4 25 isstmt 1 ## test.c:4:25 debug information is commented .byte 14 ## DWFORMstrp .byte 17 ## DWATlowpc .byte 1 ## DWFORMaddr .byte 18 ## DWAThighpc .byte 1 ## DWFORM_addr
There might be a or flag already for this. AFAIK what clang emits comes from LLVM.
This flag is already , should be usable (issue can be closed?):
Any reason not to make this the default?
Likely the fact that it may change the behavior (I don't actually know what that means but this seems like a valid assumption).
it looks like -Z asm-comments doesn't do this. MCOptions.AsmVerbose must be set to true for the assembler to emit them.
So it looks like -Zasm-comments isn't actually used anywhere based on what I can find in the source... or, rather, its uses are in methods that are themselves never called.
Yeah, to get comments I believe I needed to set a verbose flag in some llvm context. Clang does this by default and it would be nice if rustc did too.
IIUC without this neither the playground nor godbolt (compiler-explorer) can map assembly to lines of Rust source code.
Godbolt uses debug info AFAIK? Our debug info isn't always great but in general it's working, isn't it?
It seems like they just don't do it much. Godbolt uses directives in the assembly file, which rustc seems to generate correctly, sorry for the noise.
Change:
<ins> // This test checks that bounds checks are elided when // index is part of a (x | y) < C style condition // min-llvm-version: 11.0.0 // compile-flags: -O #![crate_type = "lib"] // CHECK-LABEL: @get #[no_mangle] pub fn get(array: &[u8; 8], x: usize, y: usize) -> u8 { if x > 7 || y > 7 { 0 } else { // CHECK-NOT: panic_bounds_check array[y] } } </ins>

Discussion:
Context: this bug was reduced from indexing into a nested array, but this shows the same problem. () Rust doesn't elide the bounds check on , even though it's impossible for to be out of range due to the if condition. Rust does elide the bounds check when the if condition is just , however. Here is the generated ASM for the above code: and here is the generated ASM when we change the if to just be This occurs in both the latest versions of stable (1.44.1) and nightly (1.46.0-nightly (2020-06-26 ))
It seems that the bounds check does get elided if I split up the if expression. This generates
And it seems it needs two unlikely to produce the right happy path:
The assume intrinsic also seems to not work if a logical expression is used, maybe it's related? I.e. does not make subsequent bounds checks go away but 2 assumes do.
Godbolt: The problem is that the condition is converted to , at which point implication no longer works. It should be straightforward to teach LVI about this special case.
Fix has landed upstream, we'll pull it in with the LLVM 11 upgrade.
This if fixed in 1.47 with the LLVM 11 upgrade. It's probably worthwhile to add a codegen test, as bounds check optimization tends to be a bit fragile.
Great, thanks! I can handle the test
Change:
impl Stdin { pub fn new() -> io::Result<Stdin> { <del> get(c::STD_INPUT_HANDLE).map(|handle| { Stdin { handle: handle, utf8: Mutex::new(Cursor::new(Vec::new())), } </del> <ins> Ok(Stdin { utf8: Mutex::new(Cursor::new(Vec::new())), </ins> }) } pub fn read(&self, buf: &mut [u8]) -> io::Result<usize> { <del> let handle = match self.handle { Output::Console(ref c) => c.get().raw(), Output::Pipe(ref p) => return p.get().read(buf), </del> <ins> let handle = match try!(get(c::STD_INPUT_HANDLE)) { Output::Console(c) => c, Output::Pipe(p) => { let handle = Handle::new(p); let ret = handle.read(buf); handle.into_raw(); return ret } </ins> }; let mut utf8 = self.utf8.lock().unwrap(); // Read more if the buffer is empty

Discussion:
Over time the value of may change (e.g. see ) and we should likely reload the value over time instead of caching the return value to catch cases like this.
There's very little value in caching the result. takes 3 nanoseconds for me according to a quick bench.
Change:
eq::< for<'a,'b> Foo<(&'a int,&'b uint),uint>, Foo(&int,&uint) -> uint                             >(); <del> // FIXME(#18992) Test lifetime elision in `()` form: // eq::< for<'a,'b> Foo<(&'a int,), &'a int>, //      Foo(&int) -> &int                                   >(); </del> <ins> // lifetime elision eq::< for<'a,'b> Foo<(&'a int,), &'a int>, Foo(&int) -> &int                                   >(); </ins> // Errors expected: eq::< Foo<(),()>,                   Foo(char)                     >();

Discussion:
HRTB doesn't correctly implement lifetime elision for notation. See the test .
Nominating.
notes that this can be fixed backwards compatibly, and agrees. P-high, not 1.0.
Well, sort of -- I mean lifetime elision broke code, but almost only bad code. The problem is that people can use to satisfy the signature and then clients get to assume any lifetime they want.
Change:
gpr: u8, fpr: u8, reserved: u16, <del> overflow_arg_area: *mut (), reg_save_area: *mut (), </del> <ins> overflow_arg_area: *mut c_void, reg_save_area: *mut c_void, </ins> } /// x86_64 ABI implementation of a `va_list`.

Discussion:
On x8664, Aarch64, and PowerPC will not pass the lint, but it should. Given the following: The compiler will yield: The implementation of for the x8664, Aarch64, and PowerPC architectures uses or as the pointer type for the pointers to the architecture specific save areas (e.g., ).
defines . Perhaps should be used instead of
It would be fine to just special-case the language item in the lint implementation.
This seems reasonable to me too. The structure should (for obvious reasons) always be FFI safe.
Change:
error[E0158]: const parameters cannot be referenced in patterns <del> --> $DIR/const-match-pat-generic.rs:8:11 </del> <ins> --> $DIR/const-match-pat-generic.rs:9:9 </ins> | <del> LL |     const { V } => {}, |           ^^^^^ </del> <ins> LL |         const { V } => {}, |         ^^^^^^^^^^^ </ins> <del> error: aborting due to previous error </del> <ins> error: constant pattern depends on a generic parameter --> $DIR/const-match-pat-generic.rs:21:9 | LL |         const { f(V) } => {}, |         ^^^^^^^^^^^^^^ error: constant pattern depends on a generic parameter --> $DIR/const-match-pat-generic.rs:21:9 | LL |         const { f(V) } => {}, |         ^^^^^^^^^^^^^^ error: aborting due to 3 previous errors </ins> For more information about this error, try `rustc --explain E0158`.

Discussion:
Using a const parameter in an inline const pattern causes an ICE, but only when you don't directly use the parameter. This seems to be the same problem as , although under different circumstances. Using instead of gives Disappointing, but undoubtedly the intended behavior. The above example wouldn't be easy to come across naturally, but if the const parameter was (for example) an array and you tried to index it, the compiler would tell you to use a to do that. This code causes the same ICE: I should note that this issue is only present with the feature and the feature. : <details<summary<strongBacktrace</strong</summary<p</p</details
label +A-const-generics
Change:
<ins> #![feature(inherent_associated_types)] #![allow(incomplete_features)] struct Foo<T>(T); impl<'a> Foo<fn(&'a ())> { type Assoc = &'a (); } fn bar(_: fn(Foo<for<'b> fn(Foo<fn(&'b ())>::Assoc)>::Assoc)) {} //~^ ERROR higher-ranked subtype error 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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Hm, maybe not really a new (this month) regression but I also can't find any obvious duplicates right now...
searched toolchains nightly-2022-11-28 through nightly-2023-05-09 Regression in nightly-2022-12-05 Regression in cc
label F-inherentassociatedtypes
I'm pretty sure this can be fixed by erasing all regions no matter their de Bruijn index via instead of . This would "regress" but eh, I guess that's fine for now.
claim
Change:
pub llvm_version_check: bool, pub llvm_static_stdcpp: bool, pub llvm_link_shared: bool, <ins> pub llvm_targets: Option<String>, </ins> // rust codegen options pub rust_optimize: bool,

Discussion:
Currently, llvm is built with all the possible targets including Mips, ARM... For development, we can speed the build by enabling only the native target (x86 or x86_64). Maybe it would also speed the build of rustc?
FWIW, for development I use ccache (pass to ) and building LLVM takes one minute or less on a "fresh" bootstrap. (I usually work with several branches at the same time; one docker container per branch and all of them reuse the same ccache directory) Just please don't change the defaullt. I'd be very upset if I spent several minutes building stage1 rustc just to learn that it can't cross compile anything.
yeah, of course.
This is such a niche use case, to the point that it's arguably already moot by use of , if the sole purpose is to reduce build time. However there may be some other advantages, maybe space savings for use on some really storage-constrained systems? I don't know, it's trivial to make the list of targets configurable but the maintenance and support burden is real. What do the Rust team think? cc
Seems fine to me to add an option for this! We won't do it on the bots, but that doesn't mean it can't exist.
Change:
return Ok(expr); } } <ins> if (op.node == AssocOp::Equal || op.node == AssocOp::NotEqual) && self.token.kind == token::Eq && self.prev_token.span.hi() == self.token.span.lo() { // Look for JS' `===` and `!==` and recover 😇 let sp = op.span.to(self.token.span); let sugg = match op.node { AssocOp::Equal => "==", AssocOp::NotEqual => "!=", _ => unreachable!(), }; self.struct_span_err(sp, &format!("invalid comparison operator `{}=`", sugg)) .span_suggestion_short( sp, &format!("`{s}=` is not a valid comparison operator, use `{s}`", s = sugg), sugg.to_string(), Applicability::MachineApplicable, ) .emit(); self.bump(); } </ins> let op = op.node; // Special cases: if op == AssocOp::As {

Discussion:
Been working in JavaScript a lot lately and find myself accidentally typing this a lot. It would be nice to automatically detect this and offer a proper fix. Lots of languages use this syntax in addition to JavaScript so it seems like a reasonable error to make. Playground example below. () Errors:
I think the current error message is clear enough. Also I don't think providing auto-fix suggestion is easy, because the error happened when parsing AST.
Nice. But I still think the current error message is fine as is.
don't disagree, but handling it was relatively easy because there's no case where would be valid.
Change:
<ins> // build-pass // The ICE didn't happen with `cargo check` but `cargo build`. use std::marker::PhantomData; trait Owned<'a> { type Reader; } impl<'a> Owned<'a> for () { type Reader = (); } trait Handler { fn handle(&self); } struct CtxHandlerWithoutState<M, F> { message_type: PhantomData<M>, _function: F, } impl<M, F> CtxHandlerWithoutState<M, F> { pub fn new(_function: F) -> Self { Self { message_type: PhantomData, _function, } } } impl<'a, M, F> Handler for CtxHandlerWithoutState<M, F> where F: Fn(<M as Owned<'a>>::Reader), M: Owned<'a>, { fn handle(&self) {} } fn e_to_i<M: for<'a> Owned<'a>>(_: <M as Owned<'_>>::Reader) {} fn send_external_to_internal<M>() where M: for<'a> Owned<'a>, { let _: Box<dyn Handler> = Box::new(CtxHandlerWithoutState::<M, _>::new(e_to_i::<M>)); } fn main() { send_external_to_internal::<()>() } </ins>

Discussion:
When trying to use generic function with capnproto structs the compiler fails to infer types correctly. I failed to distil the problem to a smaller size. Capnproto generates code that implements traits like this impl &lt;'a::capnp::traits::Owned&lt;'afor Owned { type Reader = Reader&lt;'a; type Builder = Builder&lt;'a; } <details<summaryError</summary<pre<codeerror: internal compiler error: Encountered errors resolving bounds after type-checking </code</pre</detailsWhich I think can be distilled down to which is the same type. : rustc 1.37.0 ( 2019-08-13) binary: rustc commit-hash: commit-date: 2019-08-13 host: x86_64-unknown-linux-gnu release: 1.37.0 LLVM version: 8.0 My first issue btw, sorry for noobyness.
Please provide the source code needed to reproduce this
It can be found here on the CRASH branch. To compile you need capnproto etc also :/
Here is a self-contained reduced example from that code. It can probably be reduced a lot more.
Is this good enough as MCVE? Edit: Reduced it further
Seems to no longer ICE with modify labels: E-needs-test
searched nightlies: from nightly-2021-05-01 to nightly-2021-09-10 regressed nightly: nightly-2021-08-26 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
Looks like fixed this.
Change:
}; capture_info.capture_kind = capture_kind; <ins> let capture_info = if let Some(existing) = processed.get(&place) { determine_capture_info(*existing, capture_info) } else { capture_info }; </ins> processed.insert(place, capture_info); }

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. --I tried this code: I expected to see this happen: The code should compile. Instead, this happened: This compiler error is thrown: <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: (also works on stable 1.54). Starting from , I get the error shown above. <!-- Provide the version you are using that has the regression. --: current nightly Also broken on 1.55 beta 7: Both installed via rustup. <!-- Did the compiler crash? If so, please provide a backtrace. --n/a <!-- 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 --This seems similar to , which was fixed in / (which AFAIU should be included in ), but it still does not work.
Bisected to cc
the root cause is: if one place captured by more than 2 locations, the will be overrided by the last one in : In this case, is captured by at line 7 and at line 8, the captureinfo supercedes the previous .
Thank you for this!
Change:
version = "0.0.0" dependencies = [ "diff", <del> "env_logger 0.7.0", </del> <ins> "env_logger 0.7.1", </ins> "getopts", "lazy_static 1.3.0", "libc",

Discussion:
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! cc the PR reviewer, and nominating for compiler team prioritization.
triage: has PR (in ). Marking P-medium and removing nomination.
Change:
<ins> #![crate_name = "foo"] // @has foo/struct.Bar.html // @!has - '//h3[@id="impl-Sized"]' pub struct Bar { a: u16, } // @has foo/struct.Foo.html // @!has - '//h3[@id="impl-Sized"]' pub struct Foo<T: ?Sized>(T); // @has foo/struct.Unsized.html // @has - '//h3[@id="impl-Sized"]/code' 'impl !Sized for Unsized' pub struct Unsized { data: [u8], } </ins>

Discussion:
For example  should have a bound, but we're a little too aggressive about pruning out the bounds. For comparison  does indeed have the bound. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This also applies to bounds on traits.
This prompted a question on IRC about whether requires , because the bound is not visible in the libstd documentation. It is visible in the libcore docs though.
Triage: This still happens
This actually ended up biting me today, is there a plan to handle this? I could help implement if I get pointers
did not fix this - it now shows , which is nice, but it doesn't show bounds on traits. For traits it does matter because the default is .
I would start by finding out why this is different between local crates and cross-crate re-exports. I expect is behaving differently from .
Ah, I also hit this today when looking at . Kudos to whoever can figure this one out :)
claim
Change:
sym::lazy_normalization_consts, sym::specialization, ]; <ins> /// Some features are not allowed to be used together at the same time, if /// the two are present, produce an error pub const INCOMPATIBLE_FEATURES: &[(Symbol, Symbol)] = &[(sym::const_generics, sym::min_const_generics)]; </ins>

Discussion:
I expect the code below code to compile, but it fails. should allow more than just the types whitelisted in , but it seems rustc only looks at the flag in this case. The error message is:
You are right But why would you want to use the two of them?
I imagine this to happen whenever at first you only decide to use , but then later also switch to . You might just follow rustc, which tells you to add to your project, so you do, but then you get the behaviour as described in this issue. This could also perhaps get triggered in a more subtle way where you write a library that uses to enable or disable features.
what do you think ?
It probably makes sense to instead check if we are not using here, but there are a quite a few places were we check for , we maybe want to instead emit an error/warning when using both and in the same crate.
Created a way to produce an error in case of incompatible features, like this one
I have one question, how does using 'incompatible feature' cause maybe undefined behavior? Are there other incompatible features? In this case, wouldn't it be better to produce an error message like "feature(constgenerics) is a superset of feature(minconst_generics)"?
Note that: results in a : So currently is not a superset of .
You are missing a in your feature. I still think constgenerics are a superset of minconstgenerics, but rustc just suggest using the smaller one in this case becouse that's the subset aiming to be stabilized for now
Ah of course, my bad I was confused looking at some ui tests for const generics, and missed that those now have support differentiating between expected behavior under and , and thought a particular error was always being thrown, instead of only under .
Change:
| LL |     0u32 as char; |     ^^^^^^^^^^^^ invalid cast <ins> | help: try `char::from_u32` instead --> $DIR/error-festival.rs:25:5 | LL |     0u32 as char; |     ^^^^^^^^^^^^ </ins> error[E0605]: non-primitive cast: `u8` as `Vec<u8>` --> $DIR/error-festival.rs:29:5

Discussion:
Given the following code: The current output is: This is not very clear. There are two pieces of background information the user needs here: s are Unicode scalar values, which are any integer value from 0 to 0xD7FF and 0xE000 to 0x10FFFF. Only u8 can be statically guaranteed to meet this requirement so only u8 can be cast to char. is probably what the user wants, if they are interested in non-ASCII values. The user is directed to further information available at and , neither of which explains either of those two points. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I think a good improvement would be to a) Add more detail about this to b) Add a to this error that suggests are you interested in working on one or both of those? :)
claim
While I was reading the docs I noticed a minor error in : This isn't true; a USV is a Code Point within either of two ranges, not one. It's also a bit cagey about what the ranges are numerically; I don't know if this is intentional. Personally I would re-write it to the below: Would I put that in the same PR (as they're both documentation) or a new issue?
A new PR would be better.