jiebi/CodeConvo huggingface dataset:
Change:
#[macro_use] extern crate rustc_middle; <ins> use rustc_ast as ast; </ins> use rustc_data_structures::fx::{FxHashMap, FxHashSet}; use rustc_data_structures::sync::Lrc; use rustc_hir::def_id::CrateNum; use rustc_hir::LangItem; use rustc_middle::dep_graph::WorkProduct; <del> use rustc_middle::middle::cstore::{CrateSource, LibSource, NativeLib}; </del> <ins> use rustc_middle::middle::cstore::{self, CrateSource, LibSource}; </ins> use rustc_middle::middle::dependency_format::Dependencies; use rustc_middle::ty::query::Providers; use rustc_session::config::{OutputFilenames, OutputType, RUST_CGU_EXT}; <ins> use rustc_session::utils::NativeLibKind; </ins> use rustc_span::symbol::Symbol; use std::path::{Path, PathBuf};

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 command: I expected to see this happen: An file is generated. 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. --: Originally posted by in cc (original implementer of
PR changed the encode/decode method of . When was implemented, the encode/decode of was purposely crafted to avoid calling the encode/decode method of . The most straightforward fix is to implement / for to allow it be serialized outside of metadata. After that, may be now it is the time to re-think the way we store data in the file. What do you think ?
I think should completely be avoided in the input of the linker function. One of the uses if in it's field. This field doesn't seem to be used by the linking code.
Good suggestion, let me look into it.
are you still working on this?
Thank you for reminding and apologize for the delay. I did create a prototype but haven't got a chance polish it yet. I'll create the PR this week.
Sorry again about the delay. I've created PR , which fixes this issue.
Change:
<ins> error: unresolved link to `rustfmt::skip` --> $DIR/issue-111189-resolution-ice.rs:6:7 | LL | /// #[rustfmt::skip] |       ^^^^^^^^^^^^^ no item named `rustfmt` in scope | note: the lint level is defined here --> $DIR/issue-111189-resolution-ice.rs:4:9 | LL | #![deny(warnings)] |         ^^^^^^^^ = note: `#[deny(rustdoc::broken_intra_doc_links)]` implied by `#[deny(warnings)]` error: unresolved link to `clippy::whatever` --> $DIR/issue-111189-resolution-ice.rs:8:7 | LL | /// #[clippy::whatever] |       ^^^^^^^^^^^^^^^^ no item named `clippy` in scope error: aborting due to 2 previous errors </ins>

Discussion:
Using cargo 1.71.0-nightly ( 2023-05-02) or cargo 1.69.0 ( 2023-04-12), I get a crash when trying to generate documentation from this excerpt of the Matrix Rust SDK: <details<summary<strongBacktrace</strong</summary</details
Change:
return RustStructPrinter(val, false) if enum_member_count == 1: <del> if enum_members[0].name == None: </del> <ins> first_variant_name = enum_members[0].name if first_variant_name == None: </ins> # This is a singleton enum return rust_pretty_printer_lookup_function(val[enum_members[0]]) else: <del> assert enum_members[0].name.startswith("RUST$ENCODED$ENUM$") </del> <ins> assert first_variant_name.startswith("RUST$ENCODED$ENUM$") </ins> # This is a space-optimized enum <del> last_separator_index = enum_members[0].name.rfind("$") </del> <ins> last_separator_index = first_variant_name.rfind("$") </ins> second_last_separator_index = first_variant_name.rfind("$", 0, last_separator_index) disr_field_index = first_variant_name[second_last_separator_index + 1 : last_separator_index]

Discussion:
Debuginfo for (and probably also ) enums is not correct if the pointer that doubles as discriminant is a fat pointer. Steps to reproduce: (1) Compile the following program with (2) Print the value of in LLDB with pretty printers enabled: This should print instead of . Maybe it's just the LLDB pretty printer that needs to be adapted.
Change:
return_qualif: Option<Qualif>, qualif: Qualif, const_fn_arg_vars: BitVector, <del> local_needs_drop: IndexVec<Local, Option<Span>>, </del> temp_promotion_state: IndexVec<Local, TempState>, promotion_candidates: Vec<Candidate> }

Discussion:
These currently compile, even if they can be used from compile-time code to trigger a drop: cc
Change:
impl<'a> fmt::Display for GenericBounds<'a> { fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result { <ins> let mut bounds_dup = FxHashSet::default(); </ins> let &GenericBounds(bounds) = self; <del> for (i, bound) in bounds.iter().enumerate() { </del> <ins> for (i, bound) in bounds.iter().filter(|b| bounds_dup.insert(b.to_string())).enumerate() { </ins> if i > 0 { f.write_str(" + ")?; }

Discussion:
Example: Behavior is observable on stable and nightly. Clearly can be shortened to just .
This is a problem with how the struct is represented when re-exporting from a different crate. For example, : The gets converted into a where clause in the re-export, but i'm not sure what introduces the duplicate lifetime bound.
Current documentation still has evidence of this bug: see e.g. in
Change:
pub bounds: GenericBounds<'hir>, } <ins> impl WhereBoundPredicate<'hir> { /// Returns `true` if `param_def_id` matches the `bounded_ty` of this predicate. pub fn is_param_bound(&self, param_def_id: DefId) -> bool { let path = match self.bounded_ty.kind { TyKind::Path(QPath::Resolved(None, path)) => path, _ => return false, }; match path.res { Res::Def(DefKind::TyParam, def_id) | Res::SelfTy(Some(def_id), None) => { def_id == param_def_id } _ => false, } } } </ins> /// A lifetime predicate (e.g., `'a: 'b + 'c`). #[derive(Debug, HashStable_Generic)] pub struct WhereRegionPredicate<'hir> {

Discussion:
Given the following code: The current output is: Ideally, the diagnostic shouldn't suggest relaxing an explicit bound in the where clause. (There is already code that skips the suggestion for type parameters that have an explicit bound.) I can work on this in an in-progress pull request where I'm making other improvements to unsized suggestions. claim label +A-traits +A-typesystem +D-papercut <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Change:
let tcx = pcx.fcx.ccx.tcx; let def = tcx.def_map.borrow()[pat.id].clone(); <del> let def_type = ty::lookup_item_type(tcx, def.def_id()); let (enum_def_id, variant_def_id) = match ty::get(def_type.ty).sty { ty::ty_struct(struct_def_id, _) => (struct_def_id, struct_def_id), ty::ty_enum(enum_def_id, _) if def == def::DefVariant(enum_def_id, def.def_id(), true) => (enum_def_id, def.def_id()), _ => { </del> <ins> let (enum_def_id, variant_def_id) = match def { def::DefTrait(_) => { </ins> let name = pprust::path_to_string(path); <del> span_err!(tcx.sess, pat.span, E0163, "`{}` does not name a struct or a struct variant", name); </del> <ins> span_err!(tcx.sess, pat.span, E0168, "use of trait `{}` in a struct pattern", name); </ins> fcx.write_error(pat.id); for field in fields.iter() { check_pat(pcx, &*field.node.pat, ty::mk_err()); } return; <ins> }, _ => { let def_type = ty::lookup_item_type(tcx, def.def_id()); match ty::get(def_type.ty).sty { ty::ty_struct(struct_def_id, _) => (struct_def_id, struct_def_id), ty::ty_enum(enum_def_id, _) if def == def::DefVariant(enum_def_id, def.def_id(), true) => (enum_def_id, def.def_id()), _ => { let name = pprust::path_to_string(path); span_err!(tcx.sess, pat.span, E0163, "`{}` does not name a struct or a struct variant", name); fcx.write_error(pat.id); for field in fields.iter() { check_pat(pcx, &*field.node.pat, ty::mk_err()); } return; } } </ins> } };

Discussion:
Not the best title, but I suppose it somehow summarizes the situation. There's no ICE if I un-comment "use buffer" and prefix Buffer as the comment is suggesting. There's also no ICE if I rename Buffer into anything else. (fun!) rustc 0.13.0-nightly ( 2014-11-11 22:37:05 +0000) binary: rustc commit-hash: commit-date: 2014-11-11 22:37:05 +0000 host: x8664-apple-darwin release: 0.13.0-nightly
Change:
} ty::ExistentialPredicate::Projection(..) => None, ty::ExistentialPredicate::AutoTrait(..) => Some(predicate), <del> }) .collect(); tcx.mk_poly_existential_predicates(&predicates) </del> <ins> } })) </ins> } /// Transforms args for being encoded and used in the substitution dictionary.

Discussion:
<!-- [31mICE[0m: Rustc '-Zsanitizer=cfi -Ccodegen-units=1 -Clto -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'index out of bounds: the len is 0 but the index is 0'', 'thread 'rustc' panicked at 'index out of bounds: the len is 0 but the index is 0'' File: --original: Version information Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I believe this happens since cc
seems to also cause problems
The core problem here is the encoding of the receiver on a object that has no principal. There's a fix for this in the larger patch stack I was breaking down to land piecewise. I'll upload it in a moment. claim
Change:
return false; } <ins> fn escape_dep_filename(filename: &str) -> String { // Apparently clang and gcc *only* escape spaces: // http://llvm.org/klaus/clang/commit/9d50634cfc268ecc9a7250226dd5ca0e945240d4 filename.replace(" ", " ") } </ins> fn write_out_deps(sess: &Session, input: &Input, outputs: &OutputFilenames,

Discussion:
and maybe other characters as well? I'm not actually entirely sure what syntax should be used, but I imagine that gcc knows!
Change:
self.definitions.create_def_with_parent(parent_def, node_id, data, self.expansion, span) } <del> pub fn with_parent<F: FnOnce(&mut Self)>(&mut self, parent_def: DefIndex, f: F) { </del> <ins> fn with_parent<F: FnOnce(&mut Self)>(&mut self, parent_def: DefIndex, f: F) { </ins> let orig_parent_def = std::mem::replace(&mut self.parent_def, parent_def); f(self); self.parent_def = orig_parent_def;

Discussion:
Stable, and nightly-2019-09-09: nightly-2019-09-10: Mentioning because this is likely from .
Yeah, this is some known shortcut taken in , sorry. Didn't expect people to hit it that fast. Will fix ~this weekend.
Thanks. The realistic usage where this appears is if you forget to import a derive macro, which happens commonly.
Un-nominating since Vadim self-assigned.
triage: P-high.
Fixed in
Change:
<ins> // Copyright 2018 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 xyz() -> u8 { 42 } const NUM: u8 = xyz(); //~^ ERROR calls in constants are limited to constant functions, struct and enum constructors fn main() { match 1 { NUM => unimplemented!(), _ => unimplemented!(), } } </ins>

Discussion:
I encountered an internal compiler error (on stable, beta and nightly) in my code and i could reduce it to this: . I would expect that this program won't compile because of the non-const fn in a const declaration. Nightly rightly gives an error message to that effect and panics, stable just panics. Stacktrace:
No ICE in current stable
But using a random non-const-fn ICEs: cc
Ah, CTFE errors are supposed to be silently ignored.
Change:
fn const_uint(&self, t: Self::Type, i: u64) -> Self::Value; fn const_uint_big(&self, t: Self::Type, u: u128) -> Self::Value; fn const_bool(&self, val: bool) -> Self::Value; <ins> fn const_i16(&self, i: i16) -> Self::Value; </ins> fn const_i32(&self, i: i32) -> Self::Value; fn const_u32(&self, i: u32) -> Self::Value; fn const_u64(&self, i: u64) -> Self::Value;

Discussion:
uses , and declares it to return i32, in reality it returns c_int, so this is a potential portability concern. Maybe memcmp can be made an intrinsic to resolve this.
It also takes a parameter, not a .
Neither of these are a practical issue (yet). crate libc does not support any other configuration than so far.
cc
The extern function is now in
What should we do next? Should we try to create a intrinsic?
Hi, I believe this issue is causing array comparisons on the AVR architecture to break (see the linked issue, ). Is there any consensus on a path forward here?
Change:
<del> Subproject commit 09cadcbb62a3529801d0463d9878db3f0b5060c7 </del> <ins> Subproject commit 7a2f1cadcd5120c44eda3596053de767cd8173a2 </ins>

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!
Change:
err.note(&format!( "the following trait bounds were not satisfied:n{bound_list}" )); <ins> unsatisfied_bounds = true; </ins> } }

Discussion:
Given the following code (): The output on is: <details<summaryLong diagnostic</summary</details, , , and are suggested three times each: once for , once for , and once for . I'm not sure if this is a problem, but this seems incredibly verbose to me. Note that the output on stable 1.51 and beta 1.52 is different:
My mistake, each repetition is actually different in that two suggest taking a reference to : This still seems like a fairly massive diagnostic, though. I've updated the original post in light of this. Feel free to close if a diagnostic of this size is fine here.
cc
Might be a duplicate of , or at least fixed by the same PR that fixed it
Even if it was considered reasonable to suggest each and every possible type combination, there is no pressing reason for it to generate the intervening lines as well: rustc is a compiler, not a can of spam. This remains unpatched on nightly, and is thus a stable-to-beta diagnostic regression.
AFAICT, this is not present on beta, and is only present on nightly, so it's a stable-to-nightly regression. Please correct me if I misunderstood!
searched nightlies: from nightly-2021-01-01 to nightly-2021-04-24 regressed nightly: nightly-2021-04-09 searched commits: from to regressed commit: That is: so it’s . I guess has already been mentioned. label D-verbose
Yes, yes, I introduced this regression. Mea culpa, everybody. In my defense I keep flip-flopping between being too restrictive and too permissive for new suggestions and someone always ends up getting the short end of the stick. This week, I'm leaning towards "too permissive" and if the suggestion triggers too often, then detect the cases and make it more constrained, because the alternative is that the suggestion isn't shown when it could, and we'll never find out. This is IMO better, as long as regressions are caught in nightly, like it was in this case.&lt;/rantAnyways, fixes this.
Assigning and removing .
This now affects 1.53.0 beta. Updating the labels accordingly.
Still needs to be backported.
the beta backport for patch was approved, can this now be closed?

I think we should wait until it actually lands onto beta
This was merged in beta already, right?
Ah, so it was.
Change:
} fn render_all(mut self) { <del> let mut line = String::new(); </del> <ins> let mut line = Vec::new(); </ins> loop { line.clear(); <del> match self.stdout.read_line(&mut line) { </del> <ins> match self.stdout.read_until(b'n', &mut line) { </ins> Ok(_) => {} Err(err) if err.kind() == std::io::ErrorKind::UnexpectedEof => break, Err(err) => panic!("failed to read output of test runner: {err}"),

Discussion:
(Sorry if this isn't the right template, I wasn't sure what to choose) Hi, when I run tests with x.py from the command I get this error .
can you add some more context? there should be output printed before this panic, what does it say? what commit are you testing?
I'd like to contribute to Rust so I'm first trying to understand and try the tests from x.py, I haven't made any changes, I just cloned the repo then did an x.py setup then this command . Here is what I get from this command:
ok, great! now we need to find which of the tests are causing the "Microsoft Windows [version 10.0..1778]" output - can you run and print the ~20 or so lines before the panic?
hmm, that doesn't show the test that panicked. try adding ?
still the same thing, earlier today I had a theory, I thought it had nothing to do with tests but more a story of utf-8 and console
right, I understand it's still panicking, but I'm trying to find what's causing it to panic. alternatively, you could try making this change to bootstrap to have it print the thing it couldn't parse: you can paste that into and it should make the change for you.
I'm not sure what to copy, is that enough?
is that with ? I'm trying to find which of the tests are emitting this output, not just the output itself. If you could paste the 20 or so lines before in addition to this version output it would be very helpful.
It's with this line, but I don't know where to start copying the 20 lines, I don't have any more crashes?
I started from the last line where I was
hmm, this runs on windows, maybe that's printing the version notice?
can you post the output of ?
hmm ok, but you don't see the "Microsoft Windows [version 10.0..1778]" from ? it might be a different test that's making bootstrap panic then. cc do you have ideas what could be going wrong here? is using a french locale and that's making one of the tests emit non-utf8 on Windows for some reason.

When I launch a terminal, I get "Microsoft Windows...", but with the command I don't get "Microsoft Windows..."
I set my computer to English, I deleted the changes from earlier and I no longer have the problem.
Setting the environment variable to should work if the Visual Studio English language pack is installed. I believe rustc itself sets this. I did recently add some code to rustc to attempt to re-encode as UTF-8 if the output is not UTF-8 but this only triggers for linker output. Perhaps other tools may also want the same treatment but I've not investigated.
Oh sorry, just read that again. This is caused by cmd when used with ? Hm, strange. I'm not sure off-hand. Using should switch to the UTF-8 code page. But I'm unsure of the cause so I don't know if that would help in this case.
Change:
/// difficult-to-debug problems. /// /// Use this function only when you can prove that the code will never call it. <ins> /// Otherwise, consider using the [`unreachable!`] macro, which does not allow /// optimizations but will panic when executed. </ins> /// <del> /// The [`unreachable!()`] macro is the safe counterpart of this function, which /// will panic instead when executed. /// /// [`unreachable!()`]: ../macro.unreachable.html </del> <ins> /// [`unreachable!`]: ../macro.unreachable.html </ins> /// /// # Example ///

Discussion:
The documentation for  mentions two ways that it can affect a program: can enable the compiler to make optimizations based on the assumption that the function will never be executed. the function actually is executed, its behavior is undefined. It then goes on to mention the macro, saying This statement could be read as addressing the 2nd effect, but not the 1st. In other words, it could be interpreted as saying "the compiler will assume that will never be executed, but in the event that it is it will cause a panic." It might be worth rewording this statement to make it clear that neither (1) nor (2) applies to the safe version.
Would you like to rephrase this yourself, or would you like me to take an attempt?
Change:
self.custom_flags | self.attributes | self.security_qos_flags | <del> if self.security_qos_flags != 0 { c::SECURITY_SQOS_PRESENT } else { 0 } | </del> if self.create_new { c::FILE_FLAG_OPEN_REPARSE_POINT } else { 0 } } }

Discussion:
By default, opening a named pipe on Windows allows the server to impersonate the client. This is a security vulnerability. Pass to prevent this. Since it fixes a security hole, I don’t think this needs an RFC.
Where do we use named pipes?
Nowhere, but it is possible to open a named pipe as a file.
Could you be more clear? What exactly needs to change inside Rust? I assume we'd have to add some form of detection around file opening in windows..?
Whenever libstd calls CreateFileW(), it needs to pass these flags to avoid a local privilege escalation exploit.
can you tell anything about what potential issue you hit when trying to work on this in Or do you have WIP code of the test you where working on?
A simple explanation of the security problem: What could be a problem with setting these flags always: the flag is the same as . The first is supposed to be used with named pipes, the other for files and directories. So if we start to unconditionally add , it will in reality set the in almost all cases. Now I've never seen a system with 'hierarchical storage' where would be necessary. It is intended for systems that combine fast store like hard drives, with slow bulk storage like tapes. File operations like indexing, searching, or backup that want to work well on such systems should open files that have the attribute with this flag. Otherwise a lot of data from tape may be put back online on hard drives. See at The Old New Thing. While investigation this, I found another issue with : one of the values it takes is , whis is simply . Currently, when you set , it will silently be ignored unless you also happen to set (which our API is supposed to set automatically). Easy to fix though. Now I don't care much for working well with hierarchical storage. But we should not break it without having some sort of workaround available. We can say that if user code contains it should be able to handle Windows-specific oddities such as this one. We could make it so that even is enough to disable automatic sqos flags. But it doesn't feel great to just drop a security measure when the user could be doing something unrelated, such as the buffering hint . Only set when we know what we are trying to open is a named pipe.

I think all named pipes start with , and we know the filename when setting the flags. But I am not sure if this really works, or if it is possible for an unprivileged process to create a symbolic link to one in the object manager. I don't know if I'll get to making a PR and doing the required testing, just writing down what I've found so far.
Change:
<ins> // check-pass // issue #69184 #![feature(generic_associated_types)] #![allow(incomplete_features)] trait A { type B<'a>; fn make_b<'a>(&'a self) -> Self::B<'a>; } struct S {} impl A for S { type B<'a> = &'a S; fn make_b<'a>(&'a self) -> &'a Self { self } } enum E<'a> { S(<S as A>::B<'a>), } fn main() {} </ins>

Discussion:
This is a follow up on , which now works. The following doesn't (): Error is: however, this lifetime clearly is used and is required.
The variance code in is: It seems to me that this is disregarding the substitutions for if I'm understanding what does here wrt. the substitutions (this pretty poorly documented right now). cc
BTW how long do we need to keep this warning around? I understand that this is basically a given when using nightly features. (It puts me off using it in my normal build path — but presumably that's exactly what is wanted, in order to detect bugs like the one reported here.)
We only use for those that have been ICE-prone in the past or are generally not in a "considered implemented modulo bugs" state. It's quite a small set of features that are incomplete like this. GATs specifically are to my knowledge nowhere near ready to be "implemented modulo bugs".
On this topic, the following builds, but the bound fails with:
Also, the following fails: with: This bound may not make much sense (since there is another lifetime parameter), but I believe it should be valid to specify here.
I'm running into a similar issue which I believe is the same as this: