jiebi/CodeConvo huggingface dataset:
Code change:
Currently requires the failure ordering to "be equivalent to or weaker than a success ordering". On the other hand C11/C++11 requires only that "failure shall be no stronger than the success", which arguably means that one can write e.g. in C/C++ but not in Rust. Arguably, because neither C11 standard nor C++11 standard defines what it means for an ordering to be stronger from another. When the issue was raised in [LWG2445], the proposed and accepted resolution was to lift those restrictions altogether, leaving only requirement that "the failure argument shall not be nor ". It would be beneficial to remove success/failure ordering restrictions for reasons described in C++ proposal [P0418r2]. [LWG2445]: [P0418r2]: EDIT: Restrictions were lifted in clang & LLVM:
Blocked on The cmpxchg release acquire is accepted by LLVM but miscompiled on AArch64.
I'm about to send a PR that implements this.
I do have implementation ready as well, but that's fine, I can review instead :-).
I split it in a PR that renames the intrinsics first, and a separate PR for exposing the new ordering combinations afterwards.
Looks like llvm 12 doesn't support this: Can we make things conditionally fall back to a stronger ordering depending on the llvm version? I don't think we do anything like that in the library right now, but maybe the compiler already does things differently for different llvm versions?
Ah yes, some code checks . I suppose Builder::atomic_cmpxchg could check the same, and upgrade the ordering if necessary in that case.
Did exactly that in
To do: [x] Add codegen test. [x] Publicly expose the new orderings. [x] Update memory order lint to accept the new orderings.

Related discussion:
text: /// `failure` describes the required ordering for the load operation that takes place when /// the comparison fails. Using [`Acquire`] as success ordering makes the store part /// of this operation [`Relaxed`], and using [`Release`] makes the successful load <del> /// [`Relaxed`]. The failure ordering can only be [`SeqCst`], [`Acquire`] or [`Relaxed`] /// and must be equivalent to or weaker than the success ordering. </del> <ins> /// [`Relaxed`]. The failure ordering can only be [`SeqCst`], [`Acquire`] or [`Relaxed`]. </ins> /// /// **Note:** This method is only available on platforms that support atomic /// operations on `u8`.
Code change:
Currently requires the failure ordering to "be equivalent to or weaker than a success ordering". On the other hand C11/C++11 requires only that "failure shall be no stronger than the success", which arguably means that one can write e.g. in C/C++ but not in Rust. Arguably, because neither C11 standard nor C++11 standard defines what it means for an ordering to be stronger from another. When the issue was raised in [LWG2445], the proposed and accepted resolution was to lift those restrictions altogether, leaving only requirement that "the failure argument shall not be nor ". It would be beneficial to remove success/failure ordering restrictions for reasons described in C++ proposal [P0418r2]. [LWG2445]: [P0418r2]: EDIT: Restrictions were lifted in clang & LLVM:
Blocked on The cmpxchg release acquire is accepted by LLVM but miscompiled on AArch64.
I'm about to send a PR that implements this.
I do have implementation ready as well, but that's fine, I can review instead :-).
I split it in a PR that renames the intrinsics first, and a separate PR for exposing the new ordering combinations afterwards.
Looks like llvm 12 doesn't support this: Can we make things conditionally fall back to a stronger ordering depending on the llvm version? I don't think we do anything like that in the library right now, but maybe the compiler already does things differently for different llvm versions?
Ah yes, some code checks . I suppose Builder::atomic_cmpxchg could check the same, and upgrade the ordering if necessary in that case.
Did exactly that in
To do: [x] Add codegen test. [x] Publicly expose the new orderings. [x] Update memory order lint to accept the new orderings.

Related discussion:
text: /// Using [`Acquire`] as success ordering makes the store part of this /// operation [`Relaxed`], and using [`Release`] makes the final successful /// load [`Relaxed`]. The (failed) load ordering can only be [`SeqCst`], <del> /// [`Acquire`] or [`Relaxed`] and must be equivalent to or weaker than the /// success ordering. </del> <ins> /// [`Acquire`] or [`Relaxed`]. </ins> /// /// **Note:** This method is only available on platforms that support atomic /// operations on `u8`.
Code change:
Currently requires the failure ordering to "be equivalent to or weaker than a success ordering". On the other hand C11/C++11 requires only that "failure shall be no stronger than the success", which arguably means that one can write e.g. in C/C++ but not in Rust. Arguably, because neither C11 standard nor C++11 standard defines what it means for an ordering to be stronger from another. When the issue was raised in [LWG2445], the proposed and accepted resolution was to lift those restrictions altogether, leaving only requirement that "the failure argument shall not be nor ". It would be beneficial to remove success/failure ordering restrictions for reasons described in C++ proposal [P0418r2]. [LWG2445]: [P0418r2]: EDIT: Restrictions were lifted in clang & LLVM:
Blocked on The cmpxchg release acquire is accepted by LLVM but miscompiled on AArch64.
I'm about to send a PR that implements this.
I do have implementation ready as well, but that's fine, I can review instead :-).
I split it in a PR that renames the intrinsics first, and a separate PR for exposing the new ordering combinations afterwards.
Looks like llvm 12 doesn't support this: Can we make things conditionally fall back to a stronger ordering depending on the llvm version? I don't think we do anything like that in the library right now, but maybe the compiler already does things differently for different llvm versions?
Ah yes, some code checks . I suppose Builder::atomic_cmpxchg could check the same, and upgrade the ordering if necessary in that case.
Did exactly that in
To do: [x] Add codegen test. [x] Publicly expose the new orderings. [x] Update memory order lint to accept the new orderings.

Related discussion:
text: /// `failure` describes the required ordering for the load operation that takes place when /// the comparison fails. Using [`Acquire`] as success ordering makes the store part /// of this operation [`Relaxed`], and using [`Release`] makes the successful load <del> /// [`Relaxed`]. The failure ordering can only be [`SeqCst`], [`Acquire`] or [`Relaxed`] /// and must be equivalent to or weaker than the success ordering. </del> <ins> /// [`Relaxed`]. The failure ordering can only be [`SeqCst`], [`Acquire`] or [`Relaxed`]. </ins> /// /// **Note:** This method is only available on platforms that support atomic /// operations on pointers.
Code change:
Currently requires the failure ordering to "be equivalent to or weaker than a success ordering". On the other hand C11/C++11 requires only that "failure shall be no stronger than the success", which arguably means that one can write e.g. in C/C++ but not in Rust. Arguably, because neither C11 standard nor C++11 standard defines what it means for an ordering to be stronger from another. When the issue was raised in [LWG2445], the proposed and accepted resolution was to lift those restrictions altogether, leaving only requirement that "the failure argument shall not be nor ". It would be beneficial to remove success/failure ordering restrictions for reasons described in C++ proposal [P0418r2]. [LWG2445]: [P0418r2]: EDIT: Restrictions were lifted in clang & LLVM:
Blocked on The cmpxchg release acquire is accepted by LLVM but miscompiled on AArch64.
I'm about to send a PR that implements this.
I do have implementation ready as well, but that's fine, I can review instead :-).
I split it in a PR that renames the intrinsics first, and a separate PR for exposing the new ordering combinations afterwards.
Looks like llvm 12 doesn't support this: Can we make things conditionally fall back to a stronger ordering depending on the llvm version? I don't think we do anything like that in the library right now, but maybe the compiler already does things differently for different llvm versions?
Ah yes, some code checks . I suppose Builder::atomic_cmpxchg could check the same, and upgrade the ordering if necessary in that case.
Did exactly that in
To do: [x] Add codegen test. [x] Publicly expose the new orderings. [x] Update memory order lint to accept the new orderings.

Related discussion:
text: /// Using [`Acquire`] as success ordering makes the store part of this /// operation [`Relaxed`], and using [`Release`] makes the final successful /// load [`Relaxed`]. The (failed) load ordering can only be [`SeqCst`], <del> /// [`Acquire`] or [`Relaxed`] and must be equivalent to or weaker than the /// success ordering. </del> <ins> /// [`Acquire`] or [`Relaxed`]. </ins> /// /// **Note:** This method is only available on platforms that support atomic /// operations on pointers.
Code change:
Currently requires the failure ordering to "be equivalent to or weaker than a success ordering". On the other hand C11/C++11 requires only that "failure shall be no stronger than the success", which arguably means that one can write e.g. in C/C++ but not in Rust. Arguably, because neither C11 standard nor C++11 standard defines what it means for an ordering to be stronger from another. When the issue was raised in [LWG2445], the proposed and accepted resolution was to lift those restrictions altogether, leaving only requirement that "the failure argument shall not be nor ". It would be beneficial to remove success/failure ordering restrictions for reasons described in C++ proposal [P0418r2]. [LWG2445]: [P0418r2]: EDIT: Restrictions were lifted in clang & LLVM:
Blocked on The cmpxchg release acquire is accepted by LLVM but miscompiled on AArch64.
I'm about to send a PR that implements this.
I do have implementation ready as well, but that's fine, I can review instead :-).
I split it in a PR that renames the intrinsics first, and a separate PR for exposing the new ordering combinations afterwards.
Looks like llvm 12 doesn't support this: Can we make things conditionally fall back to a stronger ordering depending on the llvm version? I don't think we do anything like that in the library right now, but maybe the compiler already does things differently for different llvm versions?
Ah yes, some code checks . I suppose Builder::atomic_cmpxchg could check the same, and upgrade the ordering if necessary in that case.
Did exactly that in
To do: [x] Add codegen test. [x] Publicly expose the new orderings. [x] Update memory order lint to accept the new orderings.

Related discussion:
text: /// `failure` describes the required ordering for the load operation that takes place when /// the comparison fails. Using [`Acquire`] as success ordering makes the store part /// of this operation [`Relaxed`], and using [`Release`] makes the successful load <del> /// [`Relaxed`]. The failure ordering can only be [`SeqCst`], [`Acquire`] or [`Relaxed`] /// and must be equivalent to or weaker than the success ordering. </del> <ins> /// [`Relaxed`]. The failure ordering can only be [`SeqCst`], [`Acquire`] or [`Relaxed`]. </ins> /// /// **Note**: This method is only available on platforms that support atomic operations on #[doc = concat!("[`", $s_int_type, "`].")]
Code change:
Currently requires the failure ordering to "be equivalent to or weaker than a success ordering". On the other hand C11/C++11 requires only that "failure shall be no stronger than the success", which arguably means that one can write e.g. in C/C++ but not in Rust. Arguably, because neither C11 standard nor C++11 standard defines what it means for an ordering to be stronger from another. When the issue was raised in [LWG2445], the proposed and accepted resolution was to lift those restrictions altogether, leaving only requirement that "the failure argument shall not be nor ". It would be beneficial to remove success/failure ordering restrictions for reasons described in C++ proposal [P0418r2]. [LWG2445]: [P0418r2]: EDIT: Restrictions were lifted in clang & LLVM:
Blocked on The cmpxchg release acquire is accepted by LLVM but miscompiled on AArch64.
I'm about to send a PR that implements this.
I do have implementation ready as well, but that's fine, I can review instead :-).
I split it in a PR that renames the intrinsics first, and a separate PR for exposing the new ordering combinations afterwards.
Looks like llvm 12 doesn't support this: Can we make things conditionally fall back to a stronger ordering depending on the llvm version? I don't think we do anything like that in the library right now, but maybe the compiler already does things differently for different llvm versions?
Ah yes, some code checks . I suppose Builder::atomic_cmpxchg could check the same, and upgrade the ordering if necessary in that case.
Did exactly that in
To do: [x] Add codegen test. [x] Publicly expose the new orderings. [x] Update memory order lint to accept the new orderings.

Related discussion:
text: /// /// Using [`Acquire`] as success ordering makes the store part /// of this operation [`Relaxed`], and using [`Release`] makes the final successful load <del> /// [`Relaxed`]. The (failed) load ordering can only be [`SeqCst`], [`Acquire`] or [`Relaxed`] /// and must be equivalent to or weaker than the success ordering. </del> <ins> /// [`Relaxed`]. The (failed) load ordering can only be [`SeqCst`], [`Acquire`] or [`Relaxed`]. </ins> /// /// **Note**: This method is only available on platforms that support atomic operations on #[doc = concat!("[`", $s_int_type, "`].")]
Code change:
Here's the crashing code I came down to: An empty contains a single line: "pub mod " a file with the following code: This happened as I permuted type and size in my array definition. My intention was not to declare a zero sized array but to declare an array filled with zeros. Anyway, the compiler crashed. I noticed that if I remove the from the line in , it compiles fine. Backtrace:
cc
cc did the value visitor changes get merged?
is still waiting for review if that's the one you mean.
The ICE seems to be , though. So likely just needs a test (or checking that we already have an appropriate test)?
Maybe we should also find the PR that fixed this and beta nominate?
points to as being responsible for fixing this.
That PR is too big to backport. I suggest to just remove the assertion on beta as the ICE is properly fixed on master
Still need to backport
The fix is already on beta so backport is unneeded?
Yeah, playground confirms that this ICEs on stable but works fine on beta and nightly.

Related discussion:
text: <ins> // build-pass // Verify that the compiler doesn't ICE during const prop while evaluating the index operation. #![allow(unconditional_panic)] fn main() { let cols = [0u32; 0]; cols[0]; } </ins>
Code change:
I'm seeing an internal compiler error on the following input (found by ): The error happens on , , and .
I'm looking into this! But mostly as a learning exercise. Spent ~4 hours exploring typeck & error handling today to see why this exact combination of things triggers an error. My friend and I will probably have a solution at some point, but it might be a few weeks from now. If anyone has a good & quick solution, or if it is deemed high-priority, then feel free to ignore me.
~According to , this regressed between 2019-07-30 and 2019-07-31. Unfortunately, seems to be incapable of narrowing it down to a commit because that was more than 167 days ago.~ EDIT: gave me a misleading result. This error is at least as old as .
This error started happening in cc
The ICE goes away if I apply this patch: (Though I'd guess that making this change would cause us to regress on the problems that fixed.)
This change fixes the ICE and avoids regressing on : I'm unsure whether this respects the intended meaning of , though.
on a very cursory look that patch looks reasonable.
has some additional relevant context.
Unfortunately, the patch that I proposed above fails on this modification of :
triage: P-high. Removing nomination. Added regression stable-to-stable tag.
I think I found a way to resolve this without regressing on . The point of this PR is to not emit an error if it might be invalid to the user. But there are errors in context still. The patch I propose is this: This does pass every UI test. I'll open a PR so this can be discussed more easely.

Related discussion:
text: ty_span: Span, ) { if variant.recovered { <ins> self.set_tainted_by_errors(); </ins> return; } let mut err = self.type_error_struct_with_diag(
Code change:
I'm seeing an internal compiler error on the following input (found by ): The error happens on , , and .
I'm looking into this! But mostly as a learning exercise. Spent ~4 hours exploring typeck & error handling today to see why this exact combination of things triggers an error. My friend and I will probably have a solution at some point, but it might be a few weeks from now. If anyone has a good & quick solution, or if it is deemed high-priority, then feel free to ignore me.
~According to , this regressed between 2019-07-30 and 2019-07-31. Unfortunately, seems to be incapable of narrowing it down to a commit because that was more than 167 days ago.~ EDIT: gave me a misleading result. This error is at least as old as .
This error started happening in cc
The ICE goes away if I apply this patch: (Though I'd guess that making this change would cause us to regress on the problems that fixed.)
This change fixes the ICE and avoids regressing on : I'm unsure whether this respects the intended meaning of , though.
on a very cursory look that patch looks reasonable.
has some additional relevant context.
Unfortunately, the patch that I proposed above fails on this modification of :
triage: P-high. Removing nomination. Added regression stable-to-stable tag.
I think I found a way to resolve this without regressing on . The point of this PR is to not emit an error if it might be invalid to the user. But there are errors in context still. The patch I propose is this: This does pass every UI test. I'll open a PR so this can be discussed more easely.

Related discussion:
text: <ins> // Regression test for #69378: no type for node after struct parse recovery struct Foo { 0: u8 } //~ ERROR expected identifier fn test(f: Foo) { Foo{foo: 4, ..f}; } fn main() {} </ins>
Code change:
I'm seeing an internal compiler error on the following input (found by ): The error happens on , , and .
I'm looking into this! But mostly as a learning exercise. Spent ~4 hours exploring typeck & error handling today to see why this exact combination of things triggers an error. My friend and I will probably have a solution at some point, but it might be a few weeks from now. If anyone has a good & quick solution, or if it is deemed high-priority, then feel free to ignore me.
~According to , this regressed between 2019-07-30 and 2019-07-31. Unfortunately, seems to be incapable of narrowing it down to a commit because that was more than 167 days ago.~ EDIT: gave me a misleading result. This error is at least as old as .
This error started happening in cc
The ICE goes away if I apply this patch: (Though I'd guess that making this change would cause us to regress on the problems that fixed.)
This change fixes the ICE and avoids regressing on : I'm unsure whether this respects the intended meaning of , though.
on a very cursory look that patch looks reasonable.
has some additional relevant context.
Unfortunately, the patch that I proposed above fails on this modification of :
triage: P-high. Removing nomination. Added regression stable-to-stable tag.
I think I found a way to resolve this without regressing on . The point of this PR is to not emit an error if it might be invalid to the user. But there are errors in context still. The patch I propose is this: This does pass every UI test. I'll open a PR so this can be discussed more easely.

Related discussion:
text: <ins> error: expected identifier, found `0` --> $DIR/issue-69378-ice-on-invalid-type-node-after-recovery.rs:3:14 | LL | struct Foo { 0: u8 } |              ^ expected identifier error: aborting due to previous error </ins>
Code change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool clippy-driver no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! And nominating for compiler team prioritization.

Related discussion:
text: [[package]] name = "git2" <del> version = "0.11.0" </del> <ins> version = "0.12.0" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" <del> checksum = "77519ef7c5beee314d0804d4534f01e0f9e8d9acdee2b7a48627e590b27e0ec4" </del> <ins> checksum = "26e07ef27260a78f7e8d218ebac2c72f2c4db50493741b190b6e8eade1da7c68" </ins> dependencies = [ "bitflags", "libc",
Code change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool clippy-driver no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! And nominating for compiler team prioritization.

Related discussion:
text: [[package]] name = "git2-curl" <del> version = "0.12.0" </del> <ins> version = "0.13.0" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" <del> checksum = "d2559abb1d87d27668d31bd868a000f0e2e0065d10e78961b62da95d7a7f1cc7" </del> <ins> checksum = "af1754ec4170e7dcaf9bb43743bb16eddb8d827b2e0291deb6f220a6e16fe46a" </ins> dependencies = [ "curl", "git2",
Code change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool clippy-driver no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! And nominating for compiler team prioritization.

Related discussion:
text: [[package]] name = "libgit2-sys" <del> version = "0.10.0" </del> <ins> version = "0.11.0+0.99.0" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" <del> checksum = "d9ec6bca50549d34a392611dde775123086acbd994e3fff64954777ce2dc2e51" </del> <ins> checksum = "4d5d1459353d397a029fb18862166338de938e6be976606bd056cf8f1a912ecf" </ins> dependencies = [ "cc", "libc",
Code change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool clippy-driver no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! And nominating for compiler team prioritization.

Related discussion:
text: <del> Subproject commit e57bd02999c9f40d52116e0beca7d1dccb0643de </del> <ins> Subproject commit bda50510d1daf6e9c53ad6ccf603da6e0fa8103f </ins>
Code change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool clippy-driver no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! And nominating for compiler team prioritization.

Related discussion:
text: <del> Subproject commit fc5d0cc583cb1cd35d58fdb7f3e0cfa12dccd6c0 </del> <ins> Subproject commit 8b7f7e667268921c278af94ae30a61e87a22b22b </ins>