Re: [OE-core] [PATCH 1/3] rust: Fix crossbeam-utils for arches without atomics
On 2022-08-25 19:24, Khem Raj wrote: On Thu, Aug 25, 2022 at 12:11 PM Randy MacLeod wrote: On 2022-08-25 07:53, Richard Purdie wrote: On Thu, 2022-08-25 at 13:04 +0200, Alexander Kanavin wrote: On Thu, 25 Aug 2022 at 12:59, Richard Purdie wrote: The usptreamable version of the patch would probably be something which splits the target names in no_atomics up into components and matched on subsections of it rather than the whole string. My rust isn't really up to doing that though. I didn't really want us to maintain a separate list of targets which have atomics issues given it and the list in no_atomics would get out of sync very easily too. But then the same patch needs to be applied to (and maintained separately in) librsvg - and everything else that includes a copy of crossbeam. Perhaps it's worth to at least make the above suggestion about making it upstreamable in the patch commit message? Yes, I can improve the patch header. I do understand the patch isn't ideal. The alternatives are: * we take my patch * we break powerpc, mips, armv5, riscv32 and others * we drop the rust upgrades (the latent problem still exists) * we rewrite the patch For me to rewrite the patch, I'll need to learn more rust. I'm sure I can do that but it will take time and that time is time I can't use for other things. I'm hoping that by explaining the issue and documenting it, *someone* would step up and work out the upstreamable patch. This hasn't worked well for the rust recipes so far as I've had to do a lot of work to get them more into shape. I'm hoping the problem was just the shear scale and now issues are in easier smaller pieces others can/will help. It will certainly be time before someone else can schedule that in, we don't have anyone who can do it now. Yes, with the range of things I have had going on, re-writing the rust classes/recipes was too big a task to consider. However, I can and will work to get this patch into a form that is upstreamable. I've created a bug to track that: https://bugzilla.yoctoproject.org/show_bug.cgi?id=14904 and at least started to look at some of the code! Also opening an issue upstream at https://github.com/crossbeam-rs/crossbeam would be a good thing. crossbeam is vendored by many rust packages and we will end up spewing the all such recipes with the tweak in addition to regenerating the checksums in toml files with every upgrade. Agreed and noted in the YP bug. ../Randy ../Randy I will say that I'm really really tired. I have a ton of autobuilder failures and in order to resolve them I'm rewriting patches many times over, first to get them to work, then taking review feedback and people complaining they're not perfect or don't fix other issues. I have a pile of other problems like this. I appreciate the desire not to have patches, particularly when they're as painful as the rust ones are. I appreciate the patch can be improved and should go upstream. I was hoping to take some time off tomorrow but it looks like I have other things to do (in reality probably on the weekend, I need to rework the llvm patches too and both sets take hours in rebuild time even to test). Cheers, Richard -- # Randy MacLeod # Wind River Linux -- # Randy MacLeod # Wind River Linux -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#169899): https://lists.openembedded.org/g/openembedded-core/message/169899 Mute This Topic: https://lists.openembedded.org/mt/93245408/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH 1/3] rust: Fix crossbeam-utils for arches without atomics
On Thu, Aug 25, 2022 at 12:11 PM Randy MacLeod wrote: > > On 2022-08-25 07:53, Richard Purdie wrote: > > On Thu, 2022-08-25 at 13:04 +0200, Alexander Kanavin wrote: > >> On Thu, 25 Aug 2022 at 12:59, Richard Purdie > >> wrote: > >>> The usptreamable version of the patch would probably be something which > >>> splits the target names in no_atomics up into components and matched on > >>> subsections of it rather than the whole string. My rust isn't really up > >>> to doing that though. > >>> > >>> I didn't really want us to maintain a separate list of targets which > >>> have atomics issues given it and the list in no_atomics would get out > >>> of sync very easily too. > >> But then the same patch needs to be applied to (and maintained > >> separately in) librsvg - and everything else that includes a copy of > >> crossbeam. Perhaps it's worth to at least make the above suggestion > >> about making it upstreamable in the patch commit message? > > Yes, I can improve the patch header. I do understand the patch isn't > > ideal. > > > > The alternatives are: > > > > * we take my patch > > * we break powerpc, mips, armv5, riscv32 and others > > * we drop the rust upgrades (the latent problem still exists) > > * we rewrite the patch > > > > For me to rewrite the patch, I'll need to learn more rust. I'm sure I > > can do that but it will take time and that time is time I can't use for > > other things. > > > > I'm hoping that by explaining the issue and documenting it, *someone* > > would step up and work out the upstreamable patch. This hasn't worked > > well for the rust recipes so far as I've had to do a lot of work to get > > them more into shape. I'm hoping the problem was just the shear scale > > and now issues are in easier smaller pieces others can/will help. It > > will certainly be time before someone else can schedule that in, we > > don't have anyone who can do it now. > > Yes, with the range of things I have had going on, re-writing the > rust classes/recipes was too big a task to consider. However, I can > and will work to get this patch into a form that is upstreamable. > > I've created a bug to track that: > > https://bugzilla.yoctoproject.org/show_bug.cgi?id=14904 > > and at least started to look at some of the code! > Also opening an issue upstream at https://github.com/crossbeam-rs/crossbeam would be a good thing. crossbeam is vendored by many rust packages and we will end up spewing the all such recipes with the tweak in addition to regenerating the checksums in toml files with every upgrade. > ../Randy > > > > > > I will say that I'm really really tired. > > > > I have a ton of autobuilder failures and in order to resolve them I'm > > rewriting patches many times over, first to get them to work, then > > taking review feedback and people complaining they're not perfect or > > don't fix other issues. I have a pile of other problems like this. > > > > I appreciate the desire not to have patches, particularly when they're > > as painful as the rust ones are. I appreciate the patch can be improved > > and should go upstream. I was hoping to take some time off tomorrow but > > it looks like I have other things to do (in reality probably on the > > weekend, I need to rework the llvm patches too and both sets take hours > > in rebuild time even to test). > > > > Cheers, > > > > Richard > > > > > > > > -- > # Randy MacLeod > # Wind River Linux > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#169897): https://lists.openembedded.org/g/openembedded-core/message/169897 Mute This Topic: https://lists.openembedded.org/mt/93245408/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH 1/3] rust: Fix crossbeam-utils for arches without atomics
On 2022-08-25 07:53, Richard Purdie wrote: On Thu, 2022-08-25 at 13:04 +0200, Alexander Kanavin wrote: On Thu, 25 Aug 2022 at 12:59, Richard Purdie wrote: The usptreamable version of the patch would probably be something which splits the target names in no_atomics up into components and matched on subsections of it rather than the whole string. My rust isn't really up to doing that though. I didn't really want us to maintain a separate list of targets which have atomics issues given it and the list in no_atomics would get out of sync very easily too. But then the same patch needs to be applied to (and maintained separately in) librsvg - and everything else that includes a copy of crossbeam. Perhaps it's worth to at least make the above suggestion about making it upstreamable in the patch commit message? Yes, I can improve the patch header. I do understand the patch isn't ideal. The alternatives are: * we take my patch * we break powerpc, mips, armv5, riscv32 and others * we drop the rust upgrades (the latent problem still exists) * we rewrite the patch For me to rewrite the patch, I'll need to learn more rust. I'm sure I can do that but it will take time and that time is time I can't use for other things. I'm hoping that by explaining the issue and documenting it, *someone* would step up and work out the upstreamable patch. This hasn't worked well for the rust recipes so far as I've had to do a lot of work to get them more into shape. I'm hoping the problem was just the shear scale and now issues are in easier smaller pieces others can/will help. It will certainly be time before someone else can schedule that in, we don't have anyone who can do it now. Yes, with the range of things I have had going on, re-writing the rust classes/recipes was too big a task to consider. However, I can and will work to get this patch into a form that is upstreamable. I've created a bug to track that: https://bugzilla.yoctoproject.org/show_bug.cgi?id=14904 and at least started to look at some of the code! ../Randy I will say that I'm really really tired. I have a ton of autobuilder failures and in order to resolve them I'm rewriting patches many times over, first to get them to work, then taking review feedback and people complaining they're not perfect or don't fix other issues. I have a pile of other problems like this. I appreciate the desire not to have patches, particularly when they're as painful as the rust ones are. I appreciate the patch can be improved and should go upstream. I was hoping to take some time off tomorrow but it looks like I have other things to do (in reality probably on the weekend, I need to rework the llvm patches too and both sets take hours in rebuild time even to test). Cheers, Richard -- # Randy MacLeod # Wind River Linux -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#169885): https://lists.openembedded.org/g/openembedded-core/message/169885 Mute This Topic: https://lists.openembedded.org/mt/93245408/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH 1/3] rust: Fix crossbeam-utils for arches without atomics
On Thu, 2022-08-25 at 13:04 +0200, Alexander Kanavin wrote: > On Thu, 25 Aug 2022 at 12:59, Richard Purdie > wrote: > > The usptreamable version of the patch would probably be something which > > splits the target names in no_atomics up into components and matched on > > subsections of it rather than the whole string. My rust isn't really up > > to doing that though. > > > > I didn't really want us to maintain a separate list of targets which > > have atomics issues given it and the list in no_atomics would get out > > of sync very easily too. > > But then the same patch needs to be applied to (and maintained > separately in) librsvg - and everything else that includes a copy of > crossbeam. Perhaps it's worth to at least make the above suggestion > about making it upstreamable in the patch commit message? Yes, I can improve the patch header. I do understand the patch isn't ideal. The alternatives are: * we take my patch * we break powerpc, mips, armv5, riscv32 and others * we drop the rust upgrades (the latent problem still exists) * we rewrite the patch For me to rewrite the patch, I'll need to learn more rust. I'm sure I can do that but it will take time and that time is time I can't use for other things. I'm hoping that by explaining the issue and documenting it, *someone* would step up and work out the upstreamable patch. This hasn't worked well for the rust recipes so far as I've had to do a lot of work to get them more into shape. I'm hoping the problem was just the shear scale and now issues are in easier smaller pieces others can/will help. It will certainly be time before someone else can schedule that in, we don't have anyone who can do it now. I will say that I'm really really tired. I have a ton of autobuilder failures and in order to resolve them I'm rewriting patches many times over, first to get them to work, then taking review feedback and people complaining they're not perfect or don't fix other issues. I have a pile of other problems like this. I appreciate the desire not to have patches, particularly when they're as painful as the rust ones are. I appreciate the patch can be improved and should go upstream. I was hoping to take some time off tomorrow but it looks like I have other things to do (in reality probably on the weekend, I need to rework the llvm patches too and both sets take hours in rebuild time even to test). Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#169852): https://lists.openembedded.org/g/openembedded-core/message/169852 Mute This Topic: https://lists.openembedded.org/mt/93245408/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH 1/3] rust: Fix crossbeam-utils for arches without atomics
On Thu, 25 Aug 2022 at 12:59, Richard Purdie wrote: > The usptreamable version of the patch would probably be something which > splits the target names in no_atomics up into components and matched on > subsections of it rather than the whole string. My rust isn't really up > to doing that though. > > I didn't really want us to maintain a separate list of targets which > have atomics issues given it and the list in no_atomics would get out > of sync very easily too. But then the same patch needs to be applied to (and maintained separately in) librsvg - and everything else that includes a copy of crossbeam. Perhaps it's worth to at least make the above suggestion about making it upstreamable in the patch commit message? Alex -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#169851): https://lists.openembedded.org/g/openembedded-core/message/169851 Mute This Topic: https://lists.openembedded.org/mt/93245408/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH 1/3] rust: Fix crossbeam-utils for arches without atomics
On Thu, 2022-08-25 at 12:52 +0200, Alexander Kanavin wrote: > This will complicate version updates unfortunately, as updating > .cargo-checksum.json is a pain :( > Can we try to arrive at something upstreamable? The usptreamable version of the patch would probably be something which splits the target names in no_atomics up into components and matched on subsections of it rather than the whole string. My rust isn't really up to doing that though. I didn't really want us to maintain a separate list of targets which have atomics issues given it and the list in no_atomics would get out of sync very easily too. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#169850): https://lists.openembedded.org/g/openembedded-core/message/169850 Mute This Topic: https://lists.openembedded.org/mt/93245408/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH 1/3] rust: Fix crossbeam-utils for arches without atomics
On Thu, 2022-08-25 at 12:53 +0200, Alexander Kanavin wrote: > What would be much preferred is an explicit switch to disable atomics > on the platforms where we know they don't work. There is a list of such platforms in no_atomics.rs. This patch means we don't have to add the switch for every platform by fixing the detection code. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#169849): https://lists.openembedded.org/g/openembedded-core/message/169849 Mute This Topic: https://lists.openembedded.org/mt/93245408/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH 1/3] rust: Fix crossbeam-utils for arches without atomics
What would be much preferred is an explicit switch to disable atomics on the platforms where we know they don't work. Alex On Thu, 25 Aug 2022 at 12:52, Alexander Kanavin wrote: > > This will complicate version updates unfortunately, as updating > .cargo-checksum.json is a pain :( > Can we try to arrive at something upstreamable? > > Alex > > On Thu, 25 Aug 2022 at 12:49, Richard Purdie > wrote: > > > > crossbeam-utils tries to use the triplet to look up whether the target > > supports various forms of atomics. We use TARGET_VENDOR and not "-unknown" > > in the target case which means this fails and breaks platforms like mips > > and powerpc 32 bit. Add a patch to handle TARGET_VENDOR in this case. > > > > Signed-off-by: Richard Purdie > > --- > > meta/recipes-devtools/rust/rust-source.inc| 1 + > > .../rust/rust/crossbeam_atomic.patch | 33 +++ > > meta/recipes-devtools/rust/rust_1.63.0.bb | 3 ++ > > 3 files changed, 37 insertions(+) > > create mode 100644 meta/recipes-devtools/rust/rust/crossbeam_atomic.patch > > > > diff --git a/meta/recipes-devtools/rust/rust-source.inc > > b/meta/recipes-devtools/rust/rust-source.inc > > index d8be2701367..ce6c983fc0b 100644 > > --- a/meta/recipes-devtools/rust/rust-source.inc > > +++ b/meta/recipes-devtools/rust/rust-source.inc > > @@ -3,6 +3,7 @@ SRC_URI[rust.sha256sum] = > > "8f44af6dc44cc4146634a4dd5e4cc5470b3052a2337019b870c0e > > > > SRC_URI:append:class-target:pn-rust = " \ > > file://hardcodepaths.patch \ > > +file://crossbeam_atomic.patch \ > > file://0001-Add-ENOTSUP-constant-for-riscv32-musl.patch" > > SRC_URI:append:class-nativesdk:pn-nativesdk-rust = " > > file://hardcodepaths.patch" > > > > diff --git a/meta/recipes-devtools/rust/rust/crossbeam_atomic.patch > > b/meta/recipes-devtools/rust/rust/crossbeam_atomic.patch > > new file mode 100644 > > index 000..64c73810a89 > > --- /dev/null > > +++ b/meta/recipes-devtools/rust/rust/crossbeam_atomic.patch > > @@ -0,0 +1,33 @@ > > +Upstream-Status: Inappropriate [OE Specific tweak] > > + > > +Index: rustc-1.63.0-src/vendor/crossbeam-utils/build.rs > > +=== > > +--- rustc-1.63.0-src.orig/vendor/crossbeam-utils/build.rs > > rustc-1.63.0-src/vendor/crossbeam-utils/build.rs > > +@@ -29,7 +29,7 @@ use std::env; > > + include!("no_atomic.rs"); > > + > > + fn main() { > > +-let target = match env::var("TARGET") { > > ++let mut target = match env::var("TARGET") { > > + Ok(target) => target, > > + Err(e) => { > > + println!( > > +@@ -40,6 +40,8 @@ fn main() { > > + return; > > + } > > + }; > > ++let vendor = env::var("TARGET_VENDOR").unwrap(); > > ++target = target.replace(, "-unknown"); > > + > > + // Note that this is `no_*`, not `has_*`. This allows treating > > + // `cfg(target_has_atomic = "ptr")` as true when the build script > > doesn't > > +Index: rustc-1.63.0-src/vendor/crossbeam-utils/.cargo-checksum.json > > +=== > > +--- rustc-1.63.0-src.orig/vendor/crossbeam-utils/.cargo-checksum.json > > rustc-1.63.0-src/vendor/crossbeam-utils/.cargo-checksum.json > > +@@ -1 +1 @@ > >
Re: [OE-core] [PATCH 1/3] rust: Fix crossbeam-utils for arches without atomics
This will complicate version updates unfortunately, as updating .cargo-checksum.json is a pain :( Can we try to arrive at something upstreamable? Alex On Thu, 25 Aug 2022 at 12:49, Richard Purdie wrote: > > crossbeam-utils tries to use the triplet to look up whether the target > supports various forms of atomics. We use TARGET_VENDOR and not "-unknown" > in the target case which means this fails and breaks platforms like mips > and powerpc 32 bit. Add a patch to handle TARGET_VENDOR in this case. > > Signed-off-by: Richard Purdie > --- > meta/recipes-devtools/rust/rust-source.inc| 1 + > .../rust/rust/crossbeam_atomic.patch | 33 +++ > meta/recipes-devtools/rust/rust_1.63.0.bb | 3 ++ > 3 files changed, 37 insertions(+) > create mode 100644 meta/recipes-devtools/rust/rust/crossbeam_atomic.patch > > diff --git a/meta/recipes-devtools/rust/rust-source.inc > b/meta/recipes-devtools/rust/rust-source.inc > index d8be2701367..ce6c983fc0b 100644 > --- a/meta/recipes-devtools/rust/rust-source.inc > +++ b/meta/recipes-devtools/rust/rust-source.inc > @@ -3,6 +3,7 @@ SRC_URI[rust.sha256sum] = > "8f44af6dc44cc4146634a4dd5e4cc5470b3052a2337019b870c0e > > SRC_URI:append:class-target:pn-rust = " \ > file://hardcodepaths.patch \ > +file://crossbeam_atomic.patch \ > file://0001-Add-ENOTSUP-constant-for-riscv32-musl.patch" > SRC_URI:append:class-nativesdk:pn-nativesdk-rust = " > file://hardcodepaths.patch" > > diff --git a/meta/recipes-devtools/rust/rust/crossbeam_atomic.patch > b/meta/recipes-devtools/rust/rust/crossbeam_atomic.patch > new file mode 100644 > index 000..64c73810a89 > --- /dev/null > +++ b/meta/recipes-devtools/rust/rust/crossbeam_atomic.patch > @@ -0,0 +1,33 @@ > +Upstream-Status: Inappropriate [OE Specific tweak] > + > +Index: rustc-1.63.0-src/vendor/crossbeam-utils/build.rs > +=== > +--- rustc-1.63.0-src.orig/vendor/crossbeam-utils/build.rs > rustc-1.63.0-src/vendor/crossbeam-utils/build.rs > +@@ -29,7 +29,7 @@ use std::env; > + include!("no_atomic.rs"); > + > + fn main() { > +-let target = match env::var("TARGET") { > ++let mut target = match env::var("TARGET") { > + Ok(target) => target, > + Err(e) => { > + println!( > +@@ -40,6 +40,8 @@ fn main() { > + return; > + } > + }; > ++let vendor = env::var("TARGET_VENDOR").unwrap(); > ++target = target.replace(, "-unknown"); > + > + // Note that this is `no_*`, not `has_*`. This allows treating > + // `cfg(target_has_atomic = "ptr")` as true when the build script > doesn't > +Index: rustc-1.63.0-src/vendor/crossbeam-utils/.cargo-checksum.json > +=== > +--- rustc-1.63.0-src.orig/vendor/crossbeam-utils/.cargo-checksum.json > rustc-1.63.0-src/vendor/crossbeam-utils/.cargo-checksum.json > +@@ -1 +1 @@ >
[OE-core] [PATCH 1/3] rust: Fix crossbeam-utils for arches without atomics
crossbeam-utils tries to use the triplet to look up whether the target supports various forms of atomics. We use TARGET_VENDOR and not "-unknown" in the target case which means this fails and breaks platforms like mips and powerpc 32 bit. Add a patch to handle TARGET_VENDOR in this case. Signed-off-by: Richard Purdie --- meta/recipes-devtools/rust/rust-source.inc| 1 + .../rust/rust/crossbeam_atomic.patch | 33 +++ meta/recipes-devtools/rust/rust_1.63.0.bb | 3 ++ 3 files changed, 37 insertions(+) create mode 100644 meta/recipes-devtools/rust/rust/crossbeam_atomic.patch diff --git a/meta/recipes-devtools/rust/rust-source.inc b/meta/recipes-devtools/rust/rust-source.inc index d8be2701367..ce6c983fc0b 100644 --- a/meta/recipes-devtools/rust/rust-source.inc +++ b/meta/recipes-devtools/rust/rust-source.inc @@ -3,6 +3,7 @@ SRC_URI[rust.sha256sum] = "8f44af6dc44cc4146634a4dd5e4cc5470b3052a2337019b870c0e SRC_URI:append:class-target:pn-rust = " \ file://hardcodepaths.patch \ +file://crossbeam_atomic.patch \ file://0001-Add-ENOTSUP-constant-for-riscv32-musl.patch" SRC_URI:append:class-nativesdk:pn-nativesdk-rust = " file://hardcodepaths.patch" diff --git a/meta/recipes-devtools/rust/rust/crossbeam_atomic.patch b/meta/recipes-devtools/rust/rust/crossbeam_atomic.patch new file mode 100644 index 000..64c73810a89 --- /dev/null +++ b/meta/recipes-devtools/rust/rust/crossbeam_atomic.patch @@ -0,0 +1,33 @@ +Upstream-Status: Inappropriate [OE Specific tweak] + +Index: rustc-1.63.0-src/vendor/crossbeam-utils/build.rs +=== +--- rustc-1.63.0-src.orig/vendor/crossbeam-utils/build.rs rustc-1.63.0-src/vendor/crossbeam-utils/build.rs +@@ -29,7 +29,7 @@ use std::env; + include!("no_atomic.rs"); + + fn main() { +-let target = match env::var("TARGET") { ++let mut target = match env::var("TARGET") { + Ok(target) => target, + Err(e) => { + println!( +@@ -40,6 +40,8 @@ fn main() { + return; + } + }; ++let vendor = env::var("TARGET_VENDOR").unwrap(); ++target = target.replace(, "-unknown"); + + // Note that this is `no_*`, not `has_*`. This allows treating + // `cfg(target_has_atomic = "ptr")` as true when the build script doesn't +Index: rustc-1.63.0-src/vendor/crossbeam-utils/.cargo-checksum.json +=== +--- rustc-1.63.0-src.orig/vendor/crossbeam-utils/.cargo-checksum.json rustc-1.63.0-src/vendor/crossbeam-utils/.cargo-checksum.json +@@ -1 +1 @@