| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
[`let_with_type_underscore`]: Don't emit on locals from procedural macros
closes #10498
changelog: [`let_with_type_underscore`]: Don't emit on locals from procedural macros
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Remove `LangItems::require`
It's just a short wrapper used by `tcx.require_lang_item`. Deleting it gives us a negative diff.
|
|
It's just a short wrapper used by `tcx.require_lang_item`. Deleting it
gives us a negative diff.
|
|
|
|
|
|
|
|
|
|
Introduce `AliasKind::Inherent` for inherent associated types
Allows us to check (possibly generic) inherent associated types for well-formedness.
Type inference now also works properly.
Follow-up to #105961. Supersedes #108430.
Fixes #106722.
Fixes #108957.
Fixes #109768.
Fixes #109789.
Fixes #109790.
~Not to be merged before #108860 (`AliasKind::Weak`).~
CC `@jackh726`
r? `@compiler-errors`
`@rustbot` label T-types F-inherent_associated_types
|
|
skip_binder in mir subst methods
|
|
|
|
Update Clippy
r? `@Manishearth`
|
|
|
|
Implement RFC 3348, `c"foo"` literals
RFC: https://github.com/rust-lang/rfcs/pull/3348
Tracking issue: #105723
|
|
|
|
Replace `tcx.mk_trait_ref` with `TraitRef::new`
First step in implementing https://github.com/rust-lang/compiler-team/issues/616
r? `@lcnr`
|
|
Currently a `{D,Subd}iagnosticMessage` can be created from any type that
impls `Into<String>`. That includes `&str`, `String`, and `Cow<'static,
str>`, which are reasonable. It also includes `&String`, which is pretty
weird, and results in many places making unnecessary allocations for
patterns like this:
```
self.fatal(&format!(...))
```
This creates a string with `format!`, takes a reference, passes the
reference to `fatal`, which does an `into()`, which clones the
reference, doing a second allocation. Two allocations for a single
string, bleh.
This commit changes the `From` impls so that you can only create a
`{D,Subd}iagnosticMessage` from `&str`, `String`, or `Cow<'static,
str>`. This requires changing all the places that currently create one
from a `&String`. Most of these are of the `&format!(...)` form
described above; each one removes an unnecessary static `&`, plus an
allocation when executed. There are also a few places where the existing
use of `&String` was more reasonable; these now just use `clone()` at
the call site.
As well as making the code nicer and more efficient, this is a step
towards possibly using `Cow<'static, str>` in
`{D,Subd}iagnosticMessage::{Str,Eager}`. That would require changing
the `From<&'a str>` impls to `From<&'static str>`, which is doable, but
I'm not yet sure if it's worthwhile.
|
|
|
|
|
|
uplift `clippy::clone_double_ref` as `suspicious_double_ref_op`
Split from #109842.
r? ``@compiler-errors``
|
|
|
|
|
|
|
|
r=compiler-errors
Switch to `EarlyBinder` for `explicit_item_bounds`
Part of the work to finish https://github.com/rust-lang/rust/issues/105779.
This PR adds `EarlyBinder` to the return type of the `explicit_item_bounds` query and removes `bound_explicit_item_bounds`.
r? `@compiler-errors` (hope it's okay to request you, since you reviewed #110299 and #110498 :smiley:)
|
|
|
|
Update Clippy
r? `@Manishearth`
A few days late, I was on a business trip, sorry.
|
|
Run various queries from other queries instead of explicitly in phases
These are just legacy leftovers from when rustc didn't have a query system. While there are more cleanups of this sort that can be done here, I want to land them in smaller steps.
This phased order of query invocations was already a lie, as any query that looks at types (e.g. the wf checks run before) can invoke e.g. const eval which invokes borrowck, which invokes typeck, ...
|
|
|
|
Add offset_of! macro (RFC 3308)
Implements https://github.com/rust-lang/rfcs/pull/3308 (tracking issue #106655) by adding the built in macro `core::mem::offset_of`. Two of the future possibilities are also implemented:
* Nested field accesses (without array indexing)
* DST support (for `Sized` fields)
I wrote this a few months ago, before the RFC merged. Now that it's merged, I decided to rebase and finish it.
cc `@thomcc` (RFC author)
|
|
|
|
|
|
bound_explicit_item_bounds usages; remove bound_explicit_item_bounds query
|
|
|
|
|
|
This allows allocating `Expr`s into a dropless arena, which is useful
for using length prefixed thing slices in HIR, since these can only be
allocated in the dropless arena and not in a typed arena. This is
something I'm working on.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Initial support for return type notation (RTN)
See: https://smallcultfollowing.com/babysteps/blog/2023/02/13/return-type-notation-send-bounds-part-2/
1. Only supports `T: Trait<method(): Send>` style bounds, not `<T as Trait>::method(): Send`. Checking validity and injecting an implicit binder for all of the late-bound method generics is harder to do for the latter.
* I'd add this in a follow-up.
3. ~Doesn't support RTN in general type position, i.e. no `let x: <T as Trait>::method() = ...`~
* I don't think we actually want this.
5. Doesn't add syntax for "eliding" the function args -- i.e. for now, we write `method(): Send` instead of `method(..): Send`.
* May be a hazard if we try to add it in the future. I'll probably add it in a follow-up later, with a structured suggestion to change `method()` to `method(..)` once we add it.
7. ~I'm not in love with the feature gate name 😺~
* I renamed it to `return_type_notation` :heavy_check_mark:
Follow-up PRs will probably add support for `where T::method(): Send` bounds. I'm not sure if we ever want to support return-type-notation in arbitrary type positions. I may also make the bounds require `..` in the args list later.
r? `@ghost`
|
