| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Because the empty string is not a keyword.
|
|
clippy-subtree-update
|
|
make `rustc_attr_parsing` less dominant in the rustc crate graph
It has/had a glob re-export of `rustc_attr_data_structures`, which is a crate much lower in the graph, and a lot of crates were using it *just* (or *mostly*) for that re-export, while they can rely on `rustc_attr_data_structures` directly.
Previous graph:
Graph with this PR:
The first commit keeps the re-export, and just changes the dependency if possible. The second commit is the "breaking change" which removes the re-export, and "explicitly" adds the `rustc_attr_data_structures` dependency where needed. It also switches over some src/tools/*.
The second commit is actually a lot more involved than I expected. Please let me know if it's a better idea to back it out and just keep the first commit.
|
|
|
|
rustc_on_unimplemented
|
|
|
|
clippy-subtree-update
|
|
|
|
Implement `Iterator::last` for `vec::IntoIter`
Avoid iterating everything when we have random access to the last element.
|
|
ismailarilik:handle-potential-query-instability-lint-for-rustc-middle, r=oli-obk
Handle `rustc_middle` cases of `rustc::potential_query_instability` lint
This PR removes `#![allow(rustc::potential_query_instability)]` line from [`compiler/rustc_middle/src/lib.rs`](https://github.com/rust-lang/rust/blob/master/compiler/rustc_middle/src/lib.rs#L29) and converts `FxHash{Map,Set}` types into `FxIndex{Map,Set}` to suppress lint errors.
A somewhat tracking issue: https://github.com/rust-lang/rust/issues/84447
r? `@compiler-errors`
|
|
|
|
|
|
|
|
clippy-subtree-update
|
|
implement or-patterns for pattern types
These are necessary to represent `NonZeroI32`, as the range for that is `..0 | 1..`. The `rustc_scalar_layout_range_*` attributes avoided this by just implementing wraparound and having a single `1..=-1` range effectively. See https://rust-lang.zulipchat.com/#narrow/channel/481660-t-lang.2Fpattern-types/topic/.60or.20pattern.60.20representation.20in.20type.20system/with/504217694 for some background discussion
cc https://github.com/rust-lang/rust/issues/123646
r? `@BoxyUwU`
|
|
Remove `weak` alias terminology
I find the "weak" alias terminology to be quite confusing. It implies the existence of "strong" aliases (which do not exist) and I'm not really sure what about weak aliases is "weak". I much prefer "free alias" as the term. I think it's much more obvious what it means as "free function" is a well defined term that already exists in rust.
It's also a little confusing given "weak alias" is already a term in linker/codegen spaces which are part of the compiler too. Though I'm not particularly worried about that as it's usually very obvious if you're talking about the type system or not lol. I'm also currently trying to write documentation about aliases and it's somewhat awkward/confusing to be talking about *weak* aliases, when I'm not really sure what the basis for that as the term actually *is*.
I would also be happy to just find out there's a nice meaning behind calling them "weak" aliases :-)
r? `@oli-obk`
maybe we want a types MCP to decide on a specific naming here? or maybe we think its just too late to go back on this naming decision ^^'
|
|
|
|
|
|
|
|
|
|
|
|
clippy-subtree-update
|
|
Remove `name_or_empty`
Another step towards #137978.
r? ``@jdonszelmann``
|
|
deref patterns: implement implicit deref patterns
This implements implicit deref patterns (per https://hackmd.io/4qDDMcvyQ-GDB089IPcHGg#Implicit-deref-patterns) and adds tests and an unstable book chapter.
Best reviewed commit-by-commit. Overall there's a lot of additions, but a lot of that is tests, documentation, and simple(?) refactoring.
Tracking issue: #87121
r? ``@Nadrieril``
|
|
I'm removing empty identifiers everywhere, because in practice they
always mean "no identifier" rather than "empty identifier". (An empty
identifier is impossible.) It's better to use `Option` to mean "no
identifier" because you then can't forget about the "no identifier"
possibility.
Some specifics:
- When testing an attribute for a single name, the commit uses the
`has_name` method.
- When testing an attribute for multiple names, the commit uses the new
`has_any_name` method.
- When using `match` on an attribute, the match arms now have `Some` on
them.
In the tests, we now avoid printing empty identifiers by not printing
the identifier in the `error:` line at all, instead letting the carets
point out the problem.
|
|
It's a much better name, more consistent with how we name such things.
Also rename `Lifetime::res` as `Lifetime::kind` to match. I suspect this
field used to have the type `LifetimeRes` and then the type was changed
but the field name remained the same.
|
|
To accurately reflect that RPITIT assoc items don't have a name. This
avoids the use of `kw::Empty` to mean "no name", which is error prone.
Helps with #137978.
|
|
From `hir::AssocItem`.
|
|
`hir::AssocItem` currently has a boolean `fn_has_self_parameter` field,
which is misplaced, because it's only relevant for associated fns, not
for associated consts or types. This commit moves it (and renames it) to
the `AssocKind::Fn` variant, where it belongs.
This requires introducing a new C-style enum, `AssocTag`, which is like
`AssocKind` but without the fields. This is because `AssocKind` values
are passed to various functions like `find_by_ident_and_kind` to
indicate what kind of associated item should be searched for, and having
to specify `has_self` isn't relevant there.
New methods:
- Predicates `AssocItem::is_fn` and `AssocItem::is_method`.
- `AssocItem::as_tag` which converts `AssocItem::kind` to `AssocTag`.
Removed `find_by_name_and_kinds`, which is unused.
`AssocItem::descr` can now distinguish between methods and associated
functions, which slightly improves some error messages.
|
|
To avoid unnecessary interning.
|
|
This allows us to better distinguish builtin and overloaded implicit
dereferences.
|
|
Tweak `DefPathData`
Some improvements in and around `DefPathData`, following on from #137977.
r? `@spastorino`
|
|
PR #137977 changed `DefPathData::TypeNs` to contain `Option<Symbol>` to
account for RPITIT assoc types being anonymous. This commit changes it
back to `Symbol` and gives anonymous assoc types their own variant. It
makes things a bit nicer overall.
|
|
Allow drivers to supply a list of extra symbols to intern
Allows adding new symbols as `const`s in external drivers, desirable in Clippy so we can use them in patterns to replace code like https://github.com/rust-lang/rust/blob/75530e9f72a1990ed2305e16fd51d02f47048f12/src/tools/clippy/clippy_lints/src/casts/cast_ptr_alignment.rs#L66
The Clippy change adds a couple symbols as a demo, the exact `clippy_utils` API and replacing other usages can be done on the Clippy side to minimise sync conflicts
---
try-job: aarch64-gnu
|
|
|
|
It bugs me when variables of type `Ident` are called `name`. It leads to
silly things like `name.name`. `Ident` variables should be called
`ident`, and `name` should be used for variables of type `Symbol`.
This commit improves things by by doing `s/name/ident/` on a bunch of
`Ident` variables. Not all of them, but a decent chunk.
|
|
Add new `PatKind::Missing` variants
To avoid some ugly uses of `kw::Empty` when handling "missing" patterns, e.g. in bare fn tys. Helps with #137978. Details in the individual commits.
r? ``@oli-obk``
|
|
impl !PartialOrd for HirId
revive of https://github.com/rust-lang/rust/pull/92233
Another checkbox of https://github.com/rust-lang/rust/issues/90317, another small step in making incremental less likely to die in horrible ways
|
|
|
|
|
|
|
|
In the AST, currently we use `BinOpKind` within `ExprKind::AssignOp` and
`AssocOp::AssignOp`, even though this allows some nonsensical
combinations. E.g. there is no `&&=` operator. Likewise for HIR and
THIR.
This commit introduces `AssignOpKind` which only includes the ten
assignable operators, and uses it in `ExprKind::AssignOp` and
`AssocOp::AssignOp`. (And does similar things for `hir::ExprKind` and
`thir::ExprKind`.) This avoids the possibility of nonsensical
combinations, as seen by the removal of the `bug!` case in
`lang_item_for_binop`.
The commit is mostly plumbing, including:
- Adds an `impl From<AssignOpKind> for BinOpKind` (AST) and `impl
From<AssignOp> for BinOp` (MIR/THIR).
- `BinOpCategory` can now be created from both `BinOpKind` and
`AssignOpKind`.
- Replaces the `IsAssign` type with `Op`, which has more information and
a few methods.
- `suggest_swapping_lhs_and_rhs`: moves the condition to the call site,
it's easier that way.
- `check_expr_inner`: had to factor out some code into a separate
method.
I'm on the fence about whether avoiding the nonsensical combinations is
worth the extra code.
|
|
Because it's nice to avoid passing in unnecessary data.
|
|
Move methods from `Map` to `TyCtxt`, part 5.
This eliminates all methods on `Map`. Actually removing `Map` will occur in a follow-up PR.
A follow-up to #137504.
r? `@Zalathar`
|
|
Various local trait item iteration cleanups
Adding a trait impl for `Foo` unconditionally affected all queries that are interested in a completely independent trait `Bar`. Perf has no effect on this. We probably don't have a good perf test for this tho.
r? `@compiler-errors`
I am unsure about https://github.com/rust-lang/rust/pull/139018/commits/9d05efb66f7b599eeacb5d2456f844fe4768e865 as it doesn't improve anything wrt incremental, because we still do all the checks for valid `Drop` impls, which subsequently will still invoke many queries and basically keep the depgraph the same.
I want to do
https://github.com/rust-lang/rust/blob/9549077a47099dc826039c051b528d1013740e6f/compiler/rustc_middle/src/ty/trait_def.rs#L141
but would leave that to a follow-up PR, this one changes enough things as it is
|
|
|
|
This eliminates all methods on `Map`. Actually removing `Map` will occur
in a follow-up PR.
|
|
remove `feature(inline_const_pat)`
Summarizing https://rust-lang.zulipchat.com/#narrow/channel/144729-t-types/topic/remove.20feature.28inline_const_pat.29.20and.20shared.20borrowck.
With https://github.com/rust-lang/types-team/issues/129 we will start to borrowck items together with their typeck parent. This is necessary to correctly support opaque types, blocking the new solver and TAIT/ATPIT stabilization with the old one. This means that we cannot really support `inline_const_pat` as they are implemented right now:
- we want to typeck inline consts together with their parent body to allow inference to flow both ways and to allow the const to refer to local regions of its parent.This means we also need to borrowck the inline const together with its parent as that's necessary to properly support opaque types
- we want the inline const pattern to participate in exhaustiveness checking
- to participate in exhaustiveness checking we need to evaluate it, which requires borrowck, which now relies on borrowck of the typeck root, which ends up checking exhaustiveness again. **This is a query cycle**.
There are 4 possible ways to handle this:
- stop typechecking inline const patterns together with their parent
- causes inline const patterns to be different than inline const exprs
- prevents bidirectional inference, we need to either fail to compile `if let const { 1 } = 1u32` or `if let const { 1u32 } = 1`
- region inference for inline consts will be harder, it feels non-trivial to support inline consts referencing local regions from the parent fn
- inline consts no longer participate in exhaustiveness checking. Treat them like `pat if pat == const { .. }` instead. We then only evaluate them after borrowck
- difference between `const { 1 }` and `const FOO: usize = 1; match x { FOO => () }`. This is confusing
- do they carry their weight if they are now just equivalent to using an if-guard
- delay exhaustiveness checking until after borrowck
- should be possible in theory, but is a quite involved change and may have some unexpected challenges
- remove this feature for now
I believe we should either delay exhaustiveness checking or remove the feature entirely. As moving exhaustiveness checking to after borrow checking is quite complex I think the right course of action is to fully remove the feature for now and to add it again once/if we've got that implementation figured out.
`const { .. }`-expressions remain stable. These seem to have been the main motivation for https://github.com/rust-lang/rfcs/issues/2920.
r? types
cc `@rust-lang/types` `@rust-lang/lang` #76001
|
|
|
|
Move `ast::Item::ident` into `ast::ItemKind`
The follow-up to #138384, which did the same thing for `hir::ItemKind`.
r? `@fmease`
|
