jiebi/CodeConvo huggingface dataset:
Change:
let mut llvm_c_strs = Vec::with_capacity(n_args + 1); let mut llvm_args = Vec::with_capacity(n_args + 1); <del> llvm::LLVMRustInstallFatalErrorHandler(); </del> <ins> llvm::LLVMRustInstallErrorHandlers(); </ins> // On Windows, an LLVM assertion will open an Abort/Retry/Ignore dialog // box for the purpose of launching a debugger. However, on CI this will // cause it to hang until it times out, which can take several hours.

Discussion:
Running a build of , as part of a Koiji (Fedora Build System) job, I get the following for the target: Also see:
To my understanding this should be Rust
I think this is "just" an OOM situation. Fedora builds with full debuginfo by default, and this package is configured for fat LTO as well, which will all get quite heavy. When I tried to reproduce this with the stable toolchain, I got: It completed when I turned off debuginfo though. With Fedora's toolchain, I can reproduce your SIGSEGV in LLVM, but it also completes the build when debuginfo is off. My guess is that it is also hitting an allocation failure, but perhaps in a place that doesn't properly check the pointer before trying to use it.
With the rustup toolchain, it's running out of memory in LLVM's , which calls allocation methods that abort on failure. That's where we get the "LLVM ERROR: out of memory", "Allocation failed". With the Fedora toolchain, it's running out of memory in LLVM's , which calls to plain , throwing . Rust runs its own destructors during that unwind, in particular dropping that calls , and this segfaults in a (presumably the same one).
I encontered this when compiling a big proprietary project to --target=i686-unknown-linux-musl using nightly-2024-03-01 on a x86_64 host
with an x86_64 host and a different backtrace, I doubt that yours has the same root cause. I suggest filing a separate issue -- but it's going to be hard for anyone to help if they can't reproduce it, since your code is proprietary.
Change:
Ok(()) } <ins> #[instrument(skip(tcx), level = "debug", ret)] </ins> pub fn collect_trait_impl_trait_tys<'tcx>( tcx: TyCtxt<'tcx>, def_id: DefId,

Discussion:
Essentially, if my trait has and my impl has the compiler panics. Note that the code is invalid and compilation should fail. <!-- 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. --: Note that I'm using which is experimental. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
This happens for all type mismatches in the arguments (but not the arity!) A : <details<summaryWith the following backtrace: </summary</details
When not using a normal , the proper error is emitted here inside : But something gets messed up with the return position impl trait in trait desugaring that doesn't make this work (the arity check above does work). claim
Change:
.collect(); Ok(Some(files)) } <ins> /// Print a warning if the branch returned from `updated_master_branch` is old /// /// For certain configurations of git repository, this remote will not be /// updated when running `git pull`. /// /// This can result in formatting thousands of files instead of a dozen, /// so we should warn the user something is wrong. pub fn warn_old_master_branch( config: &GitConfig<'_>, git_dir: &Path, ) -> Result<(), Box<dyn std::error::Error>> { use std::time::Duration; const WARN_AFTER: Duration = Duration::from_secs(60 * 60 * 24 * 10); let updated_master = updated_master_branch(config, Some(git_dir))?; let branch_path = git_dir.join(".git/refs/remotes").join(&updated_master); match std::fs::metadata(branch_path) { Ok(meta) => { if meta.modified()?.elapsed()? > WARN_AFTER { eprintln!("warning: {updated_master} has not been updated in 10 days"); } else { return Ok(()); } } Err(err) => { eprintln!("warning: unable to check if {updated_master} is old due to error: {err}") } } eprintln!( "warning: {updated_master} is used to determine if files have been modifiedn warning: if it is not updated, this may cause files to be needlessly reformatted" ); Ok(()) } </ins>

Discussion:
I have my master branch set up to track the master branch of my fork (mainly because i don't want to accidentally pull in every git tag into my shallow clone), so doesn't updated when i run (presumably the remote was created by ? i don't remember creating it, and lots of code needs it (or another branch pointing to this repo) to work). as it turns out, uses the state of to determine if a file has been modified. so instead of it formatting every file that i modified, it formats every file anyone has modified in the last few months. at no point did anything warn me that i need to be updating a remote i didn't add. it should probably do that. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
this could be addressed by checking the timestamp on .git/refs/remotes/upstream/master and warning if it is very old
claim
I ran into a similar issue where was building llvm from source instead of using the prebuilt ci version due to an outdated branch. Would it make sense to solve both issues in one go?
should be pretty easy, just call the same warning method for both build steps maybe it should be used for all build steps?
Change:
binding = self.r.resolution(module, key).try_borrow().ok().and_then(|r| r.binding); debug!(?binding); } <ins> let feed_visibility = |this: &mut Self, def_id| { let vis = this.r.tcx.visibility(def_id).expect_local(); this.r.feed_visibility(this.r.local_def_id(id), vis); }; </ins> let Some(binding) = binding else { // We could not find the method: report an error. let candidate = self.find_similarly_named_assoc_item(ident.name, kind); let path = &self.current_trait_ref.as_ref().unwrap().1.path; let path_names = path_names_to_string(path); self.report_error(span, err(ident, path_names, candidate)); <ins> feed_visibility(self, module.def_id()); </ins> return; }; let res = binding.res(); let Res::Def(def_kind, id_in_trait) = res else { bug!() }; <ins> feed_visibility(self, id_in_trait); </ins> match seen_trait_items.entry(id_in_trait) { Entry::Occupied(entry) => {

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'assertion failed'', 'thread 'rustc' panicked at 'assertion failed'' 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: [visibility] computing visibility of [effectivevisibilities] checking effective visibilities [checkmoditem_types] checking item types in top-level module [analysis] running analysis passes on this crate --
Regression in ping
Fixed in
Change:
self.pop_front() } <del> /// Inserts an element at `index` within the `VecDeque`. Whichever /// end is closer to the insertion point will be moved to make room, /// and all the affected elements will be moved to new positions. </del> <ins> /// Inserts an element at `index` within the `VecDeque`, shifting all elements with indices /// greater than or equal to `index` towards the back. </ins> /// /// Element at index 0 is the front of the queue. ///

Discussion:
The documentation for describes implementation details of how it internally rearranges the data structure which make it unclear on what the actual behavior of the method call is: "Inserts an element at index within the VecDeque. Whichever end is closer to the insertion point will be moved to make room, and all the affected elements will be moved to new positions. Element at index 0 is the front of the queue." The doc should clearly state that the element will be inserted at this index and the existing element at this index will be pushed towards the back of the deque. The current doc makes it sound like which direction the existing element will be pushed towards could be different depending on that implementation detail.
Opened a PR for this:
Change:
("no_builtins", Whitelisted), ("no_mangle", Whitelisted), ("no_stack_check", Whitelisted), <del> ("static_assert", Gated("static_assert", "`#[static_assert]` is an experimental feature, and has a poor API")), </del> ("no_debug", Whitelisted), ("omit_gdb_pretty_printer_section", Whitelisted), ("unsafe_no_drop_flag", Gated("unsafe_no_drop_flag",

Discussion:
In I add a basic form of static assertions (as suggested by graydon in ), but it's not nice to use. The biggest problem with it is you need a static variable with a name, that goes through trans and ends up in the object file. suggested , which I think is a nice API but would need some invasive changed to the compiler (I think, uncertain).
Eh. I'm actually kinda ok with the way it turned out. If it's non-pub it shouldn't wind up in the object file as a public symbol (if it does, we're doing-stuff-wrong in codegen) and we can potentially just mark it as a throw-me-away sort of value harder if LLVM requires further convincing. Considering that static asserts in C are typically done by composing a negative-sized array and allowing the compiler to yell about that, I consider this implementation already pretty luxurious :)
How about having a thats just a wrapper around a automatically generated private static item with the #[staticassert] attribute?
if i understand you correctly, that's what i've suggested in but it seems not straightfoward to implement
Hm, but the current attribute-static item system works, no? Wouldn't a just be trivial sugar for that? Or is the 'generate a name'-part the hard one?
I don't know how to implement a macro to do this, so feel free to take a shot at it :smiley_cat:
Visiting for triage. Doesn't seem like a release blocker.
With hygiene, it should be much easier.
Triage: hygiene doesn't particularly help in this case, it's currently only for names created/bound with . A sketch: Uncommenting the gives a duplicate module error (as one might expect). If there was a macro (for creating a completely new ident) this might help, but is currently not valid as macros aren't allowed in place of s.
Macros can now expand to items with attributes:
triage bump. Nothing to add
It always needs to be crippled enough that it can't cause a compilation failure during expansion of generics. I think we should just remove the current attribute. It doesn't appear to have any real world use cases.
triage: nothing to add. We don't currently use anywhere in the codebase, which leads me to wonder if isn't right here.

An implementation in standard Rust based on the array size trick: In short, an invocation expands to It is variadic because there will be a name collision between two invocations... Yes the usability is horrible.
I wish Rust would support more static features(I use them extensively in C++ in order to enforce correct API usage)... I need to assert the simplest case: making sure the user doesn't pass an empty array/slice - and I cannot do it with the language... It's awful that I have to "assert" at run-time for such a simple case...
Change:
<ins> // issue-49296: Unsafe shenigans in constants can result in missing errors #![feature(const_fn)] #![feature(const_fn_union)] const unsafe fn transmute<T: Copy, U: Copy>(t: T) -> U { union Transmute<T: Copy, U: Copy> { from: T, to: U, } Transmute { from: t }.to } const fn wat(x: u64) -> &'static u64 { unsafe { transmute(&x) } } const X: u64 = *wat(42); //~^ ERROR any use of this value will cause an error fn main() { println!("{}", X); } </ins>

Discussion:
produces without any additional info. If the value is not dereferenced, but instead fed to llvm, we get an ICE in trans: results in Even though it should be reporting a dangling pointer const eval error
Both samples now require The first reports a dereferenced dangling pointer and the second sample no longer triggers an ICE
Thanks for checking up on this! So all we need is a ui test for the first example, because I don't think we have a regression test for that error. The second one definitely has a bunch of tests.
Change:
/// instance (with [`write`] and [`write_u8`] etc.). Most of the time, `Hasher` /// instances are used in conjunction with the [`Hash`] trait. /// <ins> /// This trait makes no assumptions about how the various `write_*` methods are /// defined and implementations of [`Hash`] should not assume that they work one /// way or another. You cannot assume, for example, that a [`write_u32`] call is /// equivalent to four calls of [`write_u8`]. /// </ins> /// # Examples /// /// ```

Discussion:
Currently is implemented as . The question is: is it a requirement for all implementations? In other words, is is true, that for each hasher implementation, call must be equivalent to ? (assuming host is little-endian). Why is it important. Suppose, you want to implement very simple hasher with state updated like . If does not have requirement as above, hasher can be implemented by simply casting any operand to and avoiding dealing with unaligned/smaller than u64 integers:
I’m fairly sure there was a discussion about it before and we decided against doing any changes to the libstd impl. Don’t exactly remember the reason, though.
If any decision is made, I wish it would be stated in the documentation of trait.
employs a different implementation to achieve platform-independence.
I don't think there's any such requirement. The in the compiler does exactly what your example does.
I think I would be opposed to this requirement; it imposes a performance penalty for systems of the "wrong" endianness, since they would need to correct their endianness. The only requirement on should be that the same sequence of calls produces the same result, I think.
My spec request: given two byte slices and , is equivalent to ? This way, we could define all the non-slice methods as explicitly being transmutes, always.
removing until lets us know what to document here.
My personal take on this is that we should only guarantee that produces the same value for the exact same sequence of calls. This even applies to plain calls on byte slices: a is only guaranteed to produce the same result if the same sequence of calls are used with the same slice lengths*. For an example of where this could make a difference, consider from Abseil which hashes short slices by reading 0-16 bytes and padding anything not included in the length with zeroes or duplicates of the existing bytes.
Based on the libs team decision in , I'm going to close this issue. The answer to the question in the issue title is no: is not required to be equivalent to 4 calls of .
Was there any updates to the documentation of Hasher? I didn't see any in a quick scan of threads.
Yeah, it seems like the thread was closed because the original idea was decided to not be done, but I agree that it shouldn't be closed until documentation is .

cc who closed this since it shouldn't be closed. Opened to add docs for this, but think this issue should be kept open until we've finally decided on how to document this.
Change:
return Ok(constant); } <del> let constant = constant.try_super_fold_with(self)?; debug!(?constant, ?self.param_env); Ok(crate::traits::with_replaced_escaping_bound_vars( </del> <ins> let constant = crate::traits::with_replaced_escaping_bound_vars( </ins> self.infcx, &mut self.universes, constant, |constant| constant.normalize(self.infcx.tcx, self.param_env), <del> )) </del> <ins> ); debug!(?constant, ?self.param_env); constant.try_super_fold_with(self) </ins> } #[inline]

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. --: rustc -Cdebuginfo=2 --crate-type lib <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
I guess this is now reachable without debug assertions cc
not entirely sure why that assertion fails but: good?
Change:
} } <del> #[derive(Debug, Copy, Clone, Hash, PartialEq, Eq)] pub struct JsonStd { pub stage: u32, pub target: TargetSelection, } impl Step for JsonStd { type Output = (); const DEFAULT: bool = false; fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { let default = run.builder.config.docs && run.builder.config.cmd.json(); run.all_krates("test").path("library").default_condition(default) } fn make_run(run: RunConfig<'_>) { run.builder.ensure(Std { stage: run.builder.top_stage, target: run.target }); } /// Build JSON documentation for the standard library crates. /// /// This is largely just a wrapper around `cargo doc`. fn run(self, builder: &Builder<'_>) { let stage = self.stage; let target = self.target; let out = builder.json_doc_out(target); t!(fs::create_dir_all(&out)); let extra_args = [OsStr::new("--output-format"), OsStr::new("json")]; doc_std(builder, DocumentationFormat::JSON, stage, target, &out, &extra_args, &[]) } } </del> /// Name of the crates that are visible to consumers of the standard library. /// Documentation for internal crates is handled by the rustc step, so internal crates will show /// up there.

Discussion:
running only builds the html doc, but builds the json doc. I expected the json flag to act as the documentation says (): using the master branch of this repo commit running with a library profile.
I can't reproduce this. The files show up for me in .
Seems to reproduce, I could totally have overlooked a step tho
oh no it's even simpler than that lol it's calling the wrong function that should be JsonStd, not Std
Should I make the PR or are you gonna do it ?
If you could make a PR that would be great :)
Made the PR but since just changing the ensure wasn't enough there's a thing I'm unsure about (tested it, worked, but could be cleaner)
Change:
impl<A: Clone> Clone for ~[A] { #[inline] fn clone(&self) -> ~[A] { <del> self.iter().map(|item| item.clone()).collect() </del> <ins> // Use the fast to_owned on &[A] for cloning self.as_slice().to_owned() </ins> } fn clone_from(&mut self, source: &~[A]) {

Discussion:
Benchmark program at the end. The results: That comes out to 300 MB/s… really bad for a memory copy. I'm guessing this has to do with the fact that is generic. Its looks like and LLVM probably isn't smart enough to optimize this down to a . But anyway, there is a need for efficient vectors of primitive numerical types. If this can't happen by optimization magic, we need something like (untested). I can also imagine a language feature which would let you write This is worryingly close to C++ template specialization, but might be worth it for core data structures. It's really counterintuitive if you need to use a special vector type or a special clone method to get acceptable performance on vectors of primitive integers. Bonus weirdness: If you comment out then gets significantly faster (though still way too slow): If you comment out instead, nothing in particular happens. Here's the benchmark program:
I think this is probably . I don't think we need to change any of the vector code, it's a fixable bug.
might also be related.
(Actually, I suppose I'd want and then is a one-liner using that.)
was renamed to , fwiw.
I'm looking into this (and the related bugs) and it seems that LLVM is suspicious of the write to the vector length during the copy loop and therefore doesn't convert the loop to a memcpy. I'm currently coaxing the relevant code to allow LLVM to optimise to a memcpy where it can.
What if you mark the pointer as ? It would be correct to have rustc mark all pointers to types without inside that way.
I think it might be more than that. The bounds checks seem to cause the memcpy recogniser to fail, even though they actually get optimised out anyway.
AFAIK, there are no bounds checks here. It may hit the issue causing a redundant null check to be in the loop due to a missed optimization in LLVM. That's caused by the lack of a way to tell LLVM a pointer is non-null, but I expect LLVM could do better even without it. I guess you mean the comparison of the length against the capacity in ?
(If we want to, we can also rewrite the vec code to use the intrinsic or whatever it's called)
Using will only fix a subset of this problem, because many types are not but still have a trivial implementation.

The bug will still need to remain open if that's the attempted fix.
So I did the pragmatic thing and just made the code itself slightly better. There's no special-casing of types, so it's still fully general. I'm just making sure it still passes the tests now, but the benchmarks on my machine are: Both are done with just .
Change:
// mir. if let Ok(c) = tcx.at(expr.span).lit_to_const(lit_input) { return c; <ins> } else { tcx.sess.delay_span_bug(expr.span, "ast_const_to_const: couldn't lit_to_const"); </ins> } }

Discussion:
I'm seeing an internal compiler error on the following input (found by ): The error happens on and , but not on . <details<summaryNightly backtrace</summary</details
triage: P-high, assigning to self.
(This ended up being a great motivation for me to tie off some work I've been doing...)
ICE was introduced between nightly 2020-01-15 and 2010-01-16. Here are the merges from that time period: ( is independently working to identify which one is the culprit.)
Okay finished: searched nightlies: from nightly-2020-01-15 to nightly-2020-01-22 regressed nightly: nightly-2020-01-16 searched commits: from to regressed commit:
Looks like the problem was injected by PR
reassigning to
The following also causes an ICE: (Same reason, but different message.)
Fixed by
Change:
LL |     Vec::contains(&vec, &0); |          ^^^^^^^^ function or associated item not found in `Vec<_, _>` | <ins> note: if you're trying to build a new `Vec<_, _>` consider using one of the following associated functions: Vec::<T>::new Vec::<T>::with_capacity Vec::<T>::from_raw_parts Vec::<T, A>::new_in and 2 others --> $SRC_DIR/alloc/src/vec/mod.rs:LL:COL </ins> help: the function `contains` is implemented on `[_]` | LL |     <[_]>::contains(&vec, &0);

Discussion:
Consider the following code: This fails with an error that simply states that is not available: The intent is fairly clear: we want to construct a new using a method that follows the for constructors, but that method is not available. Instead the solution is likely to be either or : When is not available it'd be ideal if the compiler could suggest alternatives. A first heuristic for which methods to suggest be methods on the same struct that don't take any params, have as their return type, and aren't implemented through any trait. For this would include and . But not , , and . I'm not too sure how to structure the help message exactly, but I could imagine something along these lines might work: cc/
Seems like es should be to the standard library to fix this.
This seems to be the same as
Closing in favor of that.
For the example I brought up, how would an work? The method does not exist on . So it shouldn't qualify as an alias? Additionally this is intended as an automated mechanism to improve the quality of diagnostics, rather than a manual mechanism (like attributes) which would need to be opted into. While both cases do touch on improving diagnostics for missing methods, I don't think these are equivalent.
No but does exist, so e.g., on it could add the information necessary (see e.g. on ) for the compiler to provide the diagnostic. But I suppose the heuristic you've suggested might work without attributes, although I suspect it would suggest too many false positives, but let's reopen I guess.
what do you think of the following? <img width="779" alt="Screenshot 2023-10-20 at 6 13 57 PM" src=""
oh I love it!