### What does this PR try to resolve?
This is a horrible hack,
which lets the rustc invocation for learning target info always emit
warnings as warnings.
But at least it unblocks people who pass `-Awarnings` via RUSTFLAGS.
A long-term solution is a better interface
between build systems and the compiler.
See the discussion on Zulip:
https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Improving.20communication.20interface.20between.20cargo.2FrustcFixesrust-lang/cargo#8010
### How should we test and review this PR?
Ensure `CFG_DISABLE_CROSS_TESTS` is not set,
and run `cargo t --test testsuite
always_emit_warnings_as_warnings_when_learning_target_info`
This also additionally adds `wasm32-unknown-unknown` target to Cargo's
CI.
### Additional information
Instead of allowing any type in metadata, we were specifying fields like
`"string": "<any string>"`.
Found this when looking into #15030
<!--
Thanks for submitting a pull request 🎉! Here are some tips for you:
* If this is your first contribution, read "Cargo Contribution Guide"
first:
https://doc.crates.io/contrib/
* Run `cargo fmt --all` to format your code changes.
* Small commits and pull requests are always preferable and easy to
review.
* If your idea is large and needs feedback from the community, read how:
https://doc.crates.io/contrib/process/#working-on-large-features
* Cargo takes care of compatibility. Read our design principles:
https://doc.crates.io/contrib/design.html
* When changing help text of cargo commands, follow the steps to
generate docs:
https://github.com/rust-lang/cargo/tree/master/src/doc#building-the-man-pages
* If your PR is not finished, set it as "draft" PR or add "WIP" in its
title.
* It's ok to use the CI resources to test your PR, but please don't
abuse them.
### What does this PR try to resolve?
Explain the motivation behind this change.
A clear overview along with an in-depth explanation are helpful.
You can use `Fixes #<issue number>` to associate this PR to an existing
issue.
### How should we test and review this PR?
Demonstrate how you test this change and guide reviewers through your
PR.
With a smooth review process, a pull request usually gets reviewed
quicker.
If you don't know how to write and run your tests, please read the
guide:
https://doc.crates.io/contrib/tests
### Additional information
Other information you want to mention in this PR, such as prior arts,
future extensions, an unresolved problem, or a TODO list.
-->
I found a bug in the manifest parser and figured this would help make it
more obvious.
Since I was already changing the order, I figure I'm make things a
little more logical (user-facing first, implementtion details later)
### What does this PR try to resolve?
Instead of saying no package found when there are hidden `Summary`s,
we'll instead say why the summary was hidden in the cases of
- Yanked packages
- Schema mismatch
- Offline packages?
The schema mismatch covers part of #10623. Whats remaining is when we
can't parse the `Summary` but can parse a subset (name, version, schema
version, optionally rust-version). That will be handled in a follow up.
### How should we test and review this PR?
This has a couple of risky areas
- Moving the filtering of `IndexSummary` variants from the Index to the
Registry Source. On inspection, there were other code paths but they
seemed innocuous to not filter, like asking for a hash of a summary
- Switching `PackageRegistry` to preserve the `IndexSummary` variant for
regular sources and overrides
- I did not switch patches to preserve `IndexSummary` as that was more
invasive and the benefits seemed more minor (normally people patch over
registry dependencies and not to them)
### Additional information
As we abstract aware the env variables, users can't do a good job of
reporting these, so we'll do it ourselves.
We could make the traits public and take and explicit `env` parameter.
I figured we can wait until there is a motivating use case.
`build_env` does have a fancier `Env` impl where you pass it HOST and
TARGET and it automatically looks up values for those with a fallback
scheme.
This may look redundant with `CARGO_FEATURE_<CASE_CONVERTED_NAME>=1`
except that doesn't provide a lossless way of getting the names, e.g. for
forwarding for child builds like tests that need to build examples.
This also makes things more consistent as users
conditionalize on features through `cfg` and this even fits with what
the `CARGO_CFG_` docs say:
> For each configuration option of the package being built, this
> environment variable will contain the value of the configuration, where
> <cfg> is the name of the configuration uppercased and having -
> translated to _. Boolean configurations are present if they are set, and
> not present otherwise. Configurations with multiple values are joined to
> a single variable with the values delimited by ,. This includes values
> built-in to the compiler (which can be seen with rustc --print=cfg) and
> values set by build scripts and extra flags passed to rustc (such as
> those defined in RUSTFLAGS). Some examples of what these variables are:
Fixes#3702
Our MSRV is much higher than 1.77. Also, as time goes on, there is less
incentive to drop it below 1.77, especially with the MSRV-aware resolver
in 1.84
