| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
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
|
|
|
|
|
|
r=compiler-errors
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
|
|
|
|
Clippy subtree update
r? `@Manishearth`
|
|
clippy-subtree-update
|
|
Make `body_owned_by` return the `Body` instead of just the `BodyId`
fixes #125677
Almost all `body_owned_by` callers immediately called `body`, too, so just return `Body` directly.
This makes the inline-const query feeding more robust, as all calls to `body_owned_by` will now yield a body for inline consts, too.
I have not yet figured out a good way to make `tcx.hir().body()` return an inline-const body, but that can be done as a follow-up
|
|
don't inhibit random field reordering on repr(packed(1))
`inhibit_struct_field_reordering_opt` being false means we exclude this type from random field shuffling. However, `packed(1)` types can still be shuffled! The logic was added in https://github.com/rust-lang/rust/pull/48528 since it's pointless to reorder fields in packed(1) types (there's no padding that could be saved) -- but that shouldn't inhibit `-Zrandomize-layout` (which did not exist at the time).
We could add an optimization elsewhere to not bother sorting the fields for `repr(packed)` types, but I don't think that's worth the effort.
This *does* change the behavior in that we may now reorder fields of `packed(1)` structs (e.g. if there are niches, we'll try to move them to the start/end, according to `NicheBias`). We were always allowed to do that but so far we didn't. Quoting the [reference](https://doc.rust-lang.org/reference/type-layout.html):
> On their own, align and packed do not provide guarantees about the order of fields in the layout of a struct or the layout of an enum variant, although they may be combined with representations (such as C) which do provide such guarantees.
|
|
Almost all callers want this anyway, and now we can use it to also return fed bodies
|
|
call
|
|
|
|
clippy-subtree-update
|
|
|
|
Rollup of 4 pull requests
Successful merges:
- #124948 (chore: Remove repeated words (extension of #124924))
- #124992 (Add example to IsTerminal::is_terminal)
- #125279 (make `Debug` impl for `Term` simpler)
- #125286 (Miri subtree update)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
chore: Remove repeated words (extension of #124924)
When I saw #124924 I thought "Hey, I'm sure that there are far more than just two typos of this nature in the codebase". So here's some more typo-fixing.
Some found with regex, some found with a spellchecker. Every single one manually reviewed by me (along with hundreds of false negatives by the tools)
|
|
generics' attributes
|
|
Rename Unsafe to Safety
Alternative to #124455, which is to just have one Safety enum to use everywhere, this opens the posibility of adding `ast::Safety::Safe` that's useful for unsafe extern blocks.
This leaves us today with:
```rust
enum ast::Safety {
Unsafe(Span),
Default,
// Safe (going to be added for unsafe extern blocks)
}
enum hir::Safety {
Unsafe,
Safe,
}
```
We would convert from `ast::Safety::Default` into the right Safety level according the context.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Make `Ty::builtin_deref` just return a `Ty`
Nowhere in the compiler are we using the mutability part of the `TyAndMut` that we used to return.
|
|
Rollup of 7 pull requests
Successful merges:
- #124551 (Add benchmarks for `impl Debug for str`)
- #124915 (`rustc_target` cleanups)
- #124918 (Eliminate some `FIXME(lcnr)` comments)
- #124927 (opt-dist: use xz2 instead of xz crate)
- #124936 (analyse visitor: build proof tree in probe)
- #124943 (always use `GenericArgsRef`)
- #124955 (Use fewer origins when creating type variables.)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
|
|
Simplify `use crate::rustc_foo::bar` occurrences.
They can just be written as `use rustc_foo::bar`, which is far more standard. (I didn't even know that a `crate::` prefix was valid.)
r? ``@eholk``
|
|
Generic `NonZero` post-stabilization changes.
Tracking issue: https://github.com/rust-lang/rust/issues/120257
r? ``@dtolnay``
|
|
Remove braces when fixing a nested use tree into a single item
[Back in 2019](https://github.com/rust-lang/rust/pull/56645) I added rustfix support for the `unused_imports` lint, to automatically remove them when running `cargo fix`. For the most part this worked great, but when removing all but one childs of a nested use tree it turned `use foo::{Unused, Used}` into `use foo::{Used}`. This is slightly annoying, because it then requires you to run `rustfmt` to get `use foo::Used`.
This PR automatically removes braces and the surrouding whitespace when all but one child of a nested use tree are unused. To get it done I had to add the span of the nested use tree to the AST, and refactor a bit the code I wrote back then.
A thing I noticed is, there doesn't seem to be any `//@ run-rustfix` test for fixing the `unused_imports` lint. I created a test in `tests/suggestions` (is that the right directory?) that for now tests just what I added in the PR. I can followup in a separate PR to add more tests for fixing `unused_lints`.
This PR is best reviewed commit-by-commit.
|
|
|
|
|
|
They can just be written as `use rustc_foo::bar`, which is far more
standard. (I didn't even know that a `crate::` prefix was valid.)
|
|
clippy-subtree-update
|
|
`has_typeck_results` doesnt need to be a query
self-explanatory
|
|
clippy-subtree-update
|
|
|
|
|
|
Qualifier tweaking
Adding and removing qualifiers in some cases that make things nicer. Details in individual commits.
r? `@compiler-errors`
|
|
Move `SourceMap` initialization
So it happens at the same time as `SessionGlobals` initialization, rather than shortly afterward.
r? `@WaffleLapkin`
|
|
Because they're a bit redundant.
|
|
Because that's the way it should be done.
|
|
In some cases `DUMMY_SP` is already imported. In other cases this commit
adds the necessary import, in files where `DUMMY_SP` is used more than
once.
|
