typeck: always expose repeat count `AnonConst`s' parent in `generics_of`.
This should reduce some of the confusion around #43408, although, if you look at the changed test outputs (for the last commit), they all hit #68436, so nothing new will start compiling.
We can let counts of "repeat expressions" (`N` in `[x; N]`) always have the correct generics parenting, because they're always in a body, so nothing in the `where` clauses or `impl` trait/type of the parent can use it, and therefore no query cycles can occur.
<hr/>
Other potential candidates we might want to apply the same approach to, are:
* ~~(easy) `enum` discriminants (see also #70453)~~ opened #70825
* (trickier) array *type* (not *expression*) lengths nested in:
* bodies
* types of (associated or not) `const`/`static`
* RHS of `type` aliases and associated `type`s
* `fn` signatures
We should've done so from the start, the only reason we haven't is because I was squeamish about blacklisting some of the cases, but if we whitelist instead we should be fine.
Also, lazy normalization is taking forever 😞.
<hr/>
There's also 5 other commits here:
* "typeck: track any errors injected during writeback and taint tables appropriately." - fixes#66706, as the next commit would otherwise trigger an ICE again
* "typeck: workaround WF hole in `to_const`." - its purpose is to emulate most of #70107's direct effect, at least in the case of repeat expressions, where the count always goes through `to_const`
* this is the reason no new code can really compile, as the WF checks require #68436 to bypass
* however, this has more test changes than I hoped, so it should be reviewed separately, and maybe even landed separately (as #70107 might take a while, as it's blocked on a few of my PRs)
* "ty: erase lifetimes early in `ty::Const::eval`." - first attempt at fixing #70773
* still useful, I believe the new approach is less likely to cause issues long-term
* I could take this out or move it into another PR if desired or someone else could take over (cc @skinny121)
* "traits/query/normalize: add some `debug!` logging for the result." - debugging aid for #70773
* "borrow_check/type_check: normalize `Aggregate` and `Call` operands." - actually fixes#70773
r? @nikomatsakis cc @pnkfelix @varkor @yodaldevoid @oli-obk @estebank
It is already possible to extract the pointer part of a raw slice by a
simple cast, but retrieving the length is not possible without relying
on the representation of the raw slice when it is not valid to convert
the raw slice into a slice reference (i.e. the pointer is null or
unaligned).
Introduce a len() method on raw slices to add this missing feature.
This appears to have never been used ever since its introduction in 61c7569d4 --
the plugin discussed on the PR introducing that commit, 34811, never
materialized.
It's also simple to readd in the current scheme, but given that macro expansion
is already quite complicated, additional useless state seems good to remove
while we're not using it.
incremental compilation.
This is symmetric to PR #67020, which handled the case where the LLVM module's
*imports* changed. This commit builds upon the infrastructure added there; the
export map is just the inverse of the import map, so we can build the export map
at the same time that we load the serialized import map.
Fix#69798
Remove the last remnant of unsigned Neg
It's been gone since #23945, before Rust 1.0. The former wrapping
semantics have also been available as inherent methods for a long time
now. There's no reason to keep this unused macro around.
Some helpers functions have been introduced to deal with (buggy) cases
where either a `NodeId` or a `DefId` do not have a corresponding `HirId`.
Those cases are tracked in issue #71104.
Improve async-await/generator obligation errors in some cases
Fixes#68112.
This change is best read one commit at a time (I add a test at the beginning and update it in each change after).
The `test2` function is a case I found while writing the test that we don't handle with this code yet. I don't attempt to fix it in this PR, but it's a good candidate for future work.
r? @davidtwco, @nikomatsakis
