jiebi/CodeConvo huggingface dataset:
Code change:
- checkout: self fetchDepth: 2 <ins> # Set the SKIP_JOB environment variable if this job is supposed to only run # when submodules are updated and they were not. The following time consuming # tasks will be skipped when the environment variable is present. - ${{ if parameters.only_on_updated_submodules }}: - bash: | set -e # Submodules pseudo-files inside git have the 160000 permissions, so when # those files are present in the diff a submodule was updated. if git diff HEAD^ | grep "^index .* 160000" >/dev/null 2>&1; then echo "Executing the job since submodules are updated" else echo "Not executing this job since no submodules were updated" echo "##vso[task.setvariable variable=SKIP_JOB;]1" fi displayName: Decide whether to run this job </ins> # Spawn a background process to collect CPU usage statistics which we'll upload # at the end of the build. See the comments in the script here for more # information.

Related discussion:
text: This issue is meant to track where on Travis we currently whenever the commit message looks like it updates a submodule. We should enable something similar for Azure Pipelines where whenever a PR is detected as updating a submodule (either via actually looking at the git history or at the git commit message) then we schedule the builder on the PR. The purpose of this PR build is to help weed out errors even sooner than before where we're just running a smoke tests on Linux on each PR.
Code change:
<ins> // ignore-tidy-linelength // FIXME: this doesn't test as much as I'd like; ideally it would have these query too: // has task_lists/index.html '//li/input[@type="checkbox" and disabled]/following-sibling::text()' 'a' // has task_lists/index.html '//li/input[@type="checkbox"]/following-sibling::text()' 'b' // Unfortunately that requires LXML, because the built-in xml module doesn't support all of xpath. // @has task_lists/index.html '//ul/li/input[@type="checkbox"]' '' // @has task_lists/index.html '//ul/li/input[@disabled]' '' // @has task_lists/index.html '//ul/li' 'a' // @has task_lists/index.html '//ul/li' 'b' //! This tests 'task list' support, a common markdown extension. //! - [ ] a //! - [x] b </ins>

Related discussion:
text: These include: The reasoning for all of these extensions is that they all have wide use not just in GitHub, but in many applications of Markdown.
I'm not sure if automatically creating links from bare domain names is a good idea, so if there's an option to disable that specifically I'd suggest it. The rest all seems fine to me.
Just like said for Autolinks. I'm also not sure to see the point of the task list one. However, adding strikethrough would be nice.
Tasklist would be useful for things like this: [x] Implemented thing [x] Some other implemented thing [ ] Unimplemented thing [ ] Some other unimplemented thing or possibly in the crate root [x] Webhooks [x] Websockets [ ] Websites [ ] Other
Another noteworthy extension to implement is . This would prevent the following tags from being used for safety reasons: - - - - -
We decided in not to add this. Instead rustdoc will now suggest to turn raw links into automatic links (). So I think the only thing left is adding task list parsing.
Code change:
needs_codegen_cfg } <del> const CODEGEN_BACKEND_PREFIX: &str = "rustc_codegen_"; </del> <ins> pub(crate) const CODEGEN_BACKEND_PREFIX: &str = "rustc_codegen_"; </ins> fn is_codegen_cfg_needed(path: &TaskPath, run: &RunConfig<'_>) -> bool { if path.path.to_str().unwrap().contains(&CODEGEN_BACKEND_PREFIX) {

Related discussion:
text: I tried this code: I expected to see this happen: An error saying that is invalid and should be instead. Instead, this happened: <!-- 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. --HEAD is branched from <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Code change:
) } <del> fn base_expr<'a>(mut expr: &'a hir::Expr<'a>) -> &'a hir::Expr<'a> { loop { match expr.kind { hir::ExprKind::Field(base, ..) => expr = base, _ => return expr, } } } </del> struct MarkSymbolVisitor<'tcx> { worklist: Vec<hir::HirId>, tcx: TyCtxt<'tcx>,

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. --Here's a reduced test-case from Firefox source code: Compiling that program warns with: Which is obviously not true. <!-- 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. --:
Seems like this is a regression from .
cc
Oops, sorry! Technically, field is, in fact, never read. What went wrong is is written and read through other ways. I think restricting the lint to non-reference fields should work, and will submit a PR to do so quickly. Please double check whether my thinking is correct.
Ah, yeah, I somehow thought that the macro was needed to trigger the bug but it is not. That sounds good. Writes to mutable references have side effects so doing that seems ok.
Would that also cover this case here, in the idna crate? (The field is a reference to an type, which is in fact returned to the caller of .)
Yeah, I think it's the same.
Ah, this was closed, but the bug leaked into beta (as mentioned in ) while the fix is only in nightly. Reopening and tagging as stable-to-beta regression
Assigning and removing .
As noted on , we're going to resolve the beta issue by reverting PR on beta (which I have assigned myself to take care of).
This was a regression affecting beta 1.51, closing this.
Code change:
fn visit_expr(&mut self, e: &'gcx hir::Expr) { self.fix_scalar_builtin_expr(e); <ins> self.fix_index_builtin_expr(e); </ins> self.visit_node_id(e.span, e.hir_id);

Related discussion:
text: Hello, today we've found some weird behaviour of array indexing. Here is the Code snippet: The question is, why is the indexing operator behaves depending on whether we evaluate in place or not.
Highly related question :
Moreover, does not compile too.
points to this being a difference in how builtin indexing works vs overloaded indexing. My cleaned up version of the transcript: Highly related to , which will cause these types of situations to occur more frequently.
As a workaround, you can write an explicit type of which will then allow builtin indexing to happen:
Code change:
fn visit_expr(&mut self, e: &'gcx hir::Expr) { self.fix_scalar_builtin_expr(e); <ins> self.fix_index_builtin_expr(e); </ins> self.visit_node_id(e.span, e.hir_id);

Related discussion:
text: It appears that when it's not obvious the index type is , we fall back to overloaded indexing: Fails in constant checking, : And also with the new MIR-based constant checker, :
Code change:
<ins> fn main() { todo!(); } fn other(_: i32)) {} //~ ERROR unexpected closing delimiter: `)` </ins>

Related discussion:
text: See: This code: produces on latest stable (1.61.0).
Maybe we could form a heuristic around tokens that we know should eventually be followed by -- , , , etc. If we see one of those, (then some random other tokens), then we see , then that would be a suspicious rbrace which we could point out later.. e.g. if we see that triggers the heuristic, but not
The problem is that the error happens in the lexer, not the parser. Ideally we'd rework the lexer to have a token stream mode of operation instead of a token tree mode of operation, only for code that is being passed to the parser (i.e., not coming from a macro).
This is particularly confusing when the points to a macro: gives on 1.65.0-nightly (2022-08-31 )
the output now changed to: Do you think the should be removed?
This is changed to: it seems more helpful now.
Let's close this ticket after adding these two cases to the test suite then. I'm sure there are outstanding issues in this area, but we can hope that we'll get tickets for those more specific cases, while the tests keep us from regressing silently (hopefully, lets make sure the tests are fully annotated so its harder to do that by accident).
Code change:
error: missing fragment specifier <del> --> $DIR/macro-match-nonterminal.rs:2:8 </del> <ins> --> $DIR/macro-match-nonterminal.rs:2:6 </ins> | LL |     ($a, $b) => { <del> |        ^ </del> <ins> |      ^^ </ins> error: missing fragment specifier <del> --> $DIR/macro-match-nonterminal.rs:2:8 </del> <ins> --> $DIR/macro-match-nonterminal.rs:2:6 </ins> | LL |     ($a, $b) => { <del> |        ^ </del> <ins> |      ^^ </ins> | = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release! = note: for more information, see issue #40107 <https://github.com/rust-lang/rust/issues/40107>

Related discussion:
text: Here's some code incorrectly defining a macro, because it's missing a fragment specifier. Here's the error message rustc gives me: It's potentially confusing that the error points to the source after the name with the missing fragment specifier. Especially in a complicated macro, it would be better if it pointed to the item which was actually missing the fragment specifier. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Some more context at
Code change:
/// /// # Examples /// <del> /// Converts an <code>Option<[String]></code> into an <code>Option<[usize]></code>, preserving /// the original. The [`map`] method takes the `self` argument by value, consuming the original, /// so this technique uses `as_ref` to first take an `Option` to a reference /// to the value inside the original. </del> <ins> /// Calculates the length of an <code>Option<[String]></code> as an <code>Option<[usize]></code> /// without moving the [`String`]. The [`map`] method takes the `self` argument by value, /// consuming the original, so this technique uses `as_ref` to first take an `Option` to a /// reference to the value inside the original. </ins> /// /// [`map`]: Option::map /// [String]: ../../std/string/struct.String.html "String" <ins> /// [`String`]: ../../std/string/struct.String.html "String" </ins> /// /// ``` /// let text: Option<String> = Some("Hello, world!".to_string());

Related discussion:
text: url: function: asref() Examples: Perhaps I'm just confused, but shouldn't that say: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Transferring to the rust-lang/rust repository, as that is where the standard library documentation is. I think it is trying to illustrate the conversion from → → . The text is just eliding the middle step, and explaining where it is starting from and where it is finishing.
No, that seems fine; what confuses you (or leads you to the &str conclusion)? I could follow but not . Perhaps you're thinking the impl on would make the contain or such?
I guess I'm extremely confused then. If I have an , what good does an do me? If I have &Some( "fubar" ), how does that translate to a usize? Is it giving me the length of the string or it's pointer in memory? Neither seems useful nor relevant to the description of "Converts from &Option<Tto Option<&T.".
You can call . just describes the example code's functionality, not 's. It's showing one of the ways you could use .
Okay, sorry, I understand now that comment is talking about the upcoming example instead of discussing as_ref() in general. In order to help others not experience the same confusion I did, perhaps I could suggest a tweak to the wording, such as: ?
memory address
claim
Code change:
if let Some(&(_, res)) = rib.bindings.get(&normalized_ident) { self.record_lifetime_res(lifetime.id, res, LifetimeElisionCandidate::Named); <del> if let LifetimeRes::Param { param, .. } = res { </del> <ins> if let LifetimeRes::Param { param, binder } = res { </ins> match self.lifetime_uses.entry(param) { Entry::Vacant(v) => { debug!("First use of {:?} at {:?}", res, ident.span);

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. --I tried this code: : I expected to see this happen: explanation suggestion compiles: Instead, this happened: explanation Suggestion does not compile: ` <!-- 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. --:
Code change:
B: TrustedRandomAccess + Iterator, { fn new(a: A, b: B) -> Self { <del> let len = cmp::min(a.size(), b.size()); Zip { a, b, index: 0, len } </del> <ins> let a_len = a.size(); let len = cmp::min(a_len, b.size()); Zip { a, b, index: 0, len, a_len } </ins> } #[inline]

Related discussion:
text: Here is called for potential side effects until , ignoring however that it could have already been called in with those indexes. that demonstrates how this can be exploited to get two mutable references to the same data and cause an use-after-free bug.
Assigning as part of the .
The gift that keeps on giving Maybe it is time to get rid of as it exists today and replace it with a ? One that imposes the additional requirement on the caller that it must bring the iterator back into a safe state after it is done iterating. The upside would be eliminating a lot of code in and enabling the same optimization for and similar sources. While the downside would be that external iteration (i.e. loops and manual calls to ) would cease to benefit from optimizations and only internal iteration methods (including ) would continue to do so.
I don't know, I feel like that would just make more complex to upheld the invariants. IMO a good improvement over the current would be separating forward and backward iteration, this way it becomes easier to keep track of the state and I think would also make it possible to implement them for
I don't see how separating the forward and backward state would help with a drop implementation. The issue is that the source () currently does not have access to that state, instead the consumer drives the iteration by direct access through and never informs the source about it.
It would help because it allows the source iterator to keep track of its state by updating it when the method is called. Anyway, looks like someone already and it resulted in worse optimizations, but maybe LLVM got better in the meantime, or maybe that implementation could have been better. Anyway I don't think this is the right place to discuss this, a topic on zulip would probably be better.
https://rust-
Code change:
let mut head = self.head.index.load(Ordering::Acquire); let mut block = self.head.block.load(Ordering::Acquire); <ins> // If we're going to be dropping messages we need to synchronize with initialization if head >> SHIFT != tail >> SHIFT { // The block can be null here only if a sender is in the process of initializing the // channel while another sender managed to send a message by inserting it into the // semi-initialized channel and advanced the tail. // In that case, just wait until it gets initialized. while block.is_null() { backoff.spin_heavy(); block = self.head.block.load(Ordering::Acquire); } } </ins> unsafe { // Drop all messages between head and tail and deallocate the heap-allocated blocks. while head >> SHIFT != tail >> SHIFT {

Related discussion:
text: The unbounded channel implementation from can segfault due to what looks like a race condition when dropping channel senders and receivers. You can find a repro at Unfortunately it is not minimal at all, since it depends on the timely-dataflow crate, which is the actual channel user. I hope it is still self-contained enough that people familiar with the channel implementation can run it and use it as a starting point for debugging. Run the example like this: On some machines it will segfault after some time, e.g.: The segfault happens inside , as visible in the gdb backtrace below. The same segfault also happens with . You can reproduce this by reverting the second-to-last commit on the repro branch. I understand that is a port of , so that's not surprising. : I can reproduce the segfault on nightly as well. The segfault is not reproducible on all machines! We were able to reproduce it on: a c5.2xlarge EC2 instance running Ubuntu an AMD Threadripper Thinkpad running Debian an Intel i5-8250U Dell XPS 13 running Arch Linux It doesn't seem to reproduce on: an M1 MacBook Pro Also note that the repro is using more and more memory over time. That is because the different worker threads create and drop dataflows at different speeds and timely-dataflow keeps per-dataflow communication state (including channels) around until the last worker has dropped the dataflow. It is possible to avoid that by adding a that lets late workers catch up, but in my experience that also stops the segfault from happening. <details<summaryBacktrace</summary<p</p</details
Here are the results of some initial investigation I have been doing. I used , but I assume the results will apply to the std port as well: The segfault happens in . In the linked line, is a null pointer, and so is . It seems like there is an inconsistency between the channel's and . is pointing to nothing while points to a block. I observed the following variable assignments at the time of the segfault: If I change all the atomic orderings in to , the segfault still occurs. This suggests that the issue is not caused by the usage of too-weak orderings. If I add an after , it is triggered under the repro.
Code change:
let mut head = self.head.index.load(Ordering::Acquire); let mut block = self.head.block.load(Ordering::Acquire); <ins> // If we're going to be dropping messages we need to synchronize with initialization if head >> SHIFT != tail >> SHIFT { // The block can be null here only if a sender is in the process of initializing the // channel while another sender managed to send a message by inserting it into the // semi-initialized channel and advanced the tail. // In that case, just wait until it gets initialized. while block.is_null() { backoff.spin_heavy(); block = self.head.block.load(Ordering::Acquire); } } </ins> unsafe { // Drop all messages between head and tail and deallocate the heap-allocated blocks. while head >> SHIFT != tail >> SHIFT {

Related discussion:
text: This is where the sender is advancing and it seems plausible that this is the place where the inconsistency between and described above is introduced. I couldn't figure out why becomes a null pointer. The same method makes sure that the head is allocated previously, so some other thread must set it to null after the check.
cc
This suggests that the issue is not caused by the usage of too-weak orderings. I wouldn't be so quick to write off an ordering issue, the race condition could require stronger synchronization to fix (e.g. fences).
The segfault did occur (after about 5 minutes of runtime) on my Macbook Pro with an Intel Core i7 processor running macOS 13.3 and rustc 1.68.2. So whatever is causing this, it's not exclusive to Linux.
I have a feeling the issue is to do with a CAS failure when updating the tail not synchronizing with the update to head. If the thread that actually makes the update is preempted, the second thread might continue with the assumption that head has been updated, which might matter if it quickly writes to the entire block and the channel is disconnected before the head is ever touched. I haven't verified if this is possible, but it would be extremely rare if it is, which explains why this issue hasn't been hit before.
Code change:
<ins> - // MIR for `main` before DeadStoreElimination + // MIR for `main` after DeadStoreElimination fn main() -> () { let mut _0: ();                      // return place in scope 0 at $DIR/place_mention.rs:+0:11: +0:11 let mut _1: (&str, &str);            // in scope 0 at $DIR/place_mention.rs:+3:18: +3:36 scope 1 { } bb0: { StorageLive(_1);                 // scope 0 at $DIR/place_mention.rs:+3:18: +3:36 _1 = (const "Hello", const "World"); // scope 0 at $DIR/place_mention.rs:+3:18: +3:36 // mir::Constant // + span: $DIR/place_mention.rs:8:19: 8:26 // + literal: Const { ty: &str, val: Value(Slice(..)) } // mir::Constant // + span: $DIR/place_mention.rs:8:28: 8:35 // + literal: Const { ty: &str, val: Value(Slice(..)) } PlaceMention(_1);                // scope 0 at $DIR/place_mention.rs:+3:18: +3:36 StorageDead(_1);                 // scope 0 at $DIR/place_mention.rs:+3:36: +3:37 _0 = const ();                   // scope 0 at $DIR/place_mention.rs:+0:11: +4:2 return;                          // scope 0 at $DIR/place_mention.rs:+4:2: +4:2 } } </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. --I tried this code: You need edition 2015 or 2018 to reproduce this. `
Looks to me like the problem is that doesn't realize that a makes the place not dead.
The bug is . is a nonuse, but should get the same treatment as a . I feel obligated to mention that I have repeatedly warned that these bugs are going to happen. We should really stop using in optimizations. It was written for borrowck. (To be clear: I am as much at fault for this as anyone, I originally wrote this code).
I was wondering why always has strangely unhelpful information for optimizations...
Why is this not just a bug in PlaceContext assignment?
See my comment in the PR - in general, my understanding is that the definition of placecontext is what it is because that's what makes sense in some other part of the compiler. If we start changing placecontext now to have the information that's useful to optimizations, I worry we'll just end up making those parts of the compiler buggy
Code change:
target = if let Some(cached_block) = free_data.cached_block { cached_block } else { <del> let t = build_free(tcx, cfg, unit_temp, free_data, target); free_data.cached_block = Some(t); t </del> <ins> let into = cfg.start_new_cleanup_block(); cfg.terminate(into, build_free(tcx, unit_temp, free_data, target)); free_data.cached_block = Some(into); into </ins> } };

Related discussion:
text: This generates the following (broken) MIR: As you can see, is dropped but never written to (AFAIK this should be OK because of zeroing) but the boxes are never freed.
cc
EDIT: I wasn’t looking closely enough, it is indeed broken.
This is a problem on latest master ()