jiebi/CodeConvo huggingface dataset:
Code change:
use rustc_hir::intravisit::{self, Visitor}; use rustc_hir::Node; use rustc_middle::bug; <del> use rustc_middle::middle::codegen_fn_attrs::CodegenFnAttrFlags; </del> <ins> use rustc_middle::middle::codegen_fn_attrs::{CodegenFnAttrFlags, CodegenFnAttrs}; </ins> use rustc_middle::middle::privacy::{self, Level}; use rustc_middle::mir::interpret::{ConstAllocation, ErrorHandled, GlobalAlloc}; use rustc_middle::query::Providers;

Related discussion:
text: Ah, the behaviour was working to spec before: So I think I'd agree that is the wrong approach and should be reverted because this currently ends up conflating different things. Maybe changes elsewhere would fix this but I don't want to speculate.
the separate issue you pointed out earlier in is presumably still relevant for ?
Could this explain recent CI flakiness? The failure at and a couple other failed merges (linked on that thread, also the retries) have been msvc linker errors.
That's unfortunate. :/ Our reachable symbol code is such a spaghetti mess... I guess I'll just have to copy-paste more things into Miri then. :shrug: I am traveling right now, I'd appreciate if someone else could do the revert.
The following patch should fix the incorrect internalization I mentioned earlier: As for the question whether those symbols should be exported in the first place, it might be necessary for COFF and . The following code suggests that would not have the desired effect otherwise I don't have access to windows environment at the moment to verify that, so I don't plan to work on this myself.
Ooh this is also the stuff that also broke several ci-runs already ...
Looks like this did not fully fix the ci failures :melting_face:
Makes sense: some CI failures look non-deterministic, while we'd expect this error not to be.
Alternative approach for Miri:
Code change:
} } <del> #[cfg(any(target_arch = "x86_64", target_arch = "arm"))] </del> <ins> #[cfg(not(target_arch = "x86"))] </ins> #[macro_use] mod imp { pub type ptr_t = u32;

Related discussion:
text: The and targets force panic=abort. said : This looks related to , which points at these now-merged LLVM changes: It's possible that we do not need to force panic=abort anymore for arm64 Windows as a result. What's the best way to determine if this is still required?
Theoretically the way to fix this issue is: First Next, run the build Finally, run the tests If that all passes, then the change can land! The tests may be able to be skipped, and some tests may fail, so it may be possible to switch the defaults and we can fixup bugs later. I don't personally have hardware to test these changes on myself, though.
I occasionally have access to a Windows arm64 laptop, so I'll try and get a rustc build going on it at some point.
Code change:
/// } /// ``` #[stable(feature = "rust1", since = "1.0.0")] <ins> #[inline] </ins> pub fn raw_os_error(&self) -> Option<i32> { match self.repr { Repr::Os(i) => Some(i),

Related discussion:
text: I am facing a problem while reading different kinds of binary formats. If you are going to read primitives like too often, then performance degrades. This is mainly due to the fact that returns box. Also it does boxing TWICE! doc link: I wrote simple bench to show pref problem. Use to get it We can clearly see that performance is degrading. The more calls it takes to read, the worse the results will be. The first very popular crate that comes to mind is . It mainly depends on the data format. But what if you need to receive data over the network? The attacker may abuse wrong data to make ton of pointless memory allocations. stdlib is also use often enough. Let's run a simple bash to make sure of this In many cases, you will see that it is used . stdlib sometimes create with macro, however it doesn't happen very often. Consider adding a new static method such as and new internal member of that's enum. How about using something like , but with static lifetime? : Update 07.03.2021: Benchmarks have been improved as per the comment. This should show the problem better.
The "std_err" bench is still pretty slow though
Yes, I probably made a mistake while copying the code for the benchmark of . It should be . However, this shows that not zero-cost.
This is fixed by
Turns out it was three times, if you also count the that the is copied into.
Running your benchmark (thanks!): Before: After: Looks like it isn't completely solved yet. Adding to now... :)
That fixed it.
Code change:
<ins> // revisions: current next //[next] compile-flags: -Znext-solver // check-pass #![feature(non_lifetime_binders)] //~^ WARN the feature `non_lifetime_binders` is incomplete pub trait Foo<T: ?Sized> { type Bar<K: ?Sized>: ?Sized; } impl Foo<usize> for () { type Bar<K: ?Sized> = K; } pub fn f<T1, T2>(a: T1, b: T2) where T1: for<T> Foo<usize, Bar<T> = T>, T2: for<T> Foo<usize, Bar<T> = <T1 as Foo<usize>>::Bar<T>>, { } fn it_works() { f((), ()); } fn main() {} </ins>

Related discussion:
text: <!-- 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. --minimal project with full compiler output can be found here cargo 1.77.0-nightly ( 2024-01-09) : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Code change:
<ins> // Copyright 2016 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // aux-build:plugin.rs #![feature(proc_macro)] #[macro_use] extern crate plugin; #[derive(Foo, Bar)] struct Baz { a: i32, b: i32, } fn main() {} </ins>

Related discussion:
text: Inlined from Another issue. If a struct has two different custom derives on it and the second one panics, the error span will point to the first one, not the one which panicked. Reproduction Script
was "Reproduction Script" supposed to be a link? I'm spinning this off from as I don't think it's going to block stabilization and/or closing that issue.
Reproduction script there is a summary tag
<details<summaryReproduction Script</summaryIn a crate called In another crate The error will highlight even though panicked. </details
This seems to be fixed now, so this issue can be closed.
I ran this as a test, and got the following output:
Code change:
/// "successfully written" (by returning nonzero success values from /// `write`), any 0-length writes from `inner` must be reported as i/o /// errors from this method. <del> pub(super) fn flush_buf(&mut self) -> io::Result<()> { </del> <ins> pub(in crate::io) fn flush_buf(&mut self) -> io::Result<()> { </ins> /// Helper struct to ensure the buffer is updated after all the writes /// are complete. It tracks the number of written bytes and drains them /// all from the front of the buffer when dropped.

Related discussion:
text: I was using std::io::copy from an SSD to memory using , which reported an eye-raising 30 MB/s. Wrapping it in a BufReader (either as the outer or middle layer) made no real difference. So I googled around a bit and found the recommended size was 64KB according to some random Microsoft article, so I decided to copy-paste the std::io::copy implementation and increase the buffer size. This got up to 600 MB/s at about 256KB which sounded a lot more it continued going upwards from there past the point of believability (unless the files were being pulled from RAM as a consequence of my repeated accesses). With a 10MB Vec, I got 228.36 GB/s . Unrealistic values aside, has anybody checked the buffer value to make sure there isn't some huge low-hanging fruit for std::io::copy speeds?
You mention windows. This may be platform-specific behavior. On unix systems I would fadvise on the input file for copying. Googling tells me that the windows equivalent is . Have you tried that?
After a coarse overview, my intuition is that there is some funny business going on with the length determined by and the subsequent calls on the , that could explain the unrealistic results.
It’s possible. The actual times did increase dramatically from the std::io::copy default though - my suspicion is that there is probably some caching to RAM going on or something as cold runs were generally slower than hot runs. This was for some work code that I’m no longer actively developing. I’ll leave this email marked as unread for awhile in case I have some spare time to write a benchmark. I don’t think the other flag that was mentioned is accessible with the default open file api, but in any case it at least appears there’s some low hanging fruit wrt to std::io::copy perf
I tried benchmarking on Windoze before and after changing to (instead of the original ) and the results were slightly worse (up to ~3%) with the modified setup, both on HDD and SSD. However, I'm not sure if my benchmarks were good enough - I was having a hard time tweaking them so that I could see any difference between results for different file sizes.
Code change:
/// "successfully written" (by returning nonzero success values from /// `write`), any 0-length writes from `inner` must be reported as i/o /// errors from this method. <del> pub(super) fn flush_buf(&mut self) -> io::Result<()> { </del> <ins> pub(in crate::io) fn flush_buf(&mut self) -> io::Result<()> { </ins> /// Helper struct to ensure the buffer is updated after all the writes /// are complete. It tracks the number of written bytes and drains them /// all from the front of the buffer when dropped.

Related discussion:
text: FWIW, I'm providing the benchmark code below; it can easily be expanded to different file sizes:
4MB isn’t a whole lot. That’s well within the size of hard drive caches or possibly an OS memory-based cache. I was noticing the difference with files several gigabytes in size. As a sanity check, maybe look to see what the actual time is, not just the % difference between timings with different buffer sizes. The actual time may be wildly different than the actual steady state performance of the disk if it’s reading the data from a cache. It may also be possible at a low level to pass a flag to encourage the OS to disable or flush the cache, but I don’t know if there’s any way to instruct the hard drive to do the same.
I only pasted the benchmark for 4MB as a reference - I tested files from 4KB up to 16MB. I'm not an expert with low-level hard drive stuff, just hoping my attempt can help someone else.
Ideally you would test with a file approximately twice as big as you have RAM, so if you have 8GB of RAM you would want to test with a 16GB file.
extended open flags are accessible via FWIW lots of bennchmarks exist showing synchronous IO calls improve when matching IO operations to the underlying block size (e.g. 4MB for modern SSD's) across multiple OS's, so its very likely that there are improvements to gain here. However, 4MB is stack-breaking size by default, and heap allocations will destroy potential improvements (and further, if we're optimising, we probably want overlapped IO and a ring of buffers rather than just one buffer which will always leave one device idle).... so its complex;)
heap allocations will destroy potential improvements How come? would allocate once at the beginning. Heap memory isn't inherently slower and one memory allocation is basically free compared to the heavy IO that's happening afterwards.
But we also don't want to be allocating 4MB every time we do as someone might be doing a bunch of small copies.
Code change:
/// "successfully written" (by returning nonzero success values from /// `write`), any 0-length writes from `inner` must be reported as i/o /// errors from this method. <del> pub(super) fn flush_buf(&mut self) -> io::Result<()> { </del> <ins> pub(in crate::io) fn flush_buf(&mut self) -> io::Result<()> { </ins> /// Helper struct to ensure the buffer is updated after all the writes /// are complete. It tracks the number of written bytes and drains them /// all from the front of the buffer when dropped.

Related discussion:
text: possible approaches: thread local buffers or a buffer pool stat the input before deciding on the buffer size (this is what gnu cp does I think) heap-allocate a bigger buffer after a few iterations of the copy loop with an on-stack buffer specialize copy operations from file to memory to directly into the already allocated target, thus skipping the need for a buffer
specialize copy operations from file to memory to directly into the already allocated target, thus skipping the need for a buffer I think some kind of specialization for sources would be ideal. Because in this case, should not buffer at all and simply use the reader's buffer. Effectively this also gives you a customizable buffer size by wrapping your in a with whatever size you want. As of today, if your source is then is always the wrong answer. I got a substantial performance improvement using a simple loop instead:
a single heap allocation is entirely reasonable for a single invocation of copy of a lot of data. For many copies of a small amount of data, one ends up with a lot of allocations again (consider for instance copying data out of a tar, where we have views on the data and there's no actual synchronous IO etc happening. I like some of the suggested possibilities with specialisation.
It's a nice general optimization, but not necesarily ideal if you use a as . Adding a on the reader size does let you control the buffer size but it still introduces an unnecessary memcopy compared to . Perhaps a writer-side optimization would be more flexible. Then you can specialize either for or
That sounds rather uncommon to me though. After all, is provided by the trait so it's always available. The only case I can see where you would invoke with a as destination is some generic interfaces that takes any . But IMO such interfaces are ill-designed, as they could simply implement instead and offer a much more flexible API.
yes, generic code taking a write was the concern. E.g. tar-rs has a tar archive which takes a and is fed with items. I'm not saying that creating an in-memory archive would be a good idea, just pointing out that these patterns do exist.
I had same kind of issue but with different library (). The copy rate was around 70 MB/s (inside single NVMe SSD). The problem was actually with running the debug version of my program.
Code change:
/// "successfully written" (by returning nonzero success values from /// `write`), any 0-length writes from `inner` must be reported as i/o /// errors from this method. <del> pub(super) fn flush_buf(&mut self) -> io::Result<()> { </del> <ins> pub(in crate::io) fn flush_buf(&mut self) -> io::Result<()> { </ins> /// Helper struct to ensure the buffer is updated after all the writes /// are complete. It tracks the number of written bytes and drains them /// all from the front of the buffer when dropped.

Related discussion:
text: When I built and ran the release version, the speed jumped to over 1 GB/s.
With merged you can now (on next nightly) use to control the chunk size of . Since this relies on specialization it only works if you pass a directly, any other wrapper around it would disable this optimization.
Code change:
} let size = ret.layout.size; let bits = size.bits(); <del> if bits <= 128 { </del> <ins> if bits <= 256 { </ins> let unit = if bits <= 8 { Reg::i8() } else if bits <= 16 {

Related discussion:
text: I have an issue with rust (now version 1.22.1) on Solaris sparc (64bit). On intel I don't see it. I originally see it as part of Firefox build () I now believe it's rustc issue (though it could be still issue with clang-sys). Any help would be greatly appreciated. Run output looks like: Stack: With tracing: Note that clanggetTranslationUnitCursor isn't called with 'tu' set to 0. I have find out that the issue seems to be with the size of CXCursor structure which is returned: CXCursor is 32 bytes long. But if I tell clang-sys it's 16 bytes everything is perfect (when it's 17 bytes or more it causes the trouble): Following is disassembly when CXCursor is pretended to be just 16 bytes: And now with 17 bytes:
I wrote more minimalistic version of test case which rules out use of clang-sys. On intel it works as expected: But on sparc it looks weird: But with this "hack" it looks better:
Ok. I'm new to both Rust and LLVM. I tried to create for above example llvm-ir data on intel and used llc to build it on sparc. The same result could be seen. Does it mean that that issue is rather in LLVM?! On intel I did: On Sparc I did: The output is bad. See comment above (). [1]
and are wrong; structs up to 32 bytes in size, i.e. 256 bits, are returned in registers. I was also suspicious of this code in general when it was first merged as it doesn't seem very long, and handling mixed float and int structs is a little fiddly. EDIT: Well, actually, should vary based on whether it's an argument (which can be up to 16 bytes) or return value (up to 32 bytes).
Can you please suggest how to implement this? I can confirm that when modifying to contain 256 my above test examples passes as expected (though Firefox still wouldn't build).
As mentioned above. With partial fix Firefox build dies later when it calls . Which takes three arguments and the problematic first one is again 32 bytes long structure ().
Maybe you can suggest a preliminary patch to at least improve the code generation?
Are you sure?
Code change:
} let size = ret.layout.size; let bits = size.bits(); <del> if bits <= 128 { </del> <ins> if bits <= 256 { </ins> let unit = if bits <= 8 { Reg::i8() } else if bits <= 16 {

Related discussion:
text: That doesn't entirely control whether a is passed by value or indirectly, but specifically it handles s which the ABI treats like arrays of primitives (incl. SIMD vectors).
Code change:
<ins> error: missing `in` in `for` loop --> $DIR/issue-40782.rs:12:10 | 12 |     for i 0..2 { |          ^ help: try adding `in` here error: aborting due to previous error </ins>

Related discussion:
text: Hello, with rustc 1.17.0-nightly ( 2017-03-22), the following code gives this error message: An improved error message could add a hint :
Current output: 1) How would you want to improve upon this? Adding a suggestion? 2) To do so, we could use the same strategy as in : in , try to continue building the expression as if the keyword had been found. If we find further errors, we revert the state of the compiler to right after trying to continue and return the error from . Otherwise we cancel that one and create a new custom diagnostic: 3) or just modify the existing error with the proposed (so it looks like the 2 above). []:
Looks like current output already is an improvement over the reported one, but eithwr 2 or 3 would make it even more obvious i guess. No strong opinions here
Seems to me that the third error is the most clear ("error: missing in loop"); I suspect people using fancy pattern features will figure out what's going on.
Code change:
if !types.is_empty() { write!(w, " <del> <h2 id='associated-types'>Associated Types</h2> </del> <ins> <h2 id='associated-types' class='section-header'> <a href='#associated-types'>Associated Types</a> </h2> </ins> <div class='methods'> ")?; for t in &types {

Related discussion:
text: A page like has many things that could be useful to link to. These should be possible to link to by clicking on: [x] The header [x] 's on a page. [x] at the top On it's hit or miss: [x] Examples [x] Associated Types [x] Required Methods [x] Implementors On [x] Provided Methods I don't have any big use cases but when I want to link to these for something like this bug I can't link to any specific line. I gotta say go to vec page, scroll 75% to bottom. Squint hard to see it.
Just ran into this today; I'd really like to have links from the impls in the Implementors section to the source containing the impl.
Triage: we always need more links....
Update: Headers written in docs and (most) auto-generated headers are either fully hyperlinked or have a "section marker" symbol that shows up on hover. Major auto-generated page headers have links in the top of the sidebar of the page. Impl blocks do not have hyperlinks (yet); that's
Since got merged and closed out , that was the last major request on this issue, so i'll close this out. If you think of something else that needs a hyperlinked header, feel free to open a new issue or reopen this one.
Code change:
|| found_assoc(tcx.types.u64) || found_assoc(tcx.types.u128) || found_assoc(tcx.types.f32) <del> || found_assoc(tcx.types.f32); </del> <ins> || found_assoc(tcx.types.f64); </ins> if found_candidate && actual.is_numeric() && !actual.has_concrete_skeleton()

Related discussion:
text: This line looks like a typo to me, should it be ? Originally posted by in Currently, it affects line 1684. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Yeah, this could be fixed.
Ideally a test should also be crafted that shows that this missing affects an error message or something.
claim
Code change:
if v.is_ascii() { bytes.push(cx.expr_u8(expr.span, v as u8)); } else { <del> cx.span_err(expr.span, "non-ascii char literal in bytes!") </del> <ins> cx.span_err(expr.span, "non-ascii char literal in bytes!"); err = true; </ins> } } <del> _ => cx.span_err(expr.span, "unsupported literal in bytes!") </del> <ins> _ => { cx.span_err(expr.span, "unsupported literal in bytes!"); err = true; } </ins> }, <del> _ => cx.span_err(expr.span, "non-literal in bytes!") </del> <ins> _ => { cx.span_err(expr.span, "non-literal in bytes!"); err = true; } </ins> } } <ins> // For some reason using quote_expr!() here aborts if we threw an error. // I'm assuming that the end of the recursive parse tricks the compiler // into thinking this is a good time to stop. But we'd rather keep going. if err { // Since the compiler will stop after the macro expansion phase anyway, we // don't need type info, so we can just return a DummyResult return DummyResult::expr(sp); } </ins> let e = cx.expr_vec_slice(sp, bytes); <ins> let e = quote_expr!(cx, { static BYTES: &'static [u8] = $e; BYTES}); </ins> MacExpr::new(e) }

Related discussion:
text: (I actually think we should allow statics to include nested blocks with other statics, but I guess that's a separate bug) Well, I'm not sure what's the easiest fix in that case, I guess just to fix the semantics of so that it guarantees static data. I'm not 100% sure what's implied by such a fix: it doesn't seem too hard ;)
cc
Code change:
let fs = fields.move_map(|f| { Spanned { span: folder.new_span(f.span), node: ast::FieldPat { <del> ident: f.node.ident, </del> <ins> ident: folder.fold_ident(f.node.ident), </ins> pat: folder.fold_pat(f.node.pat), is_shorthand: f.node.is_shorthand, }}

Related discussion:
text: Test case: Compiles successfully on , causes an ICE on . Diff contains only , CC Found while trying to minimize , but filed separately since the error message is different and this one has a small test case.
Do you have a backtrace?
Yes of course. Sorry I forgot to include it: rust error: internal compiler error: attempted .defid() on invalid def: Err note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: note: run with for a backtrace thread 'rustc' panicked at 'Box<Any',