Update default Rust to nightly-2024-02-12 #12075
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
alexcrichton
force-pushed
the
update-rust
branch
from
542e4c7 to
d84f88b
Compare
maflcko
reviewed
Jun 17, 2024
Merged
alexcrichton
added a commit
to alexcrichton/oss-fuzz
that referenced
this pull request
Jun 17, 2024
This is done in the interest of assisting google#12075 and google#11626. Currently the Rust toolchain cannot be updated because the latest nightly uses LLVM 18.1.7 and coverage information breaks. This breakage is because LLVM 18.1.7 records coverage information with version "9" but LLVM 18.0.0 recorded coverage information with version "8". This means that the recordings created by Rust binaries use version "9" which are unreadable by the processing that OSS-Fuzz does with the 18.0.0-based toolchain using version "8". This commit updates the Clang toolchain to the latest 18.x.x release to get the two in sync so the same coverage recording version is used.
manunio
reviewed
Jun 18, 2024
This commit updates the default version of Rust installed for fuzzing to the last nightly of Rust that used LLVM 17. The next version uses LLVM 18.1.7 which is incompatible with the fuzz infrastructure's own LLVM which is currently 18.0.0. This is intended to update the Rust toolchain as far as possible without causing coverage incompatibilities. This additionally updates a few pinned projects to all use this nightly as well. Furthermore the containers are now configured to by-default ignore `rust-toolchain` and `rust-toolchain.toml` files which will force this particular toolchain to be used.
alexcrichton
force-pushed
the
update-rust
branch
from
caf1ff5 to
2a4e4f9
Compare
alexcrichton
changed the title
|
Ok I've updated this as recommended in #12077 to update Rust as far as possible before Rust started using LLVM 18.1.7. This should then be a relatively routine update of rustc without breaking coverage information. |
|
Looks like the libfuzzer coverage build for x86_64 failed in CI with the reasons as "System.IO.IOException: No space left on device" (from the summary) (if someone wouldn't mind kicking that with a retry) |
|
The CI is underpowered for infra changes. This needs a full rust trial run from a maintainer of this repo. |
alexcrichton
added a commit
to alexcrichton/oss-fuzz
that referenced
this pull request
Jun 18, 2024
This is done in the interest of assisting google#12075 and google#11626. Currently the Rust toolchain cannot be updated because the latest nightly uses LLVM 18.1.7 and coverage information breaks. This breakage is because LLVM 18.1.7 records coverage information with version "9" but LLVM 18.0.0 recorded coverage information with version "8". This means that the recordings created by Rust binaries use version "9" which are unreadable by the processing that OSS-Fuzz does with the 18.0.0-based toolchain using version "8". This commit updates the Clang toolchain to the latest 18.x.x release to get the two in sync so the same coverage recording version is used.
|
cc @jonathanmetzman for a trial run |
|
/gcbrun trial_build.py rust |
|
Reading over the trial build my naive interpretation is that it looks like things passed, but one of y'all more familiar with the output there probably want to double-check me. Given the number of what I thought were spurious failures on #12077 I'm surprised that there are seemingly zero failures. |
|
The other one is testing an order of magnitude more projects. This Looks ok |
jonathanmetzman
approved these changes
Jun 20, 2024
|
Can i land this now? Or do I need to wait for the other PR? |
|
This should be good to go yeah, no blockers on my end at least |
|
Yes, this is good to go. The motivation is to get almost all of rust 1.77 (https://blog.rust-lang.org/2024/03/21/Rust-1.77.0.html#stabilized-apis) into OSS-Fuzz by default (no need for each project to do it themselves locally). |
alexcrichton
added a commit
to alexcrichton/oss-fuzz
that referenced
this pull request
Jun 27, 2024
This is done in the interest of assisting google#12075 and google#11626. Currently the Rust toolchain cannot be updated because the latest nightly uses LLVM 18.1.7 and coverage information breaks. This breakage is because LLVM 18.1.7 records coverage information with version "9" but LLVM 18.0.0 recorded coverage information with version "8". This means that the recordings created by Rust binaries use version "9" which are unreadable by the processing that OSS-Fuzz does with the 18.0.0-based toolchain using version "8". This commit updates the Clang toolchain to the latest 18.x.x release to get the two in sync so the same coverage recording version is used.
alexcrichton
added a commit
to alexcrichton/oss-fuzz
that referenced
this pull request
Jul 8, 2024
This is done in the interest of assisting google#12075 and google#11626. Currently the Rust toolchain cannot be updated because the latest nightly uses LLVM 18.1.8 and coverage information breaks. This breakage is because LLVM 18.1.8 records coverage information with version "9" but LLVM 18.0.0 recorded coverage information with version "8". This means that the recordings created by Rust binaries use version "9" which are unreadable by the processing that OSS-Fuzz does with the 18.0.0-based toolchain using version "8". This commit updates the Clang toolchain to the latest 18.x.x release to get the two in sync so the same coverage recording version is used.
alexcrichton
added a commit
to alexcrichton/oss-fuzz
that referenced
this pull request
Jul 12, 2024
This is done in the interest of assisting google#12075 and google#11626. Currently the Rust toolchain cannot be updated because the latest nightly uses LLVM 18.1.8 and coverage information breaks. This breakage is because LLVM 18.1.8 records coverage information with version "9" but LLVM 18.0.0 recorded coverage information with version "8". This means that the recordings created by Rust binaries use version "9" which are unreadable by the processing that OSS-Fuzz does with the 18.0.0-based toolchain using version "8". This commit updates the Clang toolchain to the latest 18.x.x release to get the two in sync so the same coverage recording version is used.
fanquake
pushed a commit
to fanquake/oss-fuzz
that referenced
this pull request
Jul 30, 2024
This is done in the interest of assisting google#12075 and google#11626. Currently the Rust toolchain cannot be updated because the latest nightly uses LLVM 18.1.8 and coverage information breaks. This breakage is because LLVM 18.1.8 records coverage information with version "9" but LLVM 18.0.0 recorded coverage information with version "8". This means that the recordings created by Rust binaries use version "9" which are unreadable by the processing that OSS-Fuzz does with the 18.0.0-based toolchain using version "8". This commit updates the Clang toolchain to the latest 18.x.x release to get the two in sync so the same coverage recording version is used.
fanquake
pushed a commit
to fanquake/oss-fuzz
that referenced
this pull request
Jul 31, 2024
This is done in the interest of assisting google#12075 and google#11626. Currently the Rust toolchain cannot be updated because the latest nightly uses LLVM 18.1.8 and coverage information breaks. This breakage is because LLVM 18.1.8 records coverage information with version "9" but LLVM 18.0.0 recorded coverage information with version "8". This means that the recordings created by Rust binaries use version "9" which are unreadable by the processing that OSS-Fuzz does with the 18.0.0-based toolchain using version "8". This commit updates the Clang toolchain to the latest 18.x.x release to get the two in sync so the same coverage recording version is used.
fanquake
pushed a commit
to fanquake/oss-fuzz
that referenced
this pull request
Aug 1, 2024
This is done in the interest of assisting google#12075 and google#11626. Currently the Rust toolchain cannot be updated because the latest nightly uses LLVM 18.1.8 and coverage information breaks. This breakage is because LLVM 18.1.8 records coverage information with version "9" but LLVM 18.0.0 recorded coverage information with version "8". This means that the recordings created by Rust binaries use version "9" which are unreadable by the processing that OSS-Fuzz does with the 18.0.0-based toolchain using version "8". This commit updates the Clang toolchain to the latest 18.x.x release to get the two in sync so the same coverage recording version is used.
fanquake
pushed a commit
to fanquake/oss-fuzz
that referenced
this pull request
Aug 9, 2024
This is done in the interest of assisting google#12075 and google#11626. Currently the Rust toolchain cannot be updated because the latest nightly uses LLVM 18.1.8 and coverage information breaks. This breakage is because LLVM 18.1.8 records coverage information with version "9" but LLVM 18.0.0 recorded coverage information with version "8". This means that the recordings created by Rust binaries use version "9" which are unreadable by the processing that OSS-Fuzz does with the 18.0.0-based toolchain using version "8". This commit updates the Clang toolchain to the latest 18.x.x release to get the two in sync so the same coverage recording version is used.
catenacyber
pushed a commit
to catenacyber/oss-fuzz
that referenced
this pull request
Aug 16, 2024
This is done in the interest of assisting google#12075 and google#11626. Currently the Rust toolchain cannot be updated because the latest nightly uses LLVM 18.1.8 and coverage information breaks. This breakage is because LLVM 18.1.8 records coverage information with version "9" but LLVM 18.0.0 recorded coverage information with version "8". This means that the recordings created by Rust binaries use version "9" which are unreadable by the processing that OSS-Fuzz does with the 18.0.0-based toolchain using version "8". This commit updates the Clang toolchain to the latest 18.x.x release to get the two in sync so the same coverage recording version is used.
catenacyber
pushed a commit
to catenacyber/oss-fuzz
that referenced
this pull request
Sep 6, 2024
This is done in the interest of assisting google#12075 and google#11626. Currently the Rust toolchain cannot be updated because the latest nightly uses LLVM 18.1.8 and coverage information breaks. This breakage is because LLVM 18.1.8 records coverage information with version "9" but LLVM 18.0.0 recorded coverage information with version "8". This means that the recordings created by Rust binaries use version "9" which are unreadable by the processing that OSS-Fuzz does with the 18.0.0-based toolchain using version "8". This commit updates the Clang toolchain to the latest 18.x.x release to get the two in sync so the same coverage recording version is used.
catenacyber
pushed a commit
to catenacyber/oss-fuzz
that referenced
this pull request
Sep 17, 2024
This is done in the interest of assisting google#12075 and google#11626. Currently the Rust toolchain cannot be updated because the latest nightly uses LLVM 18.1.8 and coverage information breaks. This breakage is because LLVM 18.1.8 records coverage information with version "9" but LLVM 18.0.0 recorded coverage information with version "8". This means that the recordings created by Rust binaries use version "9" which are unreadable by the processing that OSS-Fuzz does with the 18.0.0-based toolchain using version "8". This commit updates the Clang toolchain to the latest 18.x.x release to get the two in sync so the same coverage recording version is used.
catenacyber
pushed a commit
to catenacyber/oss-fuzz
that referenced
this pull request
Sep 25, 2024
This is done in the interest of assisting google#12075 and google#11626. Currently the Rust toolchain cannot be updated because the latest nightly uses LLVM 18.1.8 and coverage information breaks. This breakage is because LLVM 18.1.8 records coverage information with version "9" but LLVM 18.0.0 recorded coverage information with version "8". This means that the recordings created by Rust binaries use version "9" which are unreadable by the processing that OSS-Fuzz does with the 18.0.0-based toolchain using version "8". This commit updates the Clang toolchain to the latest 18.x.x release to get the two in sync so the same coverage recording version is used.
DavidKorczynski
pushed a commit
that referenced
this pull request
Nov 20, 2024
Since the merge of #12075 reverting #11681, these lines are no longer needed and may in fact be breaking the build. The `lib` directory referenced for building the fuzzers was also renamed to `sdk` in surrealdb/surrealdb#4561.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This commit updates the default version of Rust installed for fuzzing to
the last nightly of Rust that used LLVM 17. The next version uses LLVM
18.1.7 which is incompatible with the fuzz infrastructure's own LLVM
which is currently 18.0.0. This is intended to update the Rust toolchain
as far as possible without causing coverage incompatibilities.
This additionally updates a few pinned projects to all use this nightly
as well. Furthermore the containers are now configured to by-default
ignore
rust-toolchainandrust-toolchain.tomlfiles which will forcethis particular toolchain to be used.