Align `Term` methods with `GenericArg` methods, add `Term::expect_*`
* `Term::ty` -> `Term::as_type`.
* `Term::ct` -> `Term::as_const`.
* Adds `Term::expect_type` and `Term::expect_const`, and uses them in favor of `.ty().unwrap()`, etc.
I could also shorten these to `as_ty` and then do `GenericArg::as_ty` as well, but I do think the `as_` is important to signal that this is a conversion method, and not a getter, like `Const::ty` is.
r? types
Make `WHERE_CLAUSES_OBJECT_SAFETY` a regular object safety violation
#### The issue
In #50781, we have known about unsound `where` clauses in function arguments:
```rust
trait Impossible {}
trait Foo {
fn impossible(&self)
where
Self: Impossible;
}
impl Foo for &() {
fn impossible(&self)
where
Self: Impossible,
{}
}
// `where` clause satisfied for the object, meaning that the function now *looks* callable.
impl Impossible for dyn Foo {}
fn main() {
let x: &dyn Foo = &&();
x.impossible();
}
```
... which currently segfaults at runtime because we try to call a method in the vtable that doesn't exist. :(
#### What did u change
This PR removes the `WHERE_CLAUSES_OBJECT_SAFETY` lint and instead makes it a regular object safety violation. I choose to make this into a hard error immediately rather than a `deny` because of the time that has passed since this lint was authored, and the single (1) regression (see below).
That means that it's OK to mention `where Self: Trait` where clauses in your trait, but making such a trait into a `dyn Trait` object will report an object safety violation just like `where Self: Sized`, etc.
```rust
trait Impossible {}
trait Foo {
fn impossible(&self)
where
Self: Impossible; // <~ This definition is valid, just not object-safe.
}
impl Foo for &() {
fn impossible(&self)
where
Self: Impossible,
{}
}
fn main() {
let x: &dyn Foo = &&(); // <~ THIS is where we emit an error.
}
```
#### Regressions
From a recent crater run, there's only one crate that relies on this behavior: https://github.com/rust-lang/rust/pull/124305#issuecomment-2122381740. The crate looks unmaintained and there seems to be no dependents.
#### Further
We may later choose to relax this (e.g. when the where clause is implied by the supertraits of the trait or something), but this is not something I propose to do in this FCP.
For example, given:
```
trait Tr {
fn f(&self) where Self: Blanket;
}
impl<T: ?Sized> Blanket for T {}
```
Proving that some placeholder `S` implements `S: Blanket` would be sufficient to prove that the same (blanket) impl applies for both `Concerete: Blanket` and `dyn Trait: Blanket`.
Repeating here that I don't think we need to implement this behavior right now.
----
r? lcnr
The flag propagates cargo configs to `rustc-perf --cargo-config`,
which is particularly useful when the environment is air-gapped,
and you want to use the default set of training crates vendored
in the rustc-src tarball.
The `mir!` macro has multiple parts:
- An optional return type annotation.
- A sequence of zero or more local declarations.
- A mandatory starting anonymous basic block, which is brace-delimited.
- A sequence of zero of more additional named basic blocks.
Some `mir!` invocations use braces with a "block" style, like so:
```
mir! {
let _unit: ();
{
let non_copy = S(42);
let ptr = std::ptr::addr_of_mut!(non_copy);
// Inside `callee`, the first argument and `*ptr` are basically
// aliasing places!
Call(_unit = callee(Move(*ptr), ptr), ReturnTo(after_call), UnwindContinue())
}
after_call = {
Return()
}
}
```
Some invocations use parens with a "block" style, like so:
```
mir!(
let x: [i32; 2];
let one: i32;
{
x = [42, 43];
one = 1;
x = [one, 2];
RET = Move(x);
Return()
}
)
```
And some invocations uses parens with a "tighter" style, like so:
```
mir!({
SetDiscriminant(*b, 0);
Return()
})
```
This last style is generally used for cases where just the mandatory
starting basic block is present. Its braces are placed next to the
parens.
This commit changes all `mir!` invocations to use braces with a "block"
style. Why?
- Consistency is good.
- The contents of the invocation is a block of code, so it's odd to use
parens. They are more normally used for function-like macros.
- Most importantly, the next commit will enable rustfmt for
`tests/mir-opt/`. rustfmt is more aggressive about formatting macros
that use parens than macros that use braces. Without this commit's
changes, rustfmt would break a couple of `mir!` macro invocations that
use braces within `tests/mir-opt` by inserting an extraneous comma.
E.g.:
```
mir!(type RET = (i32, bool);, { // extraneous comma after ';'
RET.0 = 1;
RET.1 = true;
Return()
})
```
Switching those `mir!` invocations to use braces avoids that problem,
resulting in this, which is nicer to read as well as being valid
syntax:
```
mir! {
type RET = (i32, bool);
{
RET.0 = 1;
RET.1 = true;
Return()
}
}
```
Improve compiletest expected/not found formatting
compiletest, oh compiletest, you are truly one of the tools in this repository. You're the omnipresent gatekeeper, ensuring that every new change works, doesn't break the world, and is nice. We thank you for your work, for your tests, for your test runs, for your features that help writing tests, for all the stability and and good you have caused. Without you, Rust wouldn't exist as it does, without you, nothing would work, without you, we would all go insane from having changes break and having to test them all by hand. Thank you, compiletest.
but holy shit i fucking hate your stupid debug output so much i simply cannot take this anymore aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
By changing a few magic lines in this file called "runtest.rs", we can cause compiletest to emit nicer messages. This is widely regarded as a good thing. We stop wasting vertical space, allowing more errors to be displayed at once. Additionally, we add colors, which make it so much more pretty *and* gay, both of which are very good and useful.
There's a bit of fuckery needed to get the colors to work. `colored` checks whether stdout is a terminal. We also print to stdout, so that works well.
But.... for some stupid reason that I absolutely refuse to even attempt to debug, stdout is *not* a terminal when executing tests *in a terminal*.
But stderr is >:).
So this just checks whether stderr is a terminal.
If you have a use case where you dump compiletest stdout into a place where colors are not supported while having stderr be a terminal, then I'm sorry for you, but you are gonna get colors and you're gonna like it. Stop it with the usual environment variable, which `colored` also respects by default.
### before (bad, hurts your brain, makes you want to cry)
## after (good, gay, makes you want to cry)
r? jieyouxu said he wants to review the PR
Rollup of 3 pull requests
Successful merges:
- #125311 (Make repr(packed) vectors work with SIMD intrinsics)
- #125849 (Migrate `run-make/emit-named-files` to `rmake.rs`)
- #125851 (Add some more specific checks to the MIR validator)
r? `@ghost`
`@rustbot` modify labels: rollup
compiletest, oh compiletest, you are truly one of the tools in this
repository. You're the omnipresent gatekeeper, ensuring that every new
change works, doesn't break the world, and is nice. We thank you for
your work, for your tests, for your test runs, for your features that
help writing tests, for all the stability and and good you have caused.
Without you, Rust wouldn't exist as it does, without you, nothing would
work, without you, we would all go insane from having changes break and
having to test them all by hand. Thank you, compiletest.
but holy shit i fucking hate your stupid debug output so much i simply
cannot take this anymore aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
By changing a few magic lines in this file called "runtest.rs", we can
cause compiletest to emit nicer messages. This is widely regarded as a
good thing. We stop wasting vertical space, allowing more errors to be
displayed at once. Additionally, we add colors, which make it so much
more pretty *and* gay, both of which are very good and useful.
There's a bit of fuckery needed to get the colors to work. `colored`
checks whether stdout is a terminal. We also print to stdout, so that
works well.
But.... for some stupid reason that I absolutely refuse to even attempt
to debug, stdout is *not* a terminal when executing tests *in a
terminal*.
But stderr is >:).
So this just checks whether stderr is a terminal.
If you have a use case where you dump compiletest stdout into a place
where colors are not supported while having stderr be a terminal, then
I'm sorry for you, but you are gonna get colors and you're gonna like
it. Stop it with the usual environment variable, which `colored` also
respects by default.
When implementing support for rmake.rs, I copied over the `$TMPDIR`
directory logic from the legacy Makefile setup. In doing so, I also
compiled recipe `rmake.rs` into executables which unfortunately are
placed into `$TMPDIR` as well.
This causes a problem on Windows where:
- The `rmake.exe` executable is placed in `$TMPDIR`.
- We run the `rmake.exe` as a process.
- The process uses `rmake.exe` inside `$TMPDIR`.
- Windows prevents the .exe file from being deleted when the process
is still alive.
- The recipe test code tries to `remove_dir_all($TMPDIR)`, which fails
with access denied because `rmake.exe` is still being used.
We fix this by separating the recipe executable and the sratch
directory:
```
base_dir/
rmake.exe
scratch/
```
We construct a base directory, unique to each run-make test, under
which we place rmake.exe alongside a `scratch/` directory. This
`scratch/` directory is what is passed to rmake.rs tests as `$TMPDIR`,
so now `remove_dir_all($TMPDIR)` has a chance to succeed because
it no longer contains `rmake.exe`.
Oops. This was a fun one to try figure out.
Uplift `{Closure,Coroutine,CoroutineClosure}Args` and friends to `rustc_type_ir`
Part of converting the new solver's `structural_traits.rs` to be interner-agnostic.
I decided against aliasing `ClosureArgs<TyCtxt<'tcx>>` to `ClosureArgs<'tcx>` because it seemed so rare. I could do so if desired, though.
r? lcnr
fix diagnostics clearing when flychecks run per-workspace
This might be causing #17300 or it's a different bug with the same functionality.
I wonder if the decision to clear diagnostics should stay in the main loop or maybe the flycheck itself should track it and tell the mainloop?
I have used a hash map but we could just as well use a vector since the IDs are `usizes` in some given range starting at 0. It would be probably faster but this just felt a bit cleaner and it allows us to change the ID to newtype later and we can just use a hasher that returns the underlying integer.
Update cargo
9 commits in 431db31d0dbeda320caf8ef8535ea48eb3093407..7a6fad0984d28c8330974636972aa296b67c4513
2024-05-28 18:17:31 +0000 to 2024-05-31 22:26:03 +0000
- fix(config): Ensure `--config net.git-fetch-with-cli=true` is respected (rust-lang/cargo#13992)
- Fix libcurl proxy documentation link (rust-lang/cargo#13990)
- fix(new): Dont say were adding to a workspace when a regular package is in root (rust-lang/cargo#13987)
- fix: adjust custom err from cert-check due to libgit2 1.8 change (rust-lang/cargo#13970)
- fix(toml): Ensure targets are in a deterministic order (rust-lang/cargo#13989)
- doc(cargo-package): explain no guarantee of vcs provenance (rust-lang/cargo#13984)
- chore: fix some comments (rust-lang/cargo#13982)
- feat: stabilize `cargo update --precise <yanked>` (rust-lang/cargo#13974)
- Update openssl-src to 111.28.2+1.1.1w (rust-lang/cargo#13976)
r? ghost
Support mdBook preprocessors for TRPL in rustbook
`rust-lang/book` recently added two mdBook preprocessors. Enable `rustbook` to use those preprocessors for books where they are requested by the `book.toml` by adding the preprocessors as path dependencies, and ignoring them where they are not requested, i.e. by all the books other than TRPL at present.
Addresses rust-lang/book#3927
Don't build the `rust-demangler` binary for coverage tests
The coverage-run tests invoke `llvm-cov`, which requires us to specify a command-line demangler that it can use to demangle Rust symbol names.
Historically this used `src/tools/rust-demangler`, which means that we currently build two different command-line tools to help with the coverage tests (`rust-demangler` and `coverage-dump`).
However, it occurred to me that if we add a demangler mode to `coverage-dump` (which is only a handful of lines and no extra dependencies), then we only need to build one helper binary for the coverage tests, and there is no need for tests to build `rust-demangler` at all.
---
Note that the `rust-demangler` binary is separate from the `rustc-demangle` crate (which both `rust-demangler` and `coverage-dump` use as a dependency to do the actual demangling).
---
So the main benefits/motivations here are:
- Slightly faster builds after a fresh checkout or bootstrap bump.
- Making it clear that currently no tests actually need the `rust-demangler` binary, since the coverage tests can use their own tool instead.
Implement `needs_async_drop` in rustc and optimize async drop glue
This PR expands on #121801 and implements `Ty::needs_async_drop` which works almost exactly the same as `Ty::needs_drop`, which is needed for #123948.
Also made compiler's async drop code to look more like compiler's regular drop code, which enabled me to write an optimization where types which do not use `AsyncDrop` can simply forward async drop glue to `drop_in_place`. This made size of the async block from the [async_drop test](67980dd6fb/tests/ui/async-await/async-drop.rs) to decrease by 12%.
Rename HIR `TypeBinding` to `AssocItemConstraint` and related cleanup
Rename `hir::TypeBinding` and `ast::AssocConstraint` to `AssocItemConstraint` and update all items and locals using the old terminology.
Motivation: The terminology *type binding* is extremely outdated. "Type bindings" not only include constraints on associated *types* but also on associated *constants* (feature `associated_const_equality`) and on RPITITs of associated *functions* (feature `return_type_notation`). Hence the word *item* in the new name. Furthermore, the word *binding* commonly refers to a mapping from a binder/identifier to a "value" for some definition of "value". Its use in "type binding" made sense when equality constraints (e.g., `AssocTy = Ty`) were the only kind of associated item constraint. Nowadays however, we also have *associated type bounds* (e.g., `AssocTy: Bound`) for which the term *binding* doesn't make sense.
---
Old terminology (HIR, rustdoc):
```
`TypeBinding`: (associated) type binding
├── `Constraint`: associated type bound
└── `Equality`: (associated) equality constraint (?)
├── `Ty`: (associated) type binding
└── `Const`: associated const equality (constraint)
```
Old terminology (AST, abbrev.):
```
`AssocConstraint`
├── `Bound`
└── `Equality`
├── `Ty`
└── `Const`
```
New terminology (AST, HIR, rustdoc):
```
`AssocItemConstraint`: associated item constraint
├── `Bound`: associated type bound
└── `Equality`: associated item equality constraint OR associated item binding (for short)
├── `Ty`: associated type equality constraint OR associated type binding (for short)
└── `Const`: associated const equality constraint OR associated const binding (for short)
```
r? compiler-errors
compiletest: clarify COMPILETEST_NEEDS_ALL_LLVM_COMPONENTS error
COMPILETEST_NEEDS_ALL_LLVM_COMPONENTS is a confusing name because elsewhere "needs" means "ignore when requirement not met", but here it means "fail when requirement not met".
