jiebi/CodeConvo huggingface dataset:
Change:
/// Returns the source snippet as `String` before the given `Span` pub fn span_to_prev_source(&self, sp: Span) -> Result<String, SpanSnippetError> { <del> self.span_to_source(sp, |src, start_index, _| src[..start_index].to_string()) </del> <ins> self.span_to_source(sp, |src, start_index, _| src.get(..start_index) .map(|s| s.to_string()) .ok_or_else(|| SpanSnippetError::IllFormedSpan(sp))) </ins> } /// Extend the given `Span` to just after the previous occurrence of `c`. Return the same span

Discussion:
When I used the character in comment, combined with some (invalid) code preceding it, the compiler panicked. I tried this code: I expected to see this happen: rustc compiles this code. Instead, this happened: rustc panicked with the following output : Backtrace:
Regressed in 1.34.0. Used to be:
cc
Miminized: Probably some span handcrafting?
Probably some span handcrafting? +1
I was idly curious, so I took a brief look at this. The diagnostic that triggers this was introduced in , but I don't think it is responsible for the error (it's just stepping through characters looking for a closing brace). There is some strange math in  (introduced in ). It oscillates between zero-length and 1+ length spans as it is stepping over characters. When it hits a multi-byte character, it returns an invalid span. Example: Starting with a span of (0,1), using would result in (1,1), then (1,2), then (2,2), then (2,4). That last one slices into the middle of the multi-byte character (because of , where width is 3), causing a panic. I'm not familiar enough with this stuff to say how it should behave. It seems like is being used for two different purposes (getting the next zero-length span, and getting the "next" character), and it's not clear to me what the behavior should be since it is used in a variety of places. I don't think it can be changed to always return zero-length spans, and it can't be changed to always return non-zero length spans. Perhaps there should be two different functions?
triage: P-medium, removing nomination; the ICE to me appears to include enough information for a user to identify the offending character and work-around the problem (namely by getting rid of the character). I do agree with that there should probably be two distinct functions corresponding to the two distinct purposes that they identified for the current callers of .
More test cases have been brought up in
I guess this is the same bug, but the examples I've seen here concern non-ASCII characters in comments. I'm getting a similar rustc panic from an erroneous code without comments: Compilation attempt:
Please file a new issue and reference this one.
I think it's fixed, try .
confirmed fixed by .
Change:
struct RevMoveBuckets<'a, K, V> { raw: RawBucket<K, V>, hashes_end: *mut u64, <del> elems_left: uint </del> <ins> elems_left: uint, marker: marker::ContravariantLifetime<'a>, </ins> } impl<'a, K, V> Iterator<(K, V)> for RevMoveBuckets<'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:
<ins> error: unreachable pattern --> $DIR/issue-65157-repeated-match-arm.rs:16:9 | LL |         PartiallyInhabitedVariants::Struct { .. } => {}, |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | note: lint level defined here --> $DIR/issue-65157-repeated-match-arm.rs:2:9 | LL | #![deny(unreachable_patterns)] |         ^^^^^^^^^^^^^^^^^^^^ error: aborting due to previous error </ins>

Discussion:
Say I have the following enum in crate : And I match on it in crate : The second branch is not detected to be unreachable. This is on current nightly; .
The reason for this behaviour is straightforward: reports tuple variants with non-exhaustive fields as always useful. This line was introduced in commit . I'm not quite sure what the intended semantics are so I wouldn't know how to fix it.
Please wait for to be merged before fixing this; I'm dreading having to rebase on top of the fix
cc
Change:
<ins> error[E0723]: unsizing casts are only allowed for references right now --> $DIR/unsizing-cast-non-null.rs:6:5 | LL |     NonNull::<[T; 0]>::dangling() |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: see issue #57563 <https://github.com/rust-lang/rust/issues/57563> for more information = help: add `#![feature(const_fn)]` to the crate attributes to enable error: aborting due to previous error For more information about this error, try `rustc --explain E0723`. </ins>

Discussion:
: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Is it a regression from stable to beta if it doesn't compile on stable? I this to the original comment: On rust stable 1.45.1, it causes this compilation error instead:
Yes, the error message regressed. I don't know if the code is supposed to compile on beta or if it should still fail with the same error, but an ICE is a regression either way.
I think the failure is introduced in and this unwrap causes it: So, my thought is we shouldn't unwrap here and return instead if it's . is this correct?
Yes, return an error mentioning that unsizing is only allowed for references right now.
Change:
#![feature(const_slice_ptr_len)] #![feature(const_type_name)] #![feature(const_likely)] <ins> #![feature(const_unreachable_unchecked)] </ins> #![feature(custom_inner_attributes)] #![feature(decl_macro)] #![feature(doc_cfg)]

Discussion:
Currently one cannot call in constant functions, so one cannot add hints of the form: These types of hints can heavily influence code generation, which can substantially change the performance of when they are invoked at run-time. It would be a shame to have to write and call and because the code generated for is sub-par. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
One cannot do any sort of conditional control flow, so would currently be less than useless. Any test you can write would be undefined behaviour
the RFC for / in const was merged and is pending an implementation right? When that's implemented, will still be useless?
No it makes sense after we have conditional control flow.
As I understand / in const functions is now implemented. Can be made into a now?
yes. Basically you just need to add the attribute to the intrinsic and wrapper function. This is documented at https://rustc-dev- Let me know if anything is unclear (in which case we should update the guide)
Hi, It looks like previous PR is not being worked on currently. I'm working on this and will create a PR soon. claim
As mentioned in , this issue should be reopened (to track stablization)
cc ^
After a short discussion on Zulip, it was decided that it's best to wait for to stabilize to avoid a potential footgun wherein users use this instead of , leading to UB at runtime. I'm subscribed to the issue and intend to file a PR to stabilize this once the aforementioned happens.
Change:
use middle::trans::common::*; use middle::trans::debuginfo; use middle::trans::expr; <del> use middle::trans::type_of; </del> use middle::ty; use util::ppaux::Repr;

Discussion:
This code: crashes rustc with the following error message: If I remove the first match arm, the program compiles correctly. I was able to reproduce this only with &'static str constants. Other types of constants I have used seem to work fine. This happens on Rust 0.9. I cannot check it on master version because I can't compile it for some reason.
Compiling with a build of rust from yesterday () I get a different error:
I was just editing the issue to add a note that I'm using Rust 0.9 because for some reason I can't build the compiler from master.
I got bit by this today with a master build (): If you replace the static variable with its string literal things work again
Change:
self.reserve(slice.len()); unsafe { let len = self.len(); <ins> let dst_slice = slice::from_raw_parts_mut(self.as_mut_ptr().add(len), slice.len()); dst_slice.copy_from_slice(slice); </ins> self.set_len(len + slice.len()); <del> self.get_unchecked_mut(len..).copy_from_slice(slice); </del> } } }

Discussion:
To my knowledge, the following code is intended to be legal: However, Miri currently flags this as UB. I believe this is , but for . Discovered while writing . cc
Yeah this looks pretty similar. uses under the hood though, so I wonder why the issue still exists here. Looks like is implemented via -- and indeed, this errors, too:
The problem is in this line: The here is a slice method, so this creates a slice covering the entire , which overlaps with the mutable reference created before and thus invalidates it.
It shouldn't be too hard to locally fix this, but that duplicates some code and there are some other uses of in . Ideally, this would all use raw slices to avoid making any uniqueness promises. But without , raw slices are not very useful.
Here's a possible fix:
Fix PR is up:
Change:
#!/bin/bash # Download and install MSYS2, needed primarily for the test suite (run-make) but # also used by the MinGW toolchain for assembling things. <del> # # FIXME: we should probe the default azure image and see if we can use the MSYS2 # toolchain there. (if there's even one there). For now though this gets the job # done. </del> set -euo pipefail IFS=$'nt'

Discussion:
On 2019-10-24 we had a CI outage due to the ca-certificates msys2 package being broken. The hack implemented (:heart:) is to download an older, known good package beforehand and install it after msys2 updated its packages. Once is fixed we should revert the hack, but I think at this point it's worth investing in vendoring msys2 as a whole.
msys2 is using and other tools from archlinux distro. Arch Linux provides per-day official repositories snapshots. User can "pin" to a specific date. I think it is possible to reuse that mechanism to vendoring msys2 as a whole, by providing a mirror of a specific date's version. See here for more descriptions .
that would be nice but msys doesn't remove old packages from their repo so the mirror would be enormous. Search for in , only those packages take dozens of GiB. Also extracting it from archive would make CI a bit faster because you won't be modifying thousands of small files over and over. On Linux that is not a problem but working through cygwin emulation a bit struggles on this part.
No update on this, planning to discuss what to vendor at the all hands.
At the last infra meeting we decided a good step is to move towards using the pre-installed msys2 packages. In theory this is as simple as removing the msys2 installation step and pointing things at the right location on the images in CI.
Change:
} err } <del> ResolutionError::BindingShadowsSomethingUnacceptable(what_binding, name, binding) => { let res = binding.res(); let shadows_what = res.descr(); </del> <ins> ResolutionError::BindingShadowsSomethingUnacceptable { shadowing_binding_descr, name, participle, article, shadowed_binding_descr, shadowed_binding_span, } => { </ins> let mut err = struct_span_err!( self.session, span, E0530, "{}s cannot shadow {}s", <del> what_binding, shadows_what </del> <ins> shadowing_binding_descr, shadowed_binding_descr, </ins> ); err.span_label( span, <del> format!("cannot be named the same as {} {}", res.article(), shadows_what), </del> <ins> format!("cannot be named the same as {} {}", article, shadowed_binding_descr), </ins> ); <del> let participle = if binding.is_import() { "imported" } else { "defined" }; let msg = format!("the {} `{}` is {} here", shadows_what, name, participle); err.span_label(binding.span, msg); </del> <ins> let msg = format!("the {} `{}` is {} here", shadowed_binding_descr, name, participle); err.span_label(shadowed_binding_span, msg); </ins> err } ResolutionError::ForwardDeclaredTyParam => {

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
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
Change:
| = help: the trait `PartialOrd<String>` is not implemented for `{integer}` = help: the following other types implement trait `PartialOrd<Rhs>`: <ins> f128 f16 </ins> f32 f64 i128 i16 i32 i64 <del> i8 isize and 6 others </del> <ins> and 8 others </ins> error[E0277]: can't compare `{integer}` with `Result<{integer}, _>` --> $DIR/binops.rs:7:7

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. --Playground nightly version: 1.79.0-nightly (2024-03-25 ) This isn't expected since it doesn't seem to hit a label +T-compiler +f-f16andf128 +I-ICE +requires-incomplete-features +S-has-mcve claim <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label -needs-triage
Minimized:
Looks like it just expects primitives to be . I'm not sure where exactly this assumption comes from, but might as well fix it before the rest of libs support can get merged.
Change:
.loading-content { display: none; } <ins> #main > h2 + div, #main > h3 + div { display: block; } #main > h2 + h3 { display: flex; } </ins>

Discussion:
For example in here: No sections is shown because they're hidden by default. It should be overloaded with noscript so that they show by default in such case.
cc
Using  for all sections that can be toggled would be a noscript-compatible, interactive solution. It can still be enhanced by javascript to respect global toggles. Edge doesn't support it but that just means edge users will have to rely on javascript as they already do today.
I'm not sure it'd fix the initial issue which made us add this auto-parts hiding. We're doing a lot of changes into the DOM so the goal is to not render it in order to make the rendering way faster. Also, we're currently supporting down to IE9. So if a recent browser like Edge doesn't support it, I'm not too much into using such a feature...
The content of details is hidden by default, only the summary is shown until you open it. So it would keep that property I don't see any problems though
The advantage of the current situation is that it works on all supported browsers whereas would just show everything and slow down the page rendering on old web browsers which are already the slowest. Once we drop old browsers support, I'm all for it but for now, not too much like I said...
Details does not show things by default unless you add the . The same behavior can be implemented in old browsers with CSS rules. Javascript would only have to toggle the attribute. <details<summaryLorem ipsum </summaryLorem ipsum dolor sit amet, consectetur adipiscing elit. Praesent et sem et lacus tincidunt posuere id sed orci. Orci varius natoque penatibus et magnis dis parturient montes</details
That doesn't answer my concerns at all:
simplified compatibility shim for IE, omitting the caret styling: This way it would not show everything by default and still would have to be unfolded via JS, exactly the same as today. No negative impact on rendering performance.
Change:
<del> Subproject commit 83403581bb7a2156f4752fc2d0ceef4b3ec75554 </del> <ins> Subproject commit 75417e5a660096929aa10f1072a21d6662c9c0dc </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! cc the PR reviewer, and nominating for compiler team prioritization.
Fix up at
Change:
use super::SubregionOrigin; <del> use super::combine::{CombineFields, RelationDir, const_unification_error}; </del> <ins> use super::combine::{CombineFields, RelationDir}; </ins> use crate::traits::Obligation; <del> use crate::ty::{self, Ty, TyCtxt, InferConst}; </del> <ins> use crate::ty::{self, Ty, TyCtxt}; </ins> use crate::ty::TyVar; use crate::ty::fold::TypeFoldable; use crate::ty::relate::{Cause, Relate, RelateResult, TypeRelation}; <del> use crate::infer::unify_key::replace_if_possible; use crate::mir::interpret::ConstValue; </del> use std::mem; /// Ensures `a` is made a subtype of `b`. Returns `a` on success.

Discussion:
<short summary of the bugI tried this code: I expected to see this happen: It should build. Instead, this happened: rustc crashed with: Possible workaround: replace with . playground: rustc version: 1.39.0-nightly 2019-09-15
cc
Also ICEs without explicit feature gate enabled :/
Change:
libssl-dev  pkg-config <del> COPY dist-i686-freebsd/build-toolchain.sh /tmp/ RUN /tmp/build-toolchain.sh i686 </del> <ins> COPY scripts/freebsd-toolchain.sh /tmp/ RUN /tmp/freebsd-toolchain.sh i686 </ins> COPY scripts/sccache.sh /scripts/ RUN sh /scripts/sccache.sh ENV  AR_i686_unknown_freebsd=i686-unknown-freebsd10-ar  <del> CC_i686_unknown_freebsd=i686-unknown-freebsd10-gcc  CXX_i686_unknown_freebsd=i686-unknown-freebsd10-g++ </del> <ins> CC_i686_unknown_freebsd=i686-unknown-freebsd10-clang  CXX_i686_unknown_freebsd=i686-unknown-freebsd10-clang++ </ins> ENV HOSTS=i686-unknown-freebsd

Discussion:
Steps to reproduce, on my FreeBSD/amd64 11.0 system: , where is: It's not 100%, but it usually happens after a few tries at most. I'll skip all the debugging and source-diving and just say that it's the same basic problem as : threads A and B are both in , thread A gets to first and s a lambda, then thread B enters and blocks in with the global mutex held, then thread A calls reentrantly on a different and deadlocks. But there might be a nicer solution than for , because has this patch: , on all platforms where they use Clang (apparently x86, little-endian ARM, and PPC), and 10.x is now the . appears to have a self-contained that doesn't use , and emprically the Rust 1.18.0 package available via doesn't deadlock. So, it might be enough to upstream that patch and update the build environment to 10.x if it isn't already.
Looks like we're using 10.2 on ci:
Thanks for the pointer. I took a (much) closer look at this, and I've gotten the build more or less working using Ubuntu's regular Clang package, which can cross-compile out of the box. I'll send a PR once I've gotten things cleaned up and tested a bit more.
So I'm kind of stuck because, when I try to test locally, I run into unless I remove , which isn't maximally useful because I don't have Cargo and therefore can't build Cargo. This happens even without my changes, but the same container running on Travis CI seems to work, and I'm at a loss as to what differences there could be that would affect (apparently?) the type checker. I suppose I could just test what I can and send a PR and hope for the best, but if possible I'd prefer to understand what my local setup is doing wrong.
Noticed this on 12-CURRENT, compilers from rustup always lock up when compiling , but it usually succeeds after a couple tries. It's nearly always !
Hmm, the rust from ports (that doesn't have this problem IIRC??) is built with bundled llvm by default…
Change:
} pub fn borrow_nested_obligations(&self) -> &[N] { <del> match &self { ImplSource::UserDefined(i) => &i.nested[..], ImplSource::Param(n, _) => &n, </del> <ins> match self { ImplSource::UserDefined(i) => &i.nested, ImplSource::Param(n, _) => n, </ins> ImplSource::Builtin(i) => &i.nested, ImplSource::AutoImpl(d) => &d.nested, ImplSource::Closure(c) => &c.nested,

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 code: This is modification of with the difference being ` Rust OOM'd here after eating at least 20 gb of memory :sweat_smile: I expected to see this happen: explanation NO OOM, maybe an error Instead, this happened: explanation OOM <!-- 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. --:
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
static ENV_LOCK: RwLock<()> = RwLock::new(()); <ins> pub fn env_read_lock() -> impl Drop { ENV_LOCK.read().unwrap_or_else(PoisonError::into_inner) } </ins> pub struct Env { iter: vec::IntoIter<(OsString, OsString)>, }

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. --Investigating library sources for , I have found that the copying of the env variable value is performed not under the lock: So there is a potential data race with setenv. I tried this code with miri And got Have tried to move under the lock, but still got error with miri. I was not able to trigger the real crash with it yet. <!-- 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. --: Bug was introduced by this commit: (PR: ) Before that changes, read was under the lock. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
I think this happened because implicit scoping of the lock guard, which makes it easy to shorten its lifetime the rwlock isn't coupled to the resource via a lifetime, so it's easy for the extracted pointer to be used longer than the lock is valid The first one could be made more visible by linting to add an explicit to make its lifetime more explicit in the code when a critical section ends. Especially when guard is otherwise unused which indicates that the lock doesn't directly own the resource it protects. The second one could be solved by using a lifetime-tagged raw pointer and coupling that lifetime to the guard.
Side note: even when fixed this assumes all other read/writes acquire Rust's lock and is potentially unsound if they do not. This has often been discussed with a view to making unsafe. Arguably if that happens then the lock would be redundant, although it could also be argued it's still useful to help avoid some footguns even if you can't make it totally safe.
That's
That PR did not add a test, did it? Would be good to add one in (those are run in Miri regularly). We probably don't want iterations though, that will take forever. 100 should easily be enough.
Something like ?
Yeah something like that.

For Miri it's not really necessary to do this "sum of the lengths" computation, not sure why that would be particularly susceptible to a data race. The one existing concurrency test uses , so probably it would make sense to use the same attribute here.