Removes extra global bounds at the winnowing stage rather than when
normalizing the param_env. This avoids breaking inference when there is
a global bound.
Previously, we didn't send --features to our cargo metadata invocations,
and thus missed some dependencies that we enable through the --features
mechanism.
UI tests in bless mode should now check to see if `.nll.*` files have a
matching `.*` file. If a match is found, it will be deleted.
This should be extensible to other modes (i.e., Polonius).
On running with `--bless`, the two files removed in #51186 are, in turn,
removed automatically.
Tries to address the recent network issues
1. Set the DNS server to 8.8.8.8/8.8.4.4/1.1.1.1/1.0.0.1 to workaround the daily "Cannot resolve host" error these two weeks.
2. Remove the unnecessary command `gem update --system` (originally added as experiment of the "Could not find a valid gem" error, which turns out to be useless).
Deny #[cfg] and #[cfg_attr] on generic parameters.
Fix#51279.
Attributes on generic parameters are not expanded, meaning `#[cfg]`, `#[cfg_attr]` and attribute proc macros are entirely ignored on them.
This PR makes using the first two attributes an error, because if they are correctly expanded will affect the AST and change code behavior.
I'm beta-nominating this, because generic parameter attributes are stabilizing in 1.27, and if we did not reserve their usage, we may never be able to repurpose the meaning of these attributes in the Rust 2015 edition.
Remove two redundant .nll.stderr files
It turns out that the diagnostics generated from NLL for these cases are now exactly the same as that produced by AST borrowck, and thus we can just fallback on those `.stderr` files that already exist for AST-borrowck.
Bravo!
(it is a good idea to remove these files, because it slightly reduces the amount of time humans will spend reviewing the .nll.stderr fileset...)
((it *might* be worthwhile trying to change the `compiletest` code to even issue a warning when two such files have equivalent contents... but I am not going so far as to try to implement that right now...))
The only instance of `ObligationForest` in use has an obligation type of
`PendingPredicateObligation`, which contains a `PredicateObligation` and a
`Vec<Ty>`.
`FulfillmentContext::pending_obligations()` calls
`ObligationForest::pending_obligations()`, which clones all the
`PendingPredicateObligation`s. But the `Vec<Ty>` field of those cloned
obligations is never touched.
This patch changes `ObligationForest::pending_obligations()` to
`map_pending_obligations` -- which gives callers control about which part
of the obligation to clone -- and takes advantage of the change to avoid
cloning the `Vec<Ty>`. The change speeds up runs of a few rustc-perf
benchmarks, the best by 1%.
`process_predicates` returns a
`Result<Option<Vec<PredicateObligation>>>`. `process_obligation` calls
it and then fiddles with the output (using `map`, `map`, `into_iter`,
`collect`) to produce a a
`Result<Option<Vec<PendingPredicateObligation>>>`.
This function is sufficiently hot that the fiddling is expensive. It's
much better for `process_predicate` to directly return a
`Result<Option<Vec<PendingPredicateObligation>>>` because `Ok(None)`
accounts for ~90% of the results, and `Ok(vec![])` accounts for another
~5%.
