Remove a loop which runs exactly once
Though the code seems to work properly, it is worth removing the loop entirely in order to not confuse the reader.
r? @estebank
The concrete type that will be too big is target dependent. Avoid
matching it in error annotation to make test work correctly across
different targets.
Previously, when compilation succeeded, neither error patterns nor error
annotation would be validated. Additionally, when compilation failed,
only error patterns would be validated if both error patterns and error
annotation were present.
Now both error patterns and error annotation are validated when present,
regardless of compilation status. Furthermore, for test that should run,
the error patterns are matched against executable output, which is what
some of tests already expect to happen, and when #65506 is merged even
more ui tests will.
When both error patterns and error annotations are present in an ui
test, only error patterns are validated against the output.
Replace the error pattern with an error annotation to avoid silently
ignoring the other error annotation.
The proper attribute was added to `simd_shuffle*` in
rust-lang/stdarch#825. This caused `promote_consts` to double-count its
second argument when recording promotion candidates, which caused
the promotion candidate compatibility check to fail.
Just to make it useable for profiling and such inside
rustc itself. It was vaguely useful in
https://wiki.alopex.li/WhereRustcSpendsItsTime and I figured
I might as well upstream it; I may or may not ever get around
to doing more with it (hopefully I will), but it may be useful
for others.
Partially revert the early feature-gatings added in #65742.
The intent here is to address #65860 ASAP (in time for beta, ideally), while leaving as much of #65742 around as possible, to make it easier to re-enable later.
Therefore, I've only kept the parts of the revert that re-add the old (i.e. non-early) feature-gating checks that were removed in #65742, and the test reverts.
I've disabled the new early feature-gating checks from #65742 entirely for now, but it would be easy to put them behind a `-Z` flag, or turn them into warnings, which would allow us to keep tests for both the early and late versions of the checks - assuming that's desirable.
cc @nikomatsakis @Mark-Simulacrum @Centril
Those annotation are silently ignored rather than begin validated
against compiler output. Update them before validation is enabled,
to avoid test failures.
Type parameters are referenced in the error message after the previous
few commits (using span label). But when the main error message already
references the very same type parameter it becomes clumsy. Do not show
the additional label in this case as per code review comment by
@estebank.
Also this contains a small style fix.
Fixes#47319.
Shows the type parameter definition(s) on type mismatch errors so the
context is clearer. Pretty much changes the following:
```
LL | bar1(t);
| ^
| |
| expected enum `std::option::Option`, found type parameter `T`
```
into:
```
LL | fn foo1<T>(t: T) {
| - this type parameter
LL | bar1(t);
| ^
| |
| expected enum `std::option::Option`, found type parameter `T`
```
Part of #47319.
This just adds type parameter name to type mismatch error message, so
e.g. the following:
```
expected enum `std::option::Option`, found type parameter
```
becomes
```
expected enum `std::option::Option`, found type parameter `T`
```
the docs are great at explaining that .len() isn't like in other
languages but stops short of explaining how to get the character length.
r? @steveklabnik
Because it's highly magical, which goes against the goal of keeping
`SymbolStr` simple. Plus it's only used in a handful of places that
only require minor changes.
