Previously, the pre-commit hook which runs `x test tidy` could pass only to have CI fail within the first 30 seconds.
This adds about 30 seconds to `test tidy` (for an initial run, much less after the tool is built the first time)
in exchange for catching errors in `.github/workflows/ci.yml` before they're pushed.
Previously, it would only run on changes to subtrees, submodules, or select directories.
That made it so that changes to the compiler that broke tools would only be detected on a full bors merge.
This makes it so the tools builder runs by default, making it easier to catch breaking changes to clippy (which was the most effected).
don't point at nonexisting code beyond EOF when warning about delims
Previously we would show this:
```
warning: unnecessary braces around block return value
--> /tmp/bad.rs:1:8
|
1 | fn a(){{{
| ^ ^
|
= note: `#[warn(unused_braces)]` on by default
help: remove these braces
|
1 - fn a(){{{
1 + fn a(){{
|
```
which is now hidden in this case.
We would create a span spanning between the pair of redundant {}s but there is only EOF instead of the `}` so we would previously point at nothing. This would cause the debug assertion ice to trigger. I would have loved to just only point at the second delim and say "you can remove that" but I'm not sure how to do that without refactoring the entire diagnostic which seems tricky. :( But given that this does not seem to regress any other tests we have, I think this edge-casey enough be acceptable.
Fixes https://github.com/rust-lang/rust/issues/107423
r? `@compiler-errors`
Especially when trying to diagnose runaway future sizes, it might be
more intuitive to sort the variants according to the control flow
(aka their yield points) rather than the size of the variants.
Change wording from "nullable" to "default".
Introduce a trait `IsDefault` for detecting values that are encoded as zeros or not encoded at all.
Add panics to impossible cases.
Some other minor cleanups.
Less import overhead for errors
This removes huge (3+ lines) import lists found in files that had their error reporting migrated. These lists are bad for developer workflows as adding, removing, or editing a single error's name might cause a chain reaction that bloats the git diff. As the error struct names are long, the likelihood of such chain reactions is high.
Follows the suggestion by `@Nilstrieb` in the [zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/147480-t-compiler.2Fwg-diagnostics/topic/massive.20use.20statements) to replace the `use errors::{FooErr, BarErr};` with `use errors;` and then changing to `errors::FooErr` on the usage sites.
I have used sed to do most of the changes, i.e. something like:
```
sed -i -E 's/(create_err|create_feature_err|emit_err|create_note|emit_fatal|emit_warning)\(([[:alnum:]]+|[A-Z][[:alnum:]:]*)( \{|\))/\1(errors::\2\3/' path/to/file.rs
```
& then I manually fixed the errors that occured. Most manual changes were required in `compiler/rustc_parse/src/parser/expr.rs`.
r? `@compiler-errors`
emit `ConstEquate` in `TypeRelating<D>`
emitting `ConstEquate` during mir typeck is useful since it can help catch bugs in hir typeck incase our impl of `ConstEquate` is wrong.
doing this did actually catch a bug, when relating `Expr::Call` we `==` the types of all the argument consts which spuriously returns false if the type contains const projections/aliases which causes us to fall through to the `expected_found` error arm.
Generally its an ICE if the `Const`'s `Ty`s arent equal but `ConstKind::Expr` is kind of special since they are sort of like const items that are `const CALL<F: const Fn(...), const N: F>` though we dont actually explicitly represent the `F` type param explicitly in `Expr::Call` so I just made us relate the `Const`'s ty field to avoid getting ICEs from the tests I added and the following existing test:
```rust
// tests/ui/const-generics/generic_const_exprs/different-fn.rs
#![feature(generic_const_exprs)]
#![allow(incomplete_features)]
use std::mem::size_of;
use std::marker::PhantomData;
struct Foo<T>(PhantomData<T>);
fn test<T>() -> [u8; size_of::<T>()] {
[0; size_of::<Foo<T>>()]
//~^ ERROR unconstrained generic constant
//~| ERROR mismatched types
}
fn main() {
test::<u32>();
}
```
which has us relate two `ConstKind::Value` one for the fn item of `size_of::<Foo<T>>` and one for the fn item of `size_of::<T>()`, these only differ by their `Ty` and if we don't relate the `Ty` we'll end up getting an ICE from the checks that ensure the `ty` fields always match.
In theory `Expr::UnOp` has the same problem so I added a call to `relate` for the ty's, although I was unable to create a repro test.
