jiebi/CodeConvo huggingface dataset:
Change:
#[prelude_import] use std::prelude::v1::*; #[macro_use] <del> extern crate std as std; </del> <ins> extern crate std; </ins> // Copyright 2017 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT.

Discussion:
Since the check no longer panics on failure. It is obvious in the commit that the invocation is removed from the check, and no other changes are made in the function to remedy it. It can be verified by adding a new pretty test case like: The resulting pretty printed file is slightly different, the comparison fails and the message is logged, but the test continues into the type check, which fails for a different reason and then panics. If you fix the type check (by adding the module and fn main) then the whole test passes and the error message is swallowed even though the source comparison is still not matching.
Change:
tracked!(emit_thin_lto, false); tracked!(export_executable_symbols, true); tracked!(fewer_names, Some(true)); <ins> tracked!(fixed_x18, true); </ins> tracked!(flatten_format_args, false); tracked!(force_unstable_if_unmarked, true); tracked!(fuel, Some(("abc".to_string(), 99)));

Discussion:
On the target, specifying the target feature using the flag results in the following warning: The desired effect of this flag is to reserve the x18 register so that LLVM does not use it during codegen. Note that despite the warning, the flag still works fine today since it is passed on to LLVM. This feature is necessary for Rust to work when using the Linux Kernel's dynamic shadow call stack feature on aarch64 (). The shadow call stack feature requires that the x18 register is reserved, since it is used to store the shadow stack. In C code, the dynamic version of shadow call stack requires you to pass but not (which is only used for non-dynamic SCS). Clang has a collection of flags for reserving other registers than x18 as well. I think it would make sense to add those as well, even if they are less useful than x18. Related to . Related to .
This affects the ABI, right? I think adding a target spec option makes the most sense (or actually you can already set it as target feature in the target spec without giving a warning). That way you can't enable or disable it for individual functions or crates, which would break the ABI.
Yeah, it would be nice to have a flag for this (or having something like "global target features", i.e. like , but that it ensures it is set the same way for all compilation units).
There could be ABI concerns with this in general. AAPCS64 defines x18 as a platform register if required, or temporary if a platform register isn't needed. For x18 it's probably unlikely for it to have ABI concerns as it's already reserved for use on some platforms, the ones where it's not already reserved, it's only supposed to be a temporary register so not using it should be OK as it is not used for any fixed purpose. That's obviously assuming a platform defines its ABI based on the Arm standards. LLVM does support reserve on other registers, most notably for ABI reasons, x1 through x7 which would have ABI problems. LLVM does have test cases to ensure that a function call doesn't occur if any of the argument registers have been reserved. I'm not sure what other codegen backends do in that case though, or if they even support reserving those registers.

The analysis that LLVM does, doesn't seem to care if it would need to use that register for ABI reasons, even a function such as can't be called in a quick test. Using target features for this feels strange to me though, I'm wondering if a codegen option to reserve certain registers would be a better approach here. While this issue is specifically about reserving a register on AArch64, LLVM does support this for multiple other architectures and multiple registers, which we should maybe consider for the future.
Change:
assert_eq!(self.elaborator.param_env().reveal(), Reveal::All); let field_ty = tcx.normalize_erasing_regions(self.elaborator.param_env(), f.ty(tcx, substs)); (tcx.mk_place_field(base_place, field, field_ty), subpath) }) .collect()

Discussion:
I found this ICE while compiling in release mode. : <details<summary<strongBacktrace</strong</summary<p</p</detailsbisect command: bisect result: Regression in
uuh cc
For repro:
You're right that this ICEs after my PR but not before, but this looks like an issue related to type system code or , not MIR inlining itself, so I don't think I can't help here.
Ah so it would have iced before if we had forced inlining before?
Yes, with enough application of this code should ICE before that PR. I couldn't tell you where to apply the attribute though, just squinting at the ICE message it looks like this is significant, though I don't know enough to track down where that closure is.
Is there some rustc flag I can use to force inlining of like ~ everything ~ for testing purposes? :eyes: edit: -Zinline-mir-threshold=0 or something like that? :D
You need to set both thresholds, and I don't think we have a magic value for "always", just use a big number. The defaults are 50 and 100 I think. Also just FYI there's also an inlining depth limit that's not configurable, but it shouldn't be relevant for this PR. But if you see unexpected missed inlinings even with passing those flags, that threshold might be why.
Oh, those flags won't help you before the PR in question, because functions without are simply not considered for inlining at all, no matter their size. Fixing this odd ignoring of size was the whole point of that PR. You can pass to lift that "must have " requirement, but of course that turns on other passes, but the check you're trying to dodge is an explicit check for the MIR opt level inside the Inline pass so... yeah just you might also hit other bugs. You could try turning off the passes that are enabled at mir-opt-level=3 but that would be messy.

The mir opt level is cranked up already anyway Maybe I can find some snippet that somehow reassembles what we are seeing here :) I'll be able to report back in an hour or so I guess ^^
Meh besides a couple more "hangs" (process timeouts) nothing new in the standard rustc test set :/
This is a dupe of I believe
Another reproducer (possibly large): Run in , with rustc 1.71.0-nightly ( 2023-04-29) running on x86_64-unknown-linux-gnu. Failing CI log:
I've been getting this too since about a month ago: I can do a bisect.
Change:
<ins> #![feature(type_alias_impl_trait)] use std::fmt::Display; type Opaque<X> = impl Sized + 'static; fn define<X>() -> Opaque<X> {} trait Trait { type Assoc: Display; } impl<'a> Trait for Opaque<&'a str> { //~^ ERROR the lifetime parameter `'a` is not constrained by the impl trait, self type, or predicates type Assoc = &'a str; } // ======= Exploit ======= fn extend<T: Trait + 'static>(s: T::Assoc) -> Box<dyn Display> { Box::new(s) } fn main() { let val = extend::<Opaque<&'_ str>>(&String::from("blah blah blah")); println!("{}", val); } </ins>

Discussion:
The following UB compiles: The impl is invalid because the lifetime parameter appears unconstrained in the impl header. It should be rejected for the same reason that projection types doesn't constraint impl generics: label C-bug T-types I-unsound requires-nightly F-typealiasimpl_trait
Change:
* other tasks wishing to access the data will block until the closure * finishes running. * <del> * The reason this function is 'unsafe' is because it is possible to * construct a circular reference among multiple Arcs by mutating the * underlying data. This creates potential for deadlock, but worse, this * will guarantee a memory leak of all involved Arcs. Using MutexArcs * inside of other Arcs is safe in absence of circular references. * </del> * If you wish to nest MutexArcs, one strategy for ensuring safety at * runtime is to add a "nesting level counter" inside the stored data, and * when traversing the arcs, assert that they monotonically decrease.

Discussion:
contains two sets of methods to access the Arc's wrapped object. and are tagged unsafe as "it is possible to construct a circular reference among multiple Arcs by mutating the underlying data. This creates potential for deadlock, but worse, this will guarantee a memory leak of all involved Arcs." There are also and methods defined when the inner type is freezable as that guarantees the type can't contain a . However, it's still trivially easy to deadlock using the safe methods: It seems that the consensus in was that possibility of deadlock is inherently unsafe, so should and be removed? cc
Perhaps access should fail when it is called by the same task twice? It would be nice if people didn't have to use unsafe blocks just to get normal stuff done.
Nested locks in the same task aren't the only way you can run into deadlock:
I am aware of that, but it seems to me this particular error would be easy and cheap to catch, so if we aren't doing that yet, we probably should. Personally I don't think the possibility of a deadlock should require an unsafe block.
Consensus in the past has been that deadlock is not unsafe (). You can deadlock with pipes too, with just two lines of code. The non- accessors for are unsafe for a totally different reason, which is documented in . Regarding "cheap and easy to catch" - I don't believe we should try to fail in the single-task deadlock case unless we can reliably fail in all deadlock cases (which is not out of the question but requires scheduler support, see ). A user who is used to seeing a failure message from their previous attempts which had deadlocked would be all the more confused when they find their cross-task deadlocking code does not fail.
Is the possibility of memory leakage really considered unsafe? doesn't seem to share that assumption, but I may be missing something there.
Neither or provides a way to leak memory via the safe constructors.
We currently don't officially consider leaks to be , but I think leaking past the lifetime of tasks with references is a very questionable thing to allow.
The box annihilator is not a good solution to rc reference cycles, but it is at least a solution. Cycles of MutexArcs will produce valgrind errors.
now provides a way to leak with the safe constructors.
Change:
fn foo(x: impl Fn(<S as T<'_>>::A) -> <S as T<'_>>::A) {} //~^ ERROR binding for associated type `Output` references an anonymous lifetime <del> //~^^ NOTE lifetimes appearing in an associated type are not considered constrained </del> <ins> //~| NOTE lifetimes appearing in an associated or opaque type are not considered constrained //~| NOTE consider introducing a named lifetime parameter </ins> fn main() {}

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. --. Prior to , these types were rejected with this error: Currently, they're accepted. Based on the assumption that generic parameters on opaque type are not constrained (see Niko's comment ), I believe the previous behavior is correct. CC: label F-typealiasimpl_trait A-impl-trait T-compiler A-lifetimes
Out of curiosity, here's an exploit derived from . It type-checks but fails at monomorphization.
The above exploit is and should be easier to do with , where indirection through would not be necessary, so label I-unsound requires-nightly T-types
if the same code were written without lifetime params and used arguments instead, we'd see the same problem before , right?
Sorry, I've clearly missed the notification :sweat_smile:. I think you already know the answer given that you've just pushed a fix :).
Change:
use std::borrow::Cow; use std::collections::HashSet; use std::env; <ins> use std::ffi::OsStr; </ins> use std::fs; use std::io::prelude::*; use std::io::BufReader;

Discussion:
cc I tried this: I expected to see this happen: The tests pass. Instead, this happened: The tests fail: These tests are pretty complicated but the error message looks correct: I'm not sure why both files are there and particularly why they have different hashes. shows that is being downloaded from CI, and I guess the is coming from somewhere - maybe we should clear the directory before doing that? <!-- 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. --HEAD is <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Ok, it turns out both versions are coming from CI: I am ... surprised this hasn't broken anything else? I don't know why only this specific test would be failing.
The difference between this test and others is that somehow in other tests knows ahead of time which hash it should use: for the allocator tests, it doesn't know, and gives an ambiguity error:
ok, here's a minimal reproducer: I think what's going on is for the working tests, the implicit injected by the compiler also loads libc, because std depends on libc: Then, when the compiler sees , it's already seen the version depends on and resolves the ambiguity by reusing that crate. But for the failing test, we never load std, so we don't have a pre-existing hash to default to, so it gives a hard ambiguity error.
Change:
#[cfg(target_os = "xous")] pub mod xous; <del> #[cfg(any(unix, target_os = "wasi", doc))] </del> <ins> #[cfg(any(unix, target_os = "hermit", target_os = "wasi", doc))] </ins> pub mod fd; #[cfg(any(target_os = "linux", target_os = "android", doc))]

Discussion:
I tried this code: With . I expected to see this happen: code to compile Instead, this happened: failed to compile with Looking at the relevant code: It seems is imply missed from the . Inside of the module there is already code for hermit: I think this is just an oversight, but I since I don't develop for Hermit I'm not sure. (I hit this while updating Mio) /cc :
label -needs-triage +O-hermit +A-cross +T-libs
I agree, the module is missing. I will create a PR.
Change:
<ins> // A bare `...` represents `CVarArgs` (`VaListImpl<'_>`) in function argument type // position without being a proper type syntactically. // This test ensures that we do not regress certain MBE calls would we ever promote // `...` to a proper type syntactically. //@ check-pass macro_rules! ck { ($ty:ty) => { compile_error!(""); }; (...) => {}; } ck!(...); fn main() {} </ins>

Discussion:
<!-- [31mICE[0m: Rustc '-Zunstable-options --edition=2024 -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: should have been handled elsewhere', 'error: internal compiler error: should have been handled elsewhere' File: --auto-reduced (treereduce-rust): 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: --
also repros with or with 2015 if you remove the :)
Regression in nightly-2020-12-20 fetching (via remote github) commits from max(, 2020-12-17) to ending github query because we found starting sha: getcommitsbetween returning commits, len: 9 commit[0] 2020-12-18: Auto merge of - ehuss:update-cargo, r=Mark-Simulacrum commit[1] 2020-12-18: Auto merge of - GuillaumeGomez:str-to-symbol, r=jyn514 commit[2] 2020-12-19: Auto merge of - mibac138:fn-fat-arrow-return, r=davidtwco commit[3] 2020-12-19: Auto merge of - davidtwco:issue--const-param-attrs, r=lcnr commit[4] 2020-12-19: Auto merge of - JohnTitor:rollup-a31s996, r=JohnTitor commit[5] 2020-12-19: Auto merge of - jackh726:binder-refactor-part-2, r=lcnr commit[6] 2020-12-19: Auto merge of - CDirkx:ipaddr-const, r=oli-obk commit[7] 2020-12-19: Auto merge of - matthewjasper:revert-eval-order, r=nikomatsakis commit[8] 2020-12-19: Auto merge of - Nadrieril:usefulness-merging, r=varkor
This is also kinda bad because rustc does not tell you what you did wrong (theres no error shown) mvce:
very likely
Change:
return false; } // Try to find predicates on *generic params* that would allow copying `ty` <del> let suggestion = </del> <ins> let mut suggestion = </ins> if let Some(symbol) = tcx.hir().maybe_get_struct_pattern_shorthand_field(expr) { format!(": {symbol}.clone()") } else {

Discussion:
Cloning the pointer doesn't make sense in that situation and would cause a type mismatch error. I'm not sure whether any of the two current suggestions should be kept or removed in this case. No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Note that this works: It works because is a place expression and then we attach to that, which then reborrows the String. I don't think we should suggest , which may have undesirable or unexpected effects in the case of things like types that handle backing buffers, instead of issuing a safe which will recreate the backing allocation correctly.
I didn't know that was possible, thanks for letting me know. I guess that the best approach would then be to change the suggestion accordingly as below?
Correct. Also, we could mention in the error for pointers, but we shouldn't recommend it. It's unsafe code, we should strive to preserve the "you break it, you buy it" / "do your own research" experience for that.
The relevant section of diagnostic code is here but it will require some restructuring to account for the fact that the suggestion will not be doing things like stripping parentheses, but suggesting adding them if they don't exist.
claim It looks good for me to make a try.
Change:
let ty::CrateAnalysis { export_map, reachable, name, .. } = analysis; let exported_symbols = find_exported_symbols(tcx, reachable); <del> let check_overflow = if let Some(v) = tcx.sess.opts.debugging_opts.force_overflow_checks { v } else { tcx.sess.opts.debug_assertions }; </del> <ins> let check_overflow = tcx.sess.overflow_checks(); </ins> let link_meta = link::build_link_meta(incremental_hashes_map, &name);

Discussion:
Tracking issue for
FWIW this should be a relatively easy bug to knock out! The option is and we'd just want to add a new flag to the (we'll delete the flag once everyone's migrated). There's a few uses throughout the codebase which I believe will need an update:    After that we'd just need to add a test which validates this behavior, likely a addition with a annotation at the top. Likewise the Cargo support should be relatively easy:
I'd like to tackle this!
OK, so this is pretty straightforward. Couple questions after actually implementing this: The RFC says the option is , but comments on the RFC suggest that people expect this to be , so one could have (I guess) . Which variant should be supported? It seems better to make the value in the single source of truth to be used throughout the compiler by setting it based on the value of or ; this makes the uses easier to read and also makes any future removal of straightforward. How should interact with ? Should we just consider any explicit setting of to "win" and only consult if the option was not explicitly provided? I guess that would mean that we'd almost have to implement the variant above?
I think it's fine to just reuse the existing  which accepts a "standard variety" of boolean options. Makes sense to me to have a single source of truth! Right now I don't think we have a lot of precedent for modifying after creation so this may not be easy. Perhaps a helper method on though? That's what a . Yeah let's just have trump . The precise semantics likely don't matter too much anyway as we'll quickly phase out the version anyway.
Change:
use cmp; use fmt; use iter_private::TrustedRandomAccess; <del> use ops::{self, Try}; </del> <ins> use ops::Try; </ins> use usize; use intrinsics; <del> use mem; </del> #[stable(feature = "rust1", since = "1.0.0")] pub use self::iterator::Iterator;

Discussion:
The following snippet demonstrates the problem: It prints: I expect second iterator to produce the same result as for the third one.
Regression from 1.28.0 to 1.29.0. Introduced in
The problem is interaction between and . ignores the inner working of StepBy. Test-case reduced to using without .
From a cursory look, it seems to me that the problem is that and are out of sync. StepBy specifically allows for the underlying iterator, either or . If both and follow the same one, the bug shouldn't occur. In other words, if is specialized and overrides the default, then needs to be specialized as well.
Change:
<del> Subproject commit 7907abea272bbf97812683ce03a1ab9c22f0557b </del> <ins> Subproject commit d342cee78703c46d9df09088f9fb99ba85d021ae </ins>

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool clippy-driver 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! And nominating for compiler team prioritization.
Change:
} } <ins> // no-op on the last index { let mut m = DList::new(); m.push_back(1); let p = m.split_off(1); assert_eq!(m.len(), 1); assert_eq!(p.len(), 0); assert_eq!(m.back(), Some(&1)); assert_eq!(m.front(), Some(&1)); } </ins> } #[test]

Discussion:
Currently, requires its argument to be strictly less than the length of the list, which means the following function panics when passed a one-element list. Instead, it should leave the original list unmodified and return an empty list: In contrast, does allow as a valid argument, so the above code works as desired if you replace DList with Vec.
Vec was actually like this until a few days ago when I happened to notice it and change the check. I must've mis-specified it in the RFC, or this went viral from the first mis-write.