Add checksums cache to build-manifest
During the release process we're currently calculating the SHA256 of each file three times:
1. In `build-manifest`, to fill the `hash = "f00"` keys of the manifests.
2. In `promote-release`, to generate the `.sha256` files.
3. In `promote-release`, to generate the `.asc` GPG signatures.
Calculations 1. and 2. could be merged into a single one if there was a way for `build-manifest` to pass the checksums it generated over to `promote-release`. Unfortunately calculation 3. can't be merged as GPG requires extra metadata to be hashed.
This PR adds support for merging 1. and 2. by creating the `BUILD_MANIFEST_CHECKSUM_CACHE` environment variable, which points to a JSON file storing a cache of all the calculated checksums. `build-manifest` will load it at startup and avoid generating existing checksums, and it will dump its internal checksums cache into it when it exits successfully.
This PR also allows to run `build-manifest` multiple times without the need to wait for checksums to be calculated in the following invocations. The speedup will allow to work torwards a fix for https://github.com/rust-lang/promote-release/issues/15 without impacting the release process duration nor our storage costs.
This PR can be reviewed commit-by-commit.
r? `@Mark-Simulacrum`
This commit adds to the generated manifest all files we ship that are
not rustup components, namely:
* Source code tarballs (rustc-{channel}-src.tar.xz)
* Windows installers (rust-{channel}-{target}.msi)
* macOS installers (rust-{channel}-{target}.pkg)
Those files are included in a new "artifacts" table of the manifest, to
avoid interfering with existing rustup installations.
Iterate over the smaller list
If there are two lists of different sizes,
iterating over the smaller list and then
looking up in the larger list is cheaper
than vice versa, because lookups scale
sublinearly.
resolve: private fields in tuple struct ctor diag
Fixes#75906.
This PR improves the diagnostic emitted when a tuple struct is being constructed which has private fields so that private fields are labelled and the message is improved.
r? @estebank
Add const_fn in generics test
Adds a test that constant functions in generic parameters work properly. I was surprised this works, but I also to turbofish the constant in main, otherwise it didn't infer properly:
```
let v: ConstU32<3> = ...
```
Did not work as I expected, which I can highlight in the test if that's the intended behaviour.
r? @lcnr
Tweak invalid `fn` header and body parsing
* Rely on regular "expected"/"found" parser error for `fn`, fix#77115
* Recover empty `fn` bodies when encountering `}`
* Recover trailing `>` in return types
* Recover from non-type in array type `[<BAD TOKEN>; LEN]`
check object safety of generic constants
As `Self` can only be effectively used in constants with `const_evaluatable_checked` this should not matter outside of it.
Implements the first item of #72219
> Object safety interactions with constants
r? @oli-obk for now cc @nikomatsakis
Move "mutable thing in const" check from interning to validity
This moves the check for mutable things (such as `UnsafeCell` or `&mut`) in a`const` from interning to validity. That means we can give more targeted error messages (pointing out *where* the problem lies), and we can simplify interning a bit.
Also fix the interning mode used for promoteds in statics.
r? @oli-obk
Suggest calling await on method call and field access
When encountering a failing method or field resolution on a `Future`,
look at the `Output` and try the same operation on it. If successful,
suggest calling `.await` on the `Future`.
This had already been introduced in #72784, but at some point they
stopped working.
Built on top of #78214, only last commit is relevant.
r? @oli-obk
Separate unsized locals
Closes#71694
Takes over again #72029 and #74971
cc @RalfJung @oli-obk @pnkfelix @eddyb as they've participated in previous reviews of this PR.
Uplift `temporary-cstring-as-ptr` lint from `clippy` into rustc
The general consensus seems to be that this lint covers a common enough mistake to warrant inclusion in rustc.
The diagnostic message might need some tweaking, as I'm not sure the use of second-person perspective matches the rest of rustc, but I'd like to hear others' thoughts on that.
(cc #53224).
r? `@oli-obk`
