jiebi/CodeConvo huggingface dataset:
Change:
assert_failed(at, self.len()); } <del> if at == 0 { // the new vector can take over the original buffer and avoid the copy return mem::replace( self, Vec::with_capacity_in(self.capacity(), self.allocator().clone()), ); } </del> let other_len = self.len - at; let mut other = Vec::with_capacity_in(other_len, self.allocator().clone());

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 was reviewing some code that uses in a loop to take the contents of a buffer, while leaving the buffer's capacity intact to be reused by subsequent iterations. When I double-checked the actual behaviour of , I was surprised to find that the vector returned by had a much larger capacity than was necessary to hold its contents. Consider this example program: I expected that the and vectors would have similar capacities, since they each only hold one value. Instead, this happened: The single-element vector produced by has a tight capacity of 1, but the single-element vector produced by has a wasteful capacity of 100, which is the same as the original vector's capacity. (The method's documentation doesn't make any explicit promises about the capacity of the returned vector, so this isn't necessarily a bug per se, but it is a surprising behaviour.)
This behaviour seems to have been introduced by , as an explicit optimization of the case, to avoid having to move the elements into a new allocation. That PR notes that the new behaviour is compatible with the existing documentation, and notes some concerns about wastefully reallocating lots of capacity due to an outlier in how long the list gets, but I don't see any discussion of the capacity of the returned vector specifically. At the very least, this behaviour probably deserves some warning in the docs, since the actual behaviour wastes more capacity than the “obvious” implementation would.
label +T-libs
Looking again at the actual documentation, it says this: If the returned vector is “newly allocated”, it's natural to assume that the new allocation would be reasonably tight, if not exact. But in the 0 case, the returned vector isn't newly allocated at all, since it steals its allocation from the existing vector.
When is 0, directly return original vec as here: it's indeed a issue, but I haven't got a better solution, this change will fix the issue, but will also introduce extra copy:
splitoff in don't have this issue:
I think the realistic options are: Document the possibility of unexpected capacity/allocation behaviour when Remove the special handling for , and just use the same code path for and In cases where is unknown, I think it's surprising for 0 and 1 to behave very differently.

In cases where the user specifically wants the current behaviour, it may be better for the user to write themselves.
Change:
/// Creates the `rust-src` installer component fn run(self, builder: &Builder<'_>) -> GeneratedTarball { <ins> builder.update_submodule(&Path::new("src/llvm-project")); </ins> let tarball = Tarball::new_targetless(builder, "rust-src"); // A lot of tools expect the rust-src component to be entirely in this directory, so if you

Discussion:
I cloned the Rust repo with the intention of building rustc for cross-compilation to the target. I did the following: selected the "codegen" option the file to append: This failed; the end of the output is as follows: After I executed and retried the build command, the LLVM submodule was checked out and the build was able to make progress. It seems like this should be done automatically. I'm not sure if the issue is specific to this target or if it's happening with other cross-compilation targets. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Hmm. This is some interaction between and cross-compiling, but I'm not sure exactly what — it should be a no-op unless you're building for the host. As a workaround you can set and that should handle the submodule automatically.
(Note that is implied by .)
Ok, it looks like we only try to build crtbegin.o for musl targets: So I think we would have checked out the submodule if we were doing a full LLVM build, but because we're only building the CRT it got missed when download-ci-llvm was implemented. I think the simplest fix is to call at the start of , like we do for the step:
looks like it also has the same bug: as well as :
claim
Does fixing also come under the scope of this issue? I'd be happy to fix that as well.
sure thing, feel free to fix all three at once :)
Do I pause work on this till gets resolved? Since it's implementing the workaround you mentioned as a solution
no, this fix still makes sense - not everyone is using the profile without changes.
Change:
| LL |         if (foo) => {} |            ^^^^^ <ins> help: you might have meant to write a "greater than or equal to" comparison | LL |         if (foo) >= {} |                  ~~ </ins> error: expected `{`, found `bar` --> $DIR/missing-block-hint.rs:7:13

Discussion:
When encountering code like , we currently emit But it should be closer to <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Hi! I'd like to try working on this issue if nobody else is currently. claim
Change:
use rustc::hir::def_id::DefId; use rustc::middle::lang_items::{ExchangeMallocFnLangItem}; use rustc::traits; <del> use rustc::ty::subst::{Substs, Subst}; </del> <ins> use rustc::ty::subst::Substs; </ins> use rustc::ty::{self, TypeFoldable, TyCtxt}; use rustc::ty::adjustment::CustomCoerceUnsized; use rustc::mir::{self, Location};

Discussion:
Compiler panicks instead of showing an appropriate error message in case boundaries are not satisfied. I tried this code: In the result compiler panicked with the following message:
Minimal repr:
Still panics on stable 1.15.1
Change:
} }; <del> Ok(ModuleLlvm { llmod_raw, llcx, tm }) </del> <ins> Ok(ModuleLlvm { llmod_raw, llcx, tm: ManuallyDrop::new(tm) }) </ins> } }

Discussion:
After using command random dependencies throw error. I'm 100% sure that dependencies I'm trying to build are valid because at every compile attempt different dependency fails e.g. tomledit, crossbeam-channel, actix-router_. Sometimes none of imported dependencies fail and out of 5 attempts I was able to build project succesfully twice (I deleted folder after each attempt). Example output: some dependencies (in my case 23) command Improve build scripts on Windows ARM?
Thanks for the report! Transferred to rust-lang/rust since this is a compiler issue. I'm able to reproduce, though I am also using Parallels on an aarch64 mac. I do not have native Windows ARM hardware to test, so I'm not sure if this is unique to the M2 or Parallels. If someone has native hardware, it might be good to help with testing to see if it is a general problem with the target. This appears to be a regression, and I have bisected to cc
I'm seeing the same issue intermittently on a project that uses . It looks like we might have a UAF on an LLVM object. <details<summaryCrashing stack</summary</details<details<summaryEarlier "untrack" operation</summary</detailsI'm guessing this might be triggered because causes us to drop the LLVM TargetMachine dropping the LLVM context.
Swapping the drop order back to the way we had it originally makes my reproducer compile successfully.
WG-prioritization assigning priority (). label -I-prioritize +P-high
Re-opening to track backports
I encountered this issue in Github CI yesterday. It only occurs with rust-1.74 but not with 1.73 and lower.
this should be fixed by and included in the upcoming 1.74.1 stable release. You can probably try a nightly rustc build if you're curious to test the fix.
74.1 has been released.
Yes fixed it.
Hi, sorry for reply to the closed issue, but since I updated my M2 macbook to Sonoma 14.2 last week, I randomly got similar issue
This is happening again with Full log here
Please open a new issue, but it might also have something to do with
Change:
packages: &[], features: None, manifest_path: None, <ins> // Many tests here use quickcheck and some of them can fail randomly, so only run deterministic tests. filters: &[ "test_flatten::", "test_fmt::", "test_headers::", "test_index::", "test_join::", "test_partition::", "test_search::", "test_select::", "test_slice::", "test_split::", "test_stats::", "test_table::", ], </ins> }, Test { name: "servo",

Discussion:
As part of our CI we run "cargotest" on a variety of ecosystem crates, making sure they successfully build and run tests. Unfortunately, some of use stochastic tests like quickcheck, which means that a crate passing our CI one day may not necessarily mean it passes CI the next. Perhaps we should audit the tests being run and filter out ones like these? See and cc
Yeah I think we've discussed this to some extent previously within infra team as part of our "what to do about cargotest" discussions. cc in particular Not sure that we came to any conclusions though.
Related:
The test from xsv fails occasionally:
This just bit me and took a lot of time as I triple-checked that after bors failing twice (!) in xsv, the same test actually works fine on my system.
The xsv test suite seems to be full of quickcheck tests, so I think the only way to fix this is to remove xsv from cargotest (or to only run a short list of curated tests).
See where there is some discussion fo changing the cargotest set. I think implies dropping xsv.
Hm, that discussion seems to have stalled though. So to fix the immediate problem, I propose we do something like
Change:
/// ``` #[macro_export] #[stable(feature = "rust1", since = "1.0.0")] <ins> #[allow_internal_unstable] </ins> macro_rules! writeln { ($dst:expr) => ( write!($dst, "n")

Discussion:
The following all compile and run for example: I would expect them to produce "error: format argument must be a string literal." like does. This is because they use things like but accepts other literals not just . I assume this isn't intentional.
One way to fix this is to replace 's definition with I would prefer to force and friends to take strings but at least this keeps it consistent. EDIT: I honestly don't like how automatically stringifies, it seems kinda ugly and I feel like there should be a separate macro that does compile-time stringification. This would almost certainly be super backwards-incompatible though.
awesome! Why do the places that need 's stringifying functionality not use so doesn't duplicate functionality? That would solve this issue. EDIT: Turns out is different to , the latter only accepts literals whereas the former will verbatim stringify token trees, such as .
Seems like it'd be a breaking change to "fix" this.
For it is explicit and by design, so that part is no problem.
good point, actually has it's own unintuitive behaviour similar but different to .
Why do we consider that the code like works to be a bug? I understand that forbidding it will make more consistent and explicit but we're trading in some convenience here. The other option could be to make behave in same way.
it's not documented so technically something needs to fixed, even if it's just the documentation. If we make behave the same then surely we'd have to change and as well to keep things consistent and I don't think that's a good idea as this isn't even useful. I think this should either be fixed as a breaking change, I doubt it will break much if any real world code, or just depreciated.
thanks for the clarifications, thats makes sense now. I'm not sure and should behave exactly as and as the two groups of macros serve different purposes. Maybe one more special case doesn't worth it however.
Libs team consensus: while it may be desirable to clean this up, this is not breakage we're willing to take on during the Rust 1.x series. I've a new tag, closed-as-desirable-breakage, to help us track issues like this that we might want to revisit if we ever produce a 2.0 release.
related issue: accepts non-bools
Sadly, has been implemented with this bug, so is also affected: .
This would be improved by
Change:
// operation panics, `hole` will get dropped and automatically write the element back // into the slice. let mut tmp = mem::ManuallyDrop::new(ptr::read(v.get_unchecked(0))); <del> let mut hole = CopyOnDrop { src: &mut *tmp, dest: v.get_unchecked_mut(1) }; ptr::copy_nonoverlapping(v.get_unchecked(1), v.get_unchecked_mut(0), 1); </del> <ins> let v = v.as_mut_ptr(); let mut hole = CopyOnDrop { src: &mut *tmp, dest: v.add(1) }; ptr::copy_nonoverlapping(v.add(1), v.add(0), 1); </ins> for i in 2..len { <del> if !is_less(v.get_unchecked(i), &*tmp) { </del> <ins> if !is_less(&*v.add(i), &*tmp) { </ins> break; } // Move `i`-th element one place to the left, thus shifting the hole to the right. <del> ptr::copy_nonoverlapping(v.get_unchecked(i), v.get_unchecked_mut(i - 1), 1); hole.dest = v.get_unchecked_mut(i); </del> <ins> ptr::copy_nonoverlapping(v.add(i), v.add(i - 1), 1); hole.dest = v.add(i); </ins> } // `hole` gets dropped and thus copies `tmp` into the remaining hole in `v`. }

Discussion:
Similar to I tried this code: I expected to see this happen: Miri does not detect UB Instead, this happened: Miri detects UB (experimentally) <!-- 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<summaryBacktrace</summary<p</p</details
cc
FWIW, I have now detected this bug through the tests in and .
Looks like the problem is in this line: re-borrows an on the entire slice, thus invalidation previously created pointers. So this is yet another instance of
Actually, just to be sure, are we interested in patching out all such instances of this in std/alloc/core? I know I personally would like the standard library to be clean against Miri with so that I can check libraries for stacked borrows issues. I just did a quick skim now that I understand the rules and I think I can spot a few other issues, so I'm not sure if these were deliberately left in, or if I'm just the first person to be looking this carefully.
So far we fixed various issues of this sort that people noticed, but there was never a concerted effort to find all of them. So they were not deliberately left in, just not found yet. Whether we want to fix them all is up to who ultimately decide about the std library implementation.
So far the fixes have been localized enough that it's been easy to take them (eg ). If anything comes up that requires drastic changes to fix then there might be a conversation about it, but for simple ones that don't increase maintenance burden I think they'll be happily accepted.
Change:
$(Q)$(CFG_PYTHON) $(S)src/etc/check-summary.py tmp/*.log # As above but don't bother running tidy. <del> check-notidy: cleantmptestlogs cleantestlibs all check-stage2 </del> <ins> check-notidy: check-sanitycheck cleantmptestlogs cleantestlibs all check-stage2 </ins> $(Q)$(CFG_PYTHON) $(S)src/etc/check-summary.py tmp/*.log # A slightly smaller set of tests for smoke testing. <del> check-lite: cleantestlibs cleantmptestlogs  </del> <ins> check-lite: check-sanitycheck cleantestlibs cleantmptestlogs  </ins> $(foreach crate,$(TEST_TARGET_CRATES),check-stage2-$(crate))  check-stage2-rpass check-stage2-rpass-valgrind  check-stage2-rfail check-stage2-cfail check-stage2-pfail check-stage2-rmake $(Q)$(CFG_PYTHON) $(S)src/etc/check-summary.py tmp/*.log # Only check the 'reference' tests: rpass/cfail/rfail/rmake. <del> check-ref: cleantestlibs cleantmptestlogs check-stage2-rpass check-stage2-rpass-valgrind  check-stage2-rfail check-stage2-cfail check-stage2-pfail check-stage2-rmake </del> <ins> check-ref: check-sanitycheck cleantestlibs cleantmptestlogs check-stage2-rpass  check-stage2-rpass-valgrind check-stage2-rfail check-stage2-cfail check-stage2-pfail  check-stage2-rmake </ins> $(Q)$(CFG_PYTHON) $(S)src/etc/check-summary.py tmp/*.log # Only check the docs. <del> check-docs: cleantestlibs cleantmptestlogs check-stage2-docs </del> <ins> check-docs: check-sanitycheck cleantestlibs cleantmptestlogs check-stage2-docs </ins> $(Q)$(CFG_PYTHON) $(S)src/etc/check-summary.py tmp/*.log # Some less critical tests that are not prone to breakage.

Discussion:
The failure happens in when the output of the command used in the test contains cyrillic letters. Changing the system locale to English (USA) or replacing with something like makes this error go away. cc
Hm interesting! This probably isn't so much connected to locales so much that something in the environment/output isn't valid UTF-8. Could you get a backtrace of this failure? I would be surprised if this was coming from , but the test looks pretty innocuous, so it may very well be coming from std!
The problem may actually reside in compiletest, it captures the output of the test and then can interpret it incorrectly. If the test is run as a standalone program outside of the test suite then no panic happens and the test works as expected. I'm still investigating. Here's the backtrace, but it's not very helpful:
Aha! It looks like . I suspect it would be fine for to just use
Change:
} } <del> pub fn getenv(k: &OsStr) -> io::Result<Option<OsString>> { </del> <ins> pub fn getenv(k: &OsStr) -> Option<OsString> { </ins> // environment variables with a nul byte can't be set, so their value is // always None as well <del> let k = CString::new(k.as_bytes())?; </del> <ins> let k = CString::new(k.as_bytes()).ok()?; </ins> unsafe { let _guard = env_read_lock(); let s = libc::getenv(k.as_ptr()) as *const libc::c_char; <del> let ret = if s.is_null() { </del> <ins> if s.is_null() { </ins> None } else { Some(OsStringExt::from_vec(CStr::from_ptr(s).to_bytes().to_vec())) <del> }; Ok(ret) </del> <ins> } </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 --
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.
Change:
ptr_offset_from_unsigned, pub_macro_rules, pub_restricted, <ins> public, </ins> pure, pushpop_unsafe, qreg,

Discussion:
When writing it will suggest and I think nothing should be suggested before it is validated. The statement to be suggested must be checked if it is true or not, if true it is suggested and if not it is not. The issue from: : The current output is: <!-- The following is not always necessary. --Ideally the output should look like: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Oh dear, I didn't think of that while making the PR. A possible solution could be checking if the current token is for initializing an item? Like, struct/enum/macro, etc.
I wrote this solution, but I don't know if I can use it in rustc, it's currently building
I can't work on the problem unfortunately, whoever will assign it to him you can solve it this way The block
release-assignment
claim
Trying to add a method in token: And add a check: Any other better idea?
could be the keyword, as well. looks alright, ideally the repeated block could be prevented using a macro? I'm afraid that might slightly overengineer it, though.
Change:
<ins> use std::sync::mpsc; fn main() { let (tx, rx) = mpsc::channel::new(1); //~^ ERROR expected type, found function `channel` in `mpsc` } </ins>

Discussion:
Given this code (): I expected that would indicate that is not function but is. Instead, I got: A diagnostic along the lines of isn't a function, but is would be helpful. <!-- 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. --: </p</details
I tried to resolve this issue with The error message now is Any informative error message suggestions?
Thanks for trying to address this. I'll comment on the PR you opened.
Change:
(tcx.lang_items.sync_trait().unwrap(), external_path(cx, "Sync", None, vec![], &empty)), }; <del> let fqn = tcx.sess.cstore.item_path(did); let fqn = fqn.into_iter().map(|i| i.to_string()).collect(); cx.external_paths.borrow_mut().as_mut().unwrap().insert(did, (fqn, TypeTrait)); </del> <ins> inline::record_extern_fqn(cx, did, TypeTrait); </ins> TraitBound(PolyTrait { trait_: ResolvedPath { path: path,

Discussion:
The [src] link on these pages is broken: The links are also broken in the stable docs version of these pages.
I think this should be fixed by . The links wrongly point to instead of because the crate is linked in std like
I've built the docs locally and the issue somehow persists.