jiebi/CodeConvo huggingface dataset:
Code change:
if let hir::Node::Pat(parent_pat) = cx.tcx.hir().get(cx.tcx.hir().get_parent_node(hid)) { if let PatKind::Struct(_, field_pats, _) = &parent_pat.kind { <del> for field in field_pats.iter() { if field.ident != ident { // Only check if a new name has been introduced, to avoid warning // on both the struct definition and this pattern. self.check_snake_case(cx, "variable", &ident); } </del> <ins> if field_pats .iter() .any(|field| !field.is_shorthand && field.pat.hir_id == p.hir_id) { // Only check if a new name has been introduced, to avoid warning // on both the struct definition and this pattern. self.check_snake_case(cx, "variable", &ident); </ins> } return; }

Related discussion:
text: Here's a minimized version of the code I'm working with: Compiling this on stable or nightly gives a warning on the indicated line, despite the attribute on . A similar issue was reported before in , and addressed in a follow-up PR , but it seems to be cropping up again here, maybe because a non-ASCII field name is involved. It was agreed in that punning of non-snake-case fields in patterns should not produce an additional warning, so I think this is a bona fide bug. (Incidentally, on stable the same warning appears twice in the compiler output, but this duplication seems to be fixed on nightly.) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
It's actually unrelated to the non-ASCII field names; reduced: claim
Thanks
Code change:
assert!(prev_predicates.is_none()); } <del> fn ty_generics_for_type_or_impl<'a, 'tcx>(ccx: &CrateCtxt<'a, 'tcx>, generics: &hir::Generics) -> ty::Generics<'tcx> { ty_generics(ccx, TypeSpace, generics, &ty::Generics::empty()) </del> <ins> fn ty_generics_for_type<'a, 'tcx>(ccx: &CrateCtxt<'a, 'tcx>, generics: &hir::Generics) -> ty::Generics<'tcx> { ty_generics(ccx, TypeSpace, generics, &ty::Generics::empty(), true) } fn ty_generics_for_impl<'a, 'tcx>(ccx: &CrateCtxt<'a, 'tcx>, generics: &hir::Generics) -> ty::Generics<'tcx> { ty_generics(ccx, TypeSpace, generics, &ty::Generics::empty(), false) </ins> } fn ty_generic_predicates_for_type_or_impl<'a,'tcx>(ccx: &CrateCtxt<'a,'tcx>,

Related discussion:
text: If I understand correctly, type parameter defaults have no effect in the block . Just like in PR , this should have a warning and then an error. Example cc
Argh, I guess I failed to cover those?
Nominating for triage.
triage: P-high
Code change:
<ins> // no-system-llvm // compile-flags: -O -C overflow-checks=on #![crate_type = "lib"] pub struct S1<'a> { data: &'a [u8], position: usize, } // CHECK-LABEL: @slice_no_index_order #[no_mangle] pub fn slice_no_index_order<'a>(s: &'a mut S1, n: usize) -> &'a [u8] { // CHECK-NOT: slice_index_order_fail let d = &s.data[s.position..s.position+n]; s.position += n; return d; } // CHECK-LABEL: @test_check #[no_mangle] pub fn test_check<'a>(s: &'a mut S1, x: usize, y: usize) -> &'a [u8] { // CHECK: slice_index_order_fail &s.data[x..y] } </ins>

Related discussion:
text: Godbolt: Basically the issue is that you compute , check that it doesn't overflow, and then you verify that is greater than , which it of course always is, since you checked for an overflow! This is probably an LLVM optimization bug, but I'm starting here :-) Command line arguments: Source: ASM:
Slightly reduced testcase: LLVM does not realize that and are the same here.
Ok, looks like the thing to do is file an LLVM bug -- do you know off hand if they're ok with Rust reproducers, or do they prefer C ones?
Ok, ended up converting to C because that seemed easy:
Submitted additionally for the IR pattern above (which is an issue separate from the missing combining). Just verified that fixing this does indeed eliminate the check in this example.
am I correct in reading that this has been waiting on a review of the LLVM patch?
Needs a rebase. More generally though, I think this is fighting a losing battle. and are not considered canonical IR for a reason: They optimize badly in the middle end. I think we'd be better off with generating the canonical variants instead (which are and ). LLVM will still form during CGP, but this should optimize better in the middle end (including avoiding the issue here). As we already have a good benchmark for the overhead of overflow checks in , I think it might be worth trying to rerun that without using the unsigned overflow intrinsics.
From the :
once this makes it's way into Rust's LLVM (is there a good way to track this?) I'll verify that the assembly in this bug was improved, and if so I'll rebase the rustc patch and we can get some new numbers!
Ok, confirmed that the recent LLVM10 update removes this branch: Shall this be closed?
Actually, that was probably premature. We should add a codegen test.
is there a good example of what a test looks like? I can spin one up pretty easily if someone can point me at how to add one.
Codegen tests are located in . One test that is thematically related: . They use . Codegen tests can be run with:
Thanks much, that's exactly what I needed! PR is up now.
Code change:
expr_span, scope, result, <del> value.ty, </del> <ins> expr.ty, </ins> ); }

Related discussion:
text: mentioned a leak coming from but not , I think I tracked this down to the use of in when given a comma-separated list. I've made that demonstrates it with , if it gets much simpler than this then the leak doesn't occur when built with --release. I'm testing on rustc 1.37.0-nightly ( 2019-06-30) nightly-x8664-pc-windows-msvc, targeting x8664-pc-windows-msvc.
Valgrind Memcheck also reports heap in use at exit on a Linux VM with the test linked above.
Thanks a lot for creating a reduced test case and creating this issue here. I stumbled over the original issue when carg-fuzz reported a memory leak in this code This PR appears to fix the issue This was also with rustc 1.37.0-nightly on Linux. I can check if I can repro with the fuzz test case on other platforms.
Looks like the early return doesn't interact well with box syntax's preallocation. MIR generation issue? cc
should be here: Now that can only schedule drops for locals, we should get the type from to avoid this sort of problem in the future.
Confirmed with my fuzzing test case that the problem is fixed in the latest rust nightly. Thanks for fixing it so quickly.
Code change:
/// # Example /// /// ```rust <ins> /// # #![allow(deprecated)] </ins> /// use url::Url; /// /// let raw = "https://username@example.com:8080/foo/bar?baz=qux#quz";

Related discussion:
text: The common fix for , , and is to rewrite the module based on the spec at and the tests at (Note: the tests assume the API, designed for JavaScript in web browsers. We do not necessarily want the same API for Rust outside of testing code.)
I'm interested in this
I have a work-in-progress implementation. I’ll publish it later today so you can pick it up if you want.
Here it is: Note that I’m targeting Rust , the version used in Servo. (Though there is an upgrade being worked on.) IDNA and the actual URL parser are not there yet, but everything else (host/domain/ipv6, , percent encoding, test harness) is there. This should start being useful as soon as the URL parser is . The host parser returns an error on non-ASCII domains. This is good enough for now, IDNA support can be later. also made an in-progress implementation: It has some known bugs ( is incorrect with non-ASCII input, at least) but the parser code can probably be reused.
Also, be aware that the URL spec itself is still moving and has a number of open bugs:
I Punycode encoding and decoding (with tests) to but not Nameprep, which is the other big part of IDNA.
is now (IMHO) ready to replace . It is not "done" yet (some bugs remain, including in the spec!), but at this point it has more than feature-parity and is probably correct in more corner cases. Given the current tendency to move things out of , rust-url probably shouldn’t move in. It could be distributed with rustc like the rest of the modules moving out of extra, but this has the downside of tying rust-url upgrades to compiler upgrades, and only weak advantages IMO. So, whenever the Rust team decides it’s appropriate, I suggest removing and recommending rust-url as a replacement.
I would generally be in favor of a in the distribution for now. This would certainly not be a package in long-term, but for now putting everything in this repo is the ad-hoc solution we have until we get a real package manager.
In that case, I’d like to iterate a bit on rust-url (port rust-http and Servo to it, …) before it moves into the distribution. Also, rust-url depends on rust-encoding, which I guess would have to move as well.
Code change:
/// # Example /// /// ```rust <ins> /// # #![allow(deprecated)] </ins> /// use url::Url; /// /// let raw = "https://username@example.com:8080/foo/bar?baz=qux#quz";

Related discussion:
text: I’d say rust-url is now in "beta" state. I have branches of rust-http and Servo using it: It builds with Cargo. It depends on rust-encoding (which also builds with Cargo), but for something non-essential that could be deactivated if avoiding the additional dependency helps. I’d like people to start using it and give feedback. I think the best way to do that is to get rid of the old liburl. I’ll go through the RFC process, but before that, what would you prefer? Replace liburl with snapshots[] of rust-url. You were in favor of this in February, but Cargo has reached alpha since then. Just remove liburl, and tell people to use rust-url through Cargo. Something else? [] In any case, I’d like to keep a separate rust-url repository that I can update in Servo independently of language upgrades.
+1 on removing liburl. Thanks
Perhaps we can deprecate all of liburl for one release cycle.
This seems like a great place to let cargo shine.
Deprecating sounds reasonable. That means emitting warnings by default, right?
awesome work! I agree with and that I think this is where cargo shines, and we can probably just remove liburl entirely without re-adding rust-url. We can also try to grow more official support for it in terms of documentation and automation (not present currently). We can mark liburl as with a message to use instead which should ferry everyone along quickly.
Code change:
exact_paths: Default::default(), modules: vec![om], is_importable_from_parent: true, <ins> inside_body: false, </ins> } }

Related discussion:
text: <!-- 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. --Consider the following code is local to and inaccessible, and should not be documented. Instead, rustdoc currently documents the module at the same level as . <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: </details
cc does this have to do with those changes you made to item collection?
Very likely. I won't be able to fix it until next week though. EDIT: I suspect it broke from
I just realized that this is broken on stable, too, so I think the cause may be older than that?
Oh. I'm at least happy to realize that I didn't break it recently. Thanks for the report. Will fix it monday.
Code change:
<ins> #![feature(unsize)] use std::marker::Unsize; use std::ops::Deref; trait Foo: Bar {} trait Bar {} impl<T> Bar for T where dyn Foo: Unsize<dyn Bar> {} impl Bar for () {} //~^ ERROR conflicting implementations of trait `Bar` for type `()` fn main() {} </ins>

Related discussion:
text: <!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'assertion failed: !self.intercrate'', 'thread 'rustc' panicked at 'assertion failed: !self.intercrate'' 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: [specializationgraphof] building specialization graph of trait [coherent_trait] coherence checking all impls of trait -- label +F-Unsize +F-unsize
The bisection looks incorrect? is from 1.77, and this looks to be from 1.72 to me.
Too lazy to look at its PRs :
Due to . This assertion is correct, and we probably shouldn't drop candidates in intercrate mode, since this is incomplete. I would say this fix is low-pri because of the fact that is not expected to be referenced.
Code change:
// seemingly completely unrelated change. // Unfortunately, LLVM has no "disable" option for this, so we have to set // "enable" to 0 instead. // compile-flags:-g -Cllvm-args=-enable-tail-merge=0 // ignore-pretty as this critically relies on line numbers

Related discussion:
text: Symbol names are not properly supported yet on msvc, so backtraces are generally unhelpful. As a result, is currently disabled. This issue can be closed when it's been reenabled.
Code change:
&self.buf } <ins> /// Returns a mutable reference to the internal buffer. /// /// This can be used to write data directly into the buffer without triggering writers /// to the underlying writer. /// /// That the buffer is a `Vec` is an implementation detail. /// Callers should not modify the capacity as there currently is no public API to do so /// and thus any capacity changes would be unexpected by the user. pub(in crate::io) fn buffer_mut(&mut self) -> &mut Vec<u8> { &mut self.buf } </ins> /// Returns the number of bytes the internal buffer can hold without flushing. /// /// # Examples

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:
&self.buf } <ins> /// Returns a mutable reference to the internal buffer. /// /// This can be used to write data directly into the buffer without triggering writers /// to the underlying writer. /// /// That the buffer is a `Vec` is an implementation detail. /// Callers should not modify the capacity as there currently is no public API to do so /// and thus any capacity changes would be unexpected by the user. pub(in crate::io) fn buffer_mut(&mut self) -> &mut Vec<u8> { &mut self.buf } </ins> /// Returns the number of bytes the internal buffer can hold without flushing. /// /// # Examples

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:
&self.buf } <ins> /// Returns a mutable reference to the internal buffer. /// /// This can be used to write data directly into the buffer without triggering writers /// to the underlying writer. /// /// That the buffer is a `Vec` is an implementation detail. /// Callers should not modify the capacity as there currently is no public API to do so /// and thus any capacity changes would be unexpected by the user. pub(in crate::io) fn buffer_mut(&mut self) -> &mut Vec<u8> { &mut self.buf } </ins> /// Returns the number of bytes the internal buffer can hold without flushing. /// /// # Examples

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:
&self.buf } <ins> /// Returns a mutable reference to the internal buffer. /// /// This can be used to write data directly into the buffer without triggering writers /// to the underlying writer. /// /// That the buffer is a `Vec` is an implementation detail. /// Callers should not modify the capacity as there currently is no public API to do so /// and thus any capacity changes would be unexpected by the user. pub(in crate::io) fn buffer_mut(&mut self) -> &mut Vec<u8> { &mut self.buf } </ins> /// Returns the number of bytes the internal buffer can hold without flushing. /// /// # Examples

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:
<ins> #![feature(const_generics)] pub struct Num<const N: usize>; // Braces around const expression causes crash impl Num<{5}> { pub fn five(&self) { } } </ins>

Related discussion:
text: Currently with const generics you can create a "specialized" implementation, such as: Which has the following output: (playground link: ) However, when using such a type in another crate this causes a stack overflow in the compiler. For example, with the following code (full example: ): I would expect it to produce the same output as the playground link above, however it produces the following:
A bisect shows this stopped crashing after , marked as needing a test
I was still encountering this in my code with and after trying to minimize it seems that the original example is fixed but the stack overflow still occurs when the const expression in the has braces around it. After experimenting I found some more examples of what works and what doesn't: (see to try it) compiles and runs successfully while and (or ) crash the compiler with the same error as the original: :
Code change:
} pub fn foobar() {} <ins> pub type Alias = u32; pub struct Foo { pub x: Alias, } impl Foo { pub fn a_method(&self) {} } pub trait Trait { type X; const Y: u32; } impl Trait for Foo { type X = u32; const Y: u32 = 0; } </ins>

Related discussion:
text: It looks like a CSS rule is being applied incorrectly. It also looks weird if you click through to the type alias's page (). ! !
I'm not really sure, could that be slipped in ?
It turns out it was actually much more recent. The PR causing the regression was , cc searched nightlies: from nightly-2021-05-01 to nightly-2021-06-12 regressed nightly: nightly-2021-06-04 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-apple-darwin Reproduce with: </details
The culprit CSS rule is here: It also caused which was fixed by .
Ah, I have missed this one. Sending a fix.
Assigning priority as in the prioritization working group. label: +P-medium -I-prioritize
The fix should be merged in less than 3 hours. ;)
I know, but we had already agreed on a priority :)
Oh I see. Thanks for taking care of that then! :)