jiebi/CodeConvo huggingface dataset:
Change:
for sibling in files_under_inspection.iter().filter(|f| { f.extension().map(OsStr::to_str).flatten().is_some_and(|ext| EXTENSIONS.contains(&ext)) }) { <del> let filename_components = sibling.to_str().unwrap().split('.').collect::<Vec<_>>(); let file_prefix = filename_components[0]; </del> <ins> let Some(filename) = sibling.file_name().map(OsStr::to_str).flatten() else { continue; }; let filename_components = filename.split('.').collect::<Vec<_>>(); let [file_prefix, ..] = &filename_components[..] else { continue; }; </ins> <del> let Some((test_path, expected_revisions)) = test_info.get(file_prefix) else { </del> <ins> let Some((test_path, expected_revisions)) = test_info.get(*file_prefix) else { </ins> continue; }; <del> match filename_components[..] { </del> <ins> match &filename_components[..] { </ins> // Cannot have a revision component, skip. [] | [_] => return, [_, _] if !expected_revisions.is_empty() => {

Discussion:
Running on my checkout with the current master commit fails with tons of errors. here's the last few screens of messages:
Is the check looking for in the full path? My rustc checkout is in a directory called (it's my 2nd of 3 checkouts), and I suspect tidy gets confused by that.
It does CC
That code should probably use .
Oops, I will try to fix this ASAP
Submitted a fix for this at .
Change:
<ins> // #84044: This used to ICE. fn main() { let f = || {}; drop(&mut f); //~ ERROR cannot borrow `f` as mutable, as it is not declared as mutable } </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. --I'm a complete Rust newbie and most of the time I have no idea of what I'm doing. So my source code is probably completely weird and fcked up by the standards of a seasoned Rust developer. Still, I don't think my compiler should be panicking :) Also please note that the source code is definitely not even supposed to compile, it DOES* have a number of syntax errors, however, I would expect a reasonable error message explaining what I'm doing wrong. Big thanks to who has minimized the code to a very simple test case that crashes the compiler: I also found several similar bugs reported but I'm still not sure if this is a duplicate or not. Similar bug reports: To reproduce: The bug does exist in the current nightly build. : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Minimized: () Note: I used for reducing most of the unneeded code, and to put everything in one big file.
Thanks for doing that, I'll edit my original post to link to your reply to see a code example. P.S. I did open the code reduction tools you linked, but I still am not sure how you got to this minimized state, great job :D
Triage: It now returns some compiler errors and is no longer ICE, fixed by , I guess. Marking as .
Just in case, if you could check your code with the latest nightly, it'd be great.
Indeed, tested with the latest nightly this produces various compiler errors and no ICE. Thank you!

<!-- 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
No longer ICEs since

I get the following ICE with 1.51.0 stable (but not on nightly). The ICE can currently be reproduced on the [playground]. [playground]: (_%3A%20%26mut%20F)%0Awhere%0A%20%20%20%20F%3A%20FnMut()%2C%0A%7B%0A%7D%0A%0Afn%20main()%20%7B%0A%20%20%20%20let%20f%20%3D%20%7C%7C%20%7B%7D%3B%0A%20%20%20%20foo(%26mut%20f)%3B%0A%7D%0A <!-- 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. --: <details<summary<strongBacktrace</strong</summary<p</p</details
Even simpler: [playground]. [playground]: ()%20%7B%0A%20%20%20%20let%20f%20%3D%20%7C%7C%20%7B%7D%3B%0A%20%20%20%20drop(%26mut%20f)%3B%0A%7D%0A
This ICE also does not happen in the 1.52 beta.
Does not seem to ICE modify labels: E-needs-test
Change:
err.help("unsized locals are gated as an unstable feature"); } } <del> ObligationCauseCode::SizedArgumentType(sp) => { if let Some(span) = sp { </del> <ins> ObligationCauseCode::SizedArgumentType(ty_span) => { if let Some(span) = ty_span { </ins> if let ty::PredicateKind::Clause(clause) = predicate.kind().skip_binder() && let ty::Clause::Trait(trait_pred) = clause && let ty::Dynamic(..) = trait_pred.self_ty().kind()

Discussion:
Notice how the last 2 suggestions aren't valid in such a closure: The suggestions given in should help me get closer to fixing the error, or at least not have invalid syntax. No response No response Output of :
(if is used in the snippet, comes up again with leaking implementation details)
Change:
(sys_now.tv_usec * 1000) as libc::c_long; let extra = (nsec / 1_000_000_000) as libc::time_t; let nsec = nsec % 1_000_000_000; <del> let seconds = dur.as_secs() as libc::time_t; </del> <ins> let seconds = saturating_cast_to_time_t(dur.as_secs()); </ins> let timeout = sys_now.tv_sec.checked_add(extra).and_then(|s| { s.checked_add(seconds)

Discussion:
I have encountered what I think is unexpected behavior from on OSX: when called with "large" values the call will return immediately, instead of waiting for an call. What constitutes "large" is variable, and appears to correspond to the current value in the system monotonic clock source. The following code reproduces the issue: If you run the code above with the "small" value uncommented the internal loop only runs once, waiting for the 1-second sleep to expire before is called. But if you run with the "large" value uncommented, the internal loop runs a very large number of times as each call to returns almost immediately. As noted above, the actual value of "large" decreases over time, I believe based on . I unfortunately couldn't come up with a way to prove this is the case. I've seen this behavior on OSX Yosemite and Sierra. Edit: this happens on 1.11, 1.12, beta, and nightly.
This is likely related to the implementation using unchecked arithmetic and something overflowing. I'll tweak it to much Linux and test out to make sure it works.
Hm no that's correctly handling overflow... Hmm...
Fixed by
Change:
|     | |     required by a bound introduced by this call | <del> = note: consider using `Box::pin` </del> <ins> = note: consider using the `pin!` macro consider using `Box::pin` if you need to access the pinned value outside of the current scope </ins> note: required by a bound in `Pin::<P>::new` --> $SRC_DIR/core/src/pin.rs:LL:COL

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:
/// /// let os_str = OsStr::new("foo"); /// ``` <ins> #[inline] </ins> #[stable(feature = "rust1", since = "1.0.0")] pub fn new<S: AsRef<OsStr> + ?Sized>(s: &S) -> &OsStr { s.as_ref() } <ins> #[inline] </ins> fn from_inner(inner: &Slice) -> &OsStr { unsafe { &*(inner as *const Slice as *const OsStr) } }

Discussion:
Godbolt link: I expect these two snippets have the same optimized asm but they don't:
I think the bigger problem here is that the quite trivial AsRef and PartialEq implementations did not get inlined. I would not expect anything to optimize well without those getting inlined.
I'm not sure we can expect these two to give you the same assembly. They are actually a bit different -- the first one will construct conditionally ( will call the closure only for ), whereas the second one will create the unconditionally before even checking if the parameter is or . As for the differences in the assembly wrt. comparisons themselves, this seems to be due to the difference between the code to check for equality of vs . I wonder, do you have a particular benchmark/workload where the first function is slower than expected?
Still, if I change the first snippet like below, [the asm][1] is different too: [1]:
is effectively a pointer cast, so it is warranted to expect assembly of at least similar quality. Inlining does not happen because we do happen to have generated machine code for these trivial functions in Tacking some s should suffice?
After inlining some methods in , I got the same asm between those two snippets:
Change:
<del> Subproject commit e05a543f74dbdd0580b2bd35ddb7f8e144d9edda </del> <ins> Subproject commit c6b3f687d5d9917b626f80a730552a185052ff28 </ins>

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. 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!
Ah, now division needs : in the docs it says this is equivalent -- so, both and need to be fully initialized? That's different from the LLVM operation so I am slightly surprised. (OTOH this intrinsic is by-value and its type would not allow uninit data anyway so I guess the question is somewhat moot.)
Whoops. Yes, that's the intent, it's also called a "blend" in SIMD jargon. It not having much in common is due to it merely having a shared name from outside the LLVM terminology.
I don't think it strictly has to have both being init, though... for this purpose, it is sufficient to assume that the stated equivalence holds in the case of uninit data only if both sides are also considered implicitly frozen by this operation. One of the purposes IS to allow composing a partially initialized vector with another that fills in the blanks in order to get a fully initialized vector. The important detail is that the operation is fully branchless: it may be valid to execute it using branches, but it does not need any to complete.
Well, it is still quite relevant whether calling the intrinsic with uninit data in a "dead" element is UB or not. But for now I will simply make it UB, and then if that is ever a problem we can see what we want to do.
It should not be, though I think that the resulting vector from a should always be fully initialized as a postcondition, which means it may be UB if both sides of a selection are uninitialized data (and the mask itself has to be initialized). We don't have MaybeUninit vectors yet though.
In that case, at least on the LLVM side, equivalence with does not hold -- under that equivalence, if any input is , the output will be . That seems like an odd requirement, what would motivate this? Definitely. Yeah so in a sense the discussion is rather moot currently and maybe I shouldn't have started it. (But by default Miri does not check integer initialization, so this still makes a difference for that case.)

Because ultimately, is "really" trying to be And there's a suite of separately-defined LLVM intrinsics... the intrinsics... that we will probably introduce Rust equivalents of if we get around to working with MaybeUninit vectors. And all of those will probably use or something in their nomenclature.
I don't understand how that motivates introducing UB when "forwarding" uninit data. I expected the type of with to be something like . Such an intrinsic could even be safe to call, but requiring the "selected" values to be initialized would prevent that, and I do not understand the benefit of that.
Hmm, perhaps you are right then.
Change:
Linkchecker, "src/tools/linkchecker", "linkchecker", Mode::Libstd; CargoTest, "src/tools/cargotest", "cargotest", Mode::Libstd; Compiletest, "src/tools/compiletest", "compiletest", Mode::Libtest; <del> BuildManifest, "src/tools/build-manifest", "build-manifest", Mode::Librustc; </del> <ins> BuildManifest, "src/tools/build-manifest", "build-manifest", Mode::Libstd; </ins> RemoteTestClient, "src/tools/remote-test-client", "remote-test-client", Mode::Libstd; RustInstaller, "src/tools/rust-installer", "rust-installer", Mode::Libstd; );

Discussion:
This is what rust-central-station does when making a release, it shouldn't need to build anything other than libstd!
cc
Change:
// Execution might have wandered off into other crates, so we cannot do a stability- // sensitive check here.  But we can at least rule out functions that are not const // at all. <del> if ecx.tcx.is_const_fn_raw(def.did) { // If this function is a `const fn` then under certain circumstances we // can evaluate call via the query system, thus memoizing all future calls. if ecx.try_eval_const_fn_call(instance, ret, args)? { return Ok(None); } } else { </del> <ins> if !ecx.tcx.is_const_fn_raw(def.did) { </ins> // Some functions we support even if they are non-const -- but avoid testing // that for const fn! ecx.hook_panic_fn(instance, args)?;

Discussion:
Since , memoization of argumentless functions is restricted to intrinsics, because other functions could perform heap allocations and thus memoization would be incorrect. I doubt we have any argumentless intrinsic that is expensive enough that memoization is worth it, so I propose we remove the leftovers of that infrastructure. Cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I want to work on this but i never contributed to rust-lang before so i need some guidance.
Great! So... step 0 is to write as a comment here, this will make sure the issue is assigned to you and noone else tries to tackle it at the same time. The main change is to remove this function: entirely without a replacement. You'll then have to adjust the call site to act as if the function returned . This may allow some small cleanups at the call site; I expect nothing major to happen there. I do not think there will be further test changes due to this, so, should run through without any failures. If it doesn't, still open a PR and let us know of your findings.
claim
Change:
<ins> error: unknown start of token: ` --> $DIR/issue-94171.rs:2:5 | LL | (; {` |     ^ | help: Unicode character '`' (Grave Accent) looks like ''' (Single Quote), but it is not | LL | (; {' |     ~ error: mismatched closing delimiter: `]` --> $DIR/issue-94171.rs:1:5 | LL | fn L(]{match |     ^^ mismatched closing delimiter |     | |     unclosed delimiter error: this file contains an unclosed delimiter --> $DIR/issue-94171.rs:5:52 | LL | fn L(]{match |      -- unclosed delimiter |      | |      missing open `[` for this delimiter LL | (; {` | -  - unclosed delimiter | | | unclosed delimiter ... LL | |                                                    ^ error: aborting due to 3 previous errors </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. --code is from clippy: :warning: you need rustc build with debug assertions :warning: <!-- 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
Run into this while fuzzing, here is a minimized test case: Note that you need rustc with debug assertions enabled. Reproduced in nightly 2022-02-25.
Another test case:
OP and seem to be fixed on latest master (). now outputs "Span must not be empty and have no suggestion" <details<summarybacktrace</summary</details
I can confirm that both of my examples have been fixed on latest master () so this issue can be closed.
Change:
condition: and(succeeded(), eq(variables['Agent.OS'], 'Windows_NT')) displayName: Check out submodules (Windows) <ins> # See also the disable for autocrlf above, this just checks that it worked # # We check both in rust-lang/rust and in a submodule to make sure both are # accurate. Submodules are checked out significantly later than the main # repository in this script, so settings can (and do!) change between then. # # Linux (and maybe macOS) builders don't currently have dos2unix so just only # run this step on Windows. - bash: | set -x # print out the git configuration so we can better investigate failures in # the following git config --list --show-origin dos2unix -ih Cargo.lock src/tools/rust-installer/install-template.sh endings=$(dos2unix -ic Cargo.lock src/tools/rust-installer/install-template.sh) # if endings has non-zero length, error out if [ -n "$endings" ]; then exit 1 ; fi condition: and(succeeded(), eq(variables['Agent.OS'], 'Windows_NT')) displayName: Verify line endings are LF </ins> # Ensure the `aws` CLI is installed so we can deploy later on, cache docker # images, etc. - bash: |

Discussion:
Since the change from travis to azure pipelines some of the rust-std archives have DOS line endings in their script, which results in errors like the following when trying to execute: Running works around the issue for now. Not all archives have this issue. Specifically does. Possibly others as well, but our install process fails after the first error, so I am not sure. See mattgodbolt/compiler-explorer-image and mattgodbolt/compiler-explorer-image
Thanks for reporting this! A tentative fix for this landed in , hopefully tomorrow's nightlies will be fixed.
Still happening on :/
Oh, this is concerning, we'll need to look into it a bit more. Thanks for the update. modify labels: regression-from-stable-to-beta -regression-from-stable-to-nightly
May have been actually .. Double checking.
is also affected, does that mean src is now generated from Windows or this is broken even more than it seems?
This is caused by the Azure migration, as it started happening right after we switched nightlies production to it. The initial hypothesis was that git's on Windows was the culprit, but that landed days ago so we need to look deeper :/
The source tarball is generated by all the dist builders and uploaded each time, so the last dist builder to finish will be the one producing the final tarball. I think we see the error there just because our slower builders are all Windows at the moment.
Assigning myself to investigate in the next few days.
Relevant: https://git-
The fix should've landed in today's nightly. Thanks everyone for reporting this!
Just a note, you might want to spin up a beta build as well. was affected by this as well.
yes, beta is still not fixed. The fix was nominated for beta backport though, so once the team approves we will backport it to the beta branch.
We backported the change!
Change:
{ let mut found = |what| { msg = format!( <del> "expected {}, found {} `{}` in `{}`", </del> <ins> "expected {}, found {} `{}` in {}", </ins> ns.descr(), what, ident, <del> path[i - 1].ident </del> <ins> parent </ins> ) }; if binding.module().is_some() {

Discussion:
Test program: This produces the following error messages: Both the error and the help seem entirely unhelpful. The error suggests that it looked for a function in the crate root, but in fact it looked for a crate . The whole "possible candidate" help seems incorrect, and adding that line would lead to a compilation failure.
cc
This is still an issue, but at least the incorrect help message is no longer displayed:
Change:
/// this interface is safe, it's not used outside this module. struct RawBuckets<'a, K, V> { raw: RawBucket<K, V>, <del> hashes_end: *mut u64 </del> <ins> hashes_end: *mut u64, marker: marker::ContravariantLifetime<'a>, </ins> } impl<'a, K, V> Iterator<RawBucket<K, V>> for RawBuckets<'a, K, V> {

Discussion:
Sorry, I'm not sure how to describe this very well in a sentence. I am able to mutably borrow the innermost values of a , delete the values, then reference them after they were deleted. This code compiles, runs, and barfs out strange numbers.
Little bit shorter example, without mutable borrows. But still fails to freeze :
nominating for 1.0 P-backcompat-lang
though this may be a library issue
weird This code is also valid: This is because the hashmap iterator just wraps the rawtable iterator, which just defers to the RawBuckets iterator, which is just a wrapper around two *mut's. That is, literally none of these iterators actually borrows the hashmap. Presumably this is fixable by taking a useless reference somewhere. The other thing I'm seeing is that there's , but the signature for Hashmap's iterator function is . How is this lifetime being elided? Is it doing the same thing as , or is something else happening? CC
Yep, it's eliding !
So there's two bugs here: the iterator doesn't borrow the map, and the references are being yielded as .
Assigning P-backcompat-libs, 1.0
thanks for fixing this! Great job!
Change:
// These items live in the type namespace. ItemTy(..) => { <del> let parent_link = ModuleParentLink(parent, name); </del> let def = Def::TyAlias(self.ast_map.local_def_id(item.id)); <del> let module = self.new_module(parent_link, Some(def), false, is_public); self.define(parent, name, TypeNS, (module, sp)); </del> <ins> self.define(parent, name, TypeNS, (def, sp, modifiers)); </ins> parent }

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