jiebi/CodeConvo huggingface dataset:
Change:
// dependent dlls. Note that this uses cfg!(windows) as opposed to // targ_cfg because syntax extensions are always loaded for the host // compiler, not for the target. <del> let mut _old_path = OsString::new(); </del> <ins> // // This is somewhat of an inherently racy operation, however, as // multiple threads calling this function could possibly continue // extending PATH far beyond what it should. To solve this for now we // just don't add any new elements to PATH which are already there // within PATH. This is basically a targeted fix at #17360 for rustdoc // which runs rustc in parallel but has been seen (#33844) to cause // problems with PATH becoming too long. let mut old_path = OsString::new(); </ins> if cfg!(windows) { <del> _old_path = env::var_os("PATH").unwrap_or(_old_path); </del> <ins> old_path = env::var_os("PATH").unwrap_or(old_path); </ins> let mut new_path = sess.host_filesearch(PathKind::All) .get_dylib_search_paths(); <del> new_path.extend(env::split_paths(&_old_path)); </del> <ins> for path in env::split_paths(&old_path) { if !new_path.contains(&path) { new_path.push(path); } } </ins> env::set_var("PATH", &env::join_paths(new_path).unwrap()); } let features = sess.features.borrow();

Discussion:
Mentioned in , there are two places where rustc sets and resets . Doing this means that running multiple compilations in parallel will stomp on each others' environment variables. This can happen, e.g. in rustdoc which runs tests by driving rustc directly. The proper way to set the environment for subprocesses is through the process Command type. cc
Yes, we could do that for subprocesses, but what about syntax extension dylibs? I guess this depends on why we are munging PATH/DYLDLIBRARYPATH/LDLIBRARYPATH: Is this because we want the OS to find the extension dylib itself? If so, we could just search along the augmented path ourselves, then load by absolute path. Or, is this because we need the OS to be able to find other dylibs that the extension dylib depends on? In this case, I don't see another way but to munge the PATH envvar. I don't know about Linux, but Windows does not seem to have a concept of a per-thread dll search path... looks like you wrote the relevant bit of code in Do you remember which of the two it was?
For the case 2, I suppose we could add with an internal mutex, that would temporarily alter PATH before delegating to . Of course, this would still race with direct calls to , but better than nothing. In fact, because essentially allows to mutate global variables, perhaps it should be marked as unsafe?
I thought it was case 1. Interesting idea, marking as unsafe... though note that the rules about when code needs to be annotated with is really meant to ensure data race freedom in safe code, not arbitrary race freedom
Triage: In , mentions this block of code: It looks like this code still doesn't prevent adding to the path over and over again.
I believe we've been seeing this a lot recently as , which is spurious test failures from something being too big, and it's probably environment variables ( coming back to haunt us)
Change:
<ins> use std::pin::Pin; use std::marker::PhantomPinned; #[derive(Debug)] struct Test { _marker: PhantomPinned, } impl Test { fn new() -> Self { Test { _marker: PhantomPinned, // This makes our type `!Unpin` } } } fn dummy(_: &mut Test) {} pub fn main() { let mut test1 = Test::new(); let mut test1 = unsafe { Pin::new_unchecked(&mut test1) }; dummy(test1.get_mut()); //~ ERROR E0277 } </ins>

Discussion:
Consider the following code, taken from the (): Local pin construction was stabilized in . We should update the diagnostics to suggest this instead of the more expensive call. No response cc/ This is probably a "good first issue" as well. If someone can tag it as such? <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
In some cases, works but does not (e.g., if you want ownership of the pinned future), so I think it's better to suggest both. Or something like:
claim
Alright, the suggestion has been in . IDK how to link a PR to an issue though, should I just reference the issue in the description of the PR?
if you put " in the PR description, it will automatically close this issue when the PR is merged :)
Change:
($dst:expr, $($arg:tt)*) => ($dst.write_fmt(format_args!($($arg)*))) } <del> /// Use the `format!` syntax to write data into a buffer, appending a newline. /// On all platforms, the newline is the LINE FEED character (`n`/`U+000A`) /// alone (no additional CARRIAGE RETURN (`r`/`U+000D`). </del> <ins> /// Write formatted data into a buffer, with appending a newline. /// /// On all platforms, the newline is the LINE FEED character (`n`/`U+000A`) alone /// (no additional CARRIAGE RETURN (`r`/`U+000D`). </ins> /// <del> /// This macro is typically used with a buffer of `&mut `[`Write`][write]. </del> <ins> /// This macro accepts any value with `write_fmt` method as a writer, a format string, and a list /// of arguments to format. /// /// `write_fmt` method usually comes from an implementation of [`std::fmt::Write`][fmt_write] or /// [`std::io::Write`][io_write] traits. These are sometimes called 'writers'. /// /// Passed arguments will be formatted according to the specified format string and the resulting /// string will be passed to the writer. </ins> /// /// See [`std::fmt`][fmt] for more information on format syntax. /// <ins> /// Return value is completely dependent on the 'write_fmt' method. /// /// Common return values are: [`Result`][enum_result], [`io::Result`][type_result] /// </ins> /// [fmt]: ../std/fmt/index.html <del> /// [write]: ../std/io/trait.Write.html </del> <ins> /// [fmt_write]: ../std/fmt/trait.Write.html /// [io_write]: ../std/io/trait.Write.html /// [enum_result]: ../std/result/enum.Result.html /// [type_result]: ../std/io/type.Result.html </ins> /// /// # Examples ///

Discussion:
Looking at  documentation page, the only thing you can figure out is that does return something and “something” has a method.
I'm pretty sure that write is not even guaranteed to return anything with an method... Write basically calls whatever method on is in scope (and makes no_ other guarantees).
It, then, should document that.
Yay duck typing!
part of
I would be willing to work with anyone who wanted to fix this issue.
Some related issues regarding that macro & it's documentation: ,
Hello! I can work on this.
great! Do you need any help from me?
Hello. Not currently. I'll come up with a PR and ask your comments on it tomorrow or the next day. Thanks for keeping an eye!
Change:
<ins> // Ensure that we properly deal with missing/placeholder types inside GACs. // issue: rust-lang/rust#124833 #![feature(generic_const_items)] #![allow(incomplete_features)] trait Trait { const K<T>: T; const Q<'a>: &'a str; } impl Trait for () { const K<T> = (); //~^ ERROR missing type for `const` item //~| ERROR mismatched types //~| ERROR mismatched types const Q = ""; //~^ ERROR missing type for `const` item //~| ERROR lifetime parameters or bounds on const `Q` do not match the trait declaration } 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. --(reduced) (original) This code is very similar to closed issue . The only difference is in line 17 which was in previous issue and now it's <!-- 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 --
label -needs-triage F-genericconstitems claim
Change:
let tcx = self.tcx; let patch = &mut self.patch; debug!("create_drop_flag({:?})", self.body.span); <del> self.drop_flags.entry(index).or_insert_with(|| patch.new_internal(tcx.types.bool, span)); </del> <ins> self.drop_flags[index].get_or_insert_with(|| patch.new_internal(tcx.types.bool, span)); </ins> } fn drop_flag(&mut self, index: MovePathIndex) -> Option<Place<'tcx>> { <del> self.drop_flags.get(&index).map(|t| Place::from(*t)) </del> <ins> self.drop_flags[index].map(Place::from) </ins> } /// create a patch that elaborates all drops in the input

Discussion:
This code creates MIR statements based on an iteration order: is defined as: Since FxHashMap's fixed seed is different between 32 and 64 bit platforms, we may end up creating statements in a different order on 32-bit vs 64-bit hosts (the target platform passed to the compiler has no effect). We should probably sort by before creating the statements.
Perhaps it should just use instead?
Revisiting this issue to evaluate the priority. unsure about the status and global direction of this issue. Do we have some work in progress somewhere? I've tried following the breadcrumbs and landed on . Unsure if it helps and - if yes - how much does that pull request covers to fix this issue. opinions? thanks :)
Change:
pub struct ZeroSize; pub type RustFn = fn(); pub type RustBadRet = extern fn() -> Box<u32>; <ins> pub type CVoidRet = (); </ins> extern { pub fn bare_type1(size: isize); //~ ERROR: found Rust type

Discussion:
made the lint trigger for tuples, but as far as I understand, returning is equivalent to returning cvoid, and therefore should be allowed. Here is an example:
Yes, stupid mistake; I'll fix it. (As a workaround, you can write .)
since was merged i'm closing
Change:
<ins> error[E0412]: cannot find type `V` in this scope --> $DIR/issue-112547.rs:8:4 | LL | }> V: IntoIterator |    ^ not found in this scope | help: you might be missing a type parameter | LL | pub fn bar<V>() |           +++ warning: the feature `non_lifetime_binders` is incomplete and may not be safe to use and/or cause compiler crashes --> $DIR/issue-112547.rs:1:12 | LL | #![feature(non_lifetime_binders)] |            ^^^^^^^^^^^^^^^^^^^^ | = note: see issue #108185 <https://github.com/rust-lang/rust/issues/108185> for more information = note: `#[warn(incomplete_features)]` on by default error: aborting due to previous error; 1 warning emitted For more information about this error, try `rustc --explain E0412`. </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 --
claim
Change:
checksum = "05499f3756671c15885fee9034446956fff3f243d6077b91e5767df161f766b3" dependencies = [ "hermit-abi", <del> "libc 0.2.112", </del> <ins> "libc", </ins> ] [[package]]

Discussion:
Running on s390x fails when attempting to build due to: This seems to be caused by a dependency on libc 0.1.12 from gccjit_sys. This version is very old (from about 2015), and does not yet support the s390x architecture at all. could this be updated to a more recent libc version? If so, would you like me to send a patch against ?
Yes, please!
Thanks for the quick merge! I see still fails for now, because the rust build still seems to pull in the commit of , probably because of the in . Will this be pulled forward automatically at some point, or do I need to submit another PR? (If so, against which repo?)
The fastest would be to update the in this repo (rust-lang/rust). I would appreciate if you submit a PR for this. Thanks!
I've updated the dependency to the current head commit and rebuilt. This automatically removed the libc 0.1 dependency from ; it is now using 0.2.112 (the version that was also already present in ) everywhere, which is fine for s390x.
With that PR applied, now passes on s390x.
Change:
let a = u.a; // OK let b = u.b; // OK <del> let c = u.c; //~ ERROR field `c` of struct `m::U` is private </del> <ins> let c = u.c; //~ ERROR field `c` of union `m::U` is private </ins> }

Discussion:
() Errors: Notice how it says "struct" when it should say "union". cc this looks like low-hanging fruit
Can I pick this up if no-one is working on this?
go ahead! You need to use here to get whether it is a struct or union using .
Thanks . Newbie question, but how do I test this while development? Do I build the stage1 compiler and then write a sample test?
is the way to get the fastest iteration time. is theoretically suspect but should affect you on what you're working on and is marginally slower on first compile but much faster on subsequent compiles. You rarely (if ever) need .
Change:
let filename = "tests/parser/stashed-diag.rs"; assert_parser_error(filename); } <ins> #[test] fn crate_parsing_stashed_diag2() { // See also https://github.com/rust-lang/rust/issues/121517 let filename = "tests/parser/stashed-diag2.rs"; assert_parser_error(filename); } </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
cc
Probably a duplicate of , and hopefully will be fixed by .
no, I checked, while is fixed, this one isn't :(
Change:
// who might care about this case, like coherence, should use // that function). if candidates.is_empty() { <ins> // If there's an error type, 'downgrade' our result from // `Err(Unimplemented)` to `Ok(None)`. This helps us avoid // emitting additional spurious errors, since we're guaranteed // to have emitted at least one. if stack.obligation.references_error() { debug!("no results for error type, treating as ambiguous"); return Ok(None); } </ins> return Err(Unimplemented); }

Discussion:
Does not appear on Stable or Beta in the playground. () Errors: modify labels: +C-bug, A-diagnostics, D-verbose, E-needs-bisection, T-compiler Edit: nevermind the attempt of adding “regression-from-stable-to-nightly”, I didn’t fully read the description of that label, it doesn’t apply.
Error: Label regression-from-stable-to-nightly can only be set by Rust team members Please let know if you're having trouble with this bot.
This can be reproduced outside the playground by adding to your . I suspect that this is caused by we now continue trait selection instead of bailing out when we see an error type. I think we'll want to re-add some kind of bail-out logic, but I'm not sure where the best place would be.
I can confirm regression at modify labels to -E-needs-bisection.
(This bug leaked into beta channel while waiting for PR to land, I think.)
Removing as this have been prioritized already.
This one is already on master and beta backported so closing it as fixed in both channels.
Change:
#[derive(Deserialize, Default)] #[serde(deny_unknown_fields, rename_all = "kebab-case")] struct Llvm { <ins> skip_rebuild: Option<bool>, </ins> optimize: Option<bool>, thin_lto: Option<bool>, release_debuginfo: Option<bool>,

Discussion:
The compiler LLVM is rebuilt whenever the built version of LLVM doesn't have the right hash. (Previously it was rebuilt based on a special marker file, which was easier to work around.) However, most of the time, having the latest LLVM version is not necessary, but makes rebuilding rustc after rebasing take significantly longer, which is a pain. It would be good to be able to disable this as an option in for convenience. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
To fix this, you'll want to add another option: you should be able to look at the logic for something like .
It would be good if this could be changed in the config file so you don't have to pass in the option all the time.
if it's a config file option, then there should be an option to rebuild it if necessary. I.e. it shouldn't be necessarily to temporarily change the to rebuild.
sure that seems good, although they can be implemented separately.
The line you would need to change is near this one: (line 735 of ) It would probably be much easier to add a check against a key in the config, than to add a new flag.
claim
Error: Parsing assign command in failed: claim ... Please let know if you're having trouble with this bot.
, my bad! claim EDIT: oh dear, I'm making it worse
are you still working on this? I wouldn't mind picking it up if not. (Sorry - not really sure what the etiquette is re: dormant tickets!)
Just saw that PR () lapsed. I'm gonna claim this, if that's okay. Will work on something based on the existing comments there. claim
Thank you for picking this up! Getting things fixed is the important thing, and I'm sure I'll find something else to fix in the near future when I have more time
Change:
E0180, E0181, E0182, <del> E0183 </del> <ins> E0183, E0184 </ins> }

Discussion:
Basically, it's now possible to write: and have everything work. This unfortunately means that doing something like with a will zero b, but not move it. /cc
I noticed this possibility too and was debating if this is a problem. It's not clear to me. Probably best to disallow it for now.
at the very least, it's causing incorrect behaviour at runtime, since it's zeroing out types like a move, but not forbidding the use of them like a copy.
Looks unsafe to me: Program received signal SIGSEGV, Segmentation fault. 0x0000555555598e5c in ()
I agree that combining it with zeroing is unsafe. If zeroing did not occur, or we did not zero for types that were copy, there wouldn't necessarily be a problem.
Anyhow, it's easiest to forbid it for now. We can always make it legal later if someone comes up with a persuasive use case. Idempotent destructors seem like a bit of an odd thing.
Change:
let ret_ty = self.inh.infcx.shallow_resolve(ret_ty); let ret_vid = match *ret_ty.kind() { ty::Infer(ty::TyVar(ret_vid)) => ret_vid, <ins> ty::Error(_) => return None, </ins> _ => span_bug!( self.tcx.def_span(expr_def_id), "async fn generator return type not an inference variable"

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</detailsNOTE: The bug is found by our work-in-progress compiler testing tool Kira, and the test program is reduced/minimized by <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Related to .
My hunch is that this code: needs to be generalized to also accept a . The function could just return (or maybe ) in that case and I expect the ICE would go away.
I'm tagging this as E-mentor because of the above instructions (feel free to also ping me on Zulip)
claim
Change:
_ => None, } } <ins> pub fn is_generic(&self) -> bool { match *self { ResolvedPath { is_generic, .. } => is_generic, _ => false, } } </ins> } impl GetDefId for Type {

Discussion:
has the implementation which is It is however , so rustdoc does the correct thing after doc inlining. This bug with blanket impls shows up in user's crates, ; for example the trait in itertools does not have its blanket impl visible in the docs.
It regressed on nightly, it also disappeard from the libstd page.
The regression is not due to specialization, see e.g. vs which does not use specialization. Regression is also visible on beta btw.
hmm, is this bug affecting me? , corresponding
Yes, it's the same bug.
thanks. a bit confusing, since that impl is the whole point of my crate :smile:
The regression was already fixed in
Change:
get_env_store().map(|env| clone_to_vec(&env.lock().unwrap())).unwrap_or_default().into_iter() } <del> pub fn getenv(k: &OsStr) -> io::Result<Option<OsString>> { Ok(get_env_store().and_then(|s| s.lock().unwrap().get(k).cloned())) </del> <ins> pub fn getenv(k: &OsStr) -> Option<OsString> { get_env_store().and_then(|s| s.lock().unwrap().get(k).cloned()) </ins> } pub fn setenv(k: &OsStr, v: &OsStr) -> io::Result<()> {

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 --
Simplified. The other malformed-looking bytes don't matter, do they?
You are right, they don't. I should have simplified it before submit.
Going to have a go at this. If I can't figure it out, I'll either ask for help or unassign myself. claim
Still working on this, but I figured an update may be helpful. My research indicates that the two characters that are potentially problematic are and . The work that needs to be done consists of 1) updating the macro expansion functions in to error in these cases; and 2) updating the macro documentation in to mention the new errors. Edit: It just occurred to me that I also need to add UI tests. Haven't figured out where to do that yet, but I will.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
I don't think just adding a check to raise error in these cases would be enough. The function shouldn't really panic (from the internals discussion). Another problem is when the OS supports this kind of environment variable. e.g. as key. would deny it while it can be valid i.e. a false positive. You should still keep your work though (and eventually open a PR) as this must be changes to which would take a while.
If this is going to be fixed upstream in in even the mid-term future, I'm not sure fixing it here makes sense. Sure, it generates an ICE, but the ICE has an unusually helpful error message.
Actually, simple solution: I'll do the fix.

Working on that now.
Was this fuzzer output? If so, which fuzzer were you using
Yes, I am using kira, a work-in-progress fuzzing tool
Have you considered sorry using structure-aware fuzzing? That could help find bugs not just in the lexer and parser, but also in the middle and back ends.
Yes, actually kira is structure-aware.