17 Commits

Author SHA1 Message Date
Nicholas Nethercote
6b62f37402 Restrict From<S> for {D,Subd}iagnosticMessage.
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.
2023-05-03 08:44:39 +10:00
Matthias Krüger
ac229c2819 fix clippy::iter_kv_map 2023-04-01 23:44:16 +02:00
Michael Goulet
8b592db27a Add (..) syntax for RTN 2023-03-28 01:14:28 +00:00
Ezra Shaw
a30c2c26c0
feat: implement better error for manual impl of Fn* traits 2023-03-10 20:32:24 +13:00
Nicholas Nethercote
2200911616 Rename many interner functions.
(This is a large commit. The changes to
`compiler/rustc_middle/src/ty/context.rs` are the most important ones.)

The current naming scheme is a mess, with a mix of `_intern_`, `intern_`
and `mk_` prefixes, with little consistency. In particular, in many
cases it's easy to use an iterator interner when a (preferable) slice
interner is available.

The guiding principles of the new naming system:
- No `_intern_` prefixes.
- The `intern_` prefix is for internal operations.
- The `mk_` prefix is for external operations.
- For cases where there is a slice interner and an iterator interner,
  the former is `mk_foo` and the latter is `mk_foo_from_iter`.

Also, `slice_interners!` and `direct_interners!` can now be `pub` or
non-`pub`, which helps enforce the internal/external operations
division.

It's not perfect, but I think it's a clear improvement.

The following lists show everything that was renamed.

slice_interners
- const_list
  - mk_const_list -> mk_const_list_from_iter
  - intern_const_list -> mk_const_list
- substs
  - mk_substs -> mk_substs_from_iter
  - intern_substs -> mk_substs
  - check_substs -> check_and_mk_substs (this is a weird one)
- canonical_var_infos
  - intern_canonical_var_infos -> mk_canonical_var_infos
- poly_existential_predicates
  - mk_poly_existential_predicates -> mk_poly_existential_predicates_from_iter
  - intern_poly_existential_predicates -> mk_poly_existential_predicates
  - _intern_poly_existential_predicates -> intern_poly_existential_predicates
- predicates
  - mk_predicates -> mk_predicates_from_iter
  - intern_predicates -> mk_predicates
  - _intern_predicates -> intern_predicates
- projs
  - intern_projs -> mk_projs
- place_elems
  - mk_place_elems -> mk_place_elems_from_iter
  - intern_place_elems -> mk_place_elems
- bound_variable_kinds
  - mk_bound_variable_kinds -> mk_bound_variable_kinds_from_iter
  - intern_bound_variable_kinds -> mk_bound_variable_kinds

direct_interners
- region
  - intern_region (unchanged)
- const
  - mk_const_internal -> intern_const
- const_allocation
  - intern_const_alloc -> mk_const_alloc
- layout
  - intern_layout -> mk_layout
- adt_def
  - intern_adt_def -> mk_adt_def_from_data (unusual case, hard to avoid)
  - alloc_adt_def(!) -> mk_adt_def
- external_constraints
  - intern_external_constraints -> mk_external_constraints

Other
- type_list
  - mk_type_list -> mk_type_list_from_iter
  - intern_type_list -> mk_type_list
- tup
  - mk_tup -> mk_tup_from_iter
  - intern_tup -> mk_tup
2023-02-24 07:32:24 +11:00
Michael Howell
3d056c3125 diagnostics: if AssocFn has self argument, describe as method
Discussed in
https://rust-lang.zulipchat.com/#narrow/stream/147480-t-compiler.2Fwg-diagnostics/topic/.22associated.20function.22.20vs.20.22method.22/near/329265515

This commit also changes the tooltips on rustdoc intra-doc links
targeting methods.
2023-02-22 08:40:33 -07:00
Matthias Krüger
226ce31edd
Rollup merge of #108200 - jhpratt:restricted-damerau-levenshtein-distance, r=tmiasko
Use restricted Damerau-Levenshtein distance for diagnostics

This replaces the existing Levenshtein algorithm with the Damerau-Levenshtein algorithm. This means that "ab" to "ba" is one change (a transposition) instead of two (a deletion and insertion). More specifically, this is a _restricted_ implementation, in that "ca" to "abc" cannot be performed as "ca" → "ac" → "abc", as there is an insertion in the middle of a transposition. I believe that errors like that are sufficiently rare that it's not worth taking into account.

This was first brought up [on IRLO](https://internals.rust-lang.org/t/18227) when it was noticed that the diagnostic for `prinltn!` (transposed L and T) was `print!` and not `println!`. Only a single existing UI test was effected, with the result being an objective improvement.

~~I have left the method name and various other references to the Levenshtein algorithm untouched, as the exact manner in which the edit distance is calculated should not be relevant to the caller.~~

r? ``@estebank``

``@rustbot`` label +A-diagnostics +C-enhancement
2023-02-20 14:32:55 +01:00
León Orell Valerian Liehr
f2253dad24
Add some FIXMEs for follow-up PRs 2023-02-19 22:54:47 +01:00
León Orell Valerian Liehr
77ea90ec71
Fix substitution bug 2023-02-19 18:35:35 +01:00
León Orell Valerian Liehr
b5e73bfe90
Groundwork for detecting ambiguous candidates
NB: Since we are using the same InferCtxt in each iteration,
we essentially *spoil* the inference variables and we only
ever get at most *one* applicable candidate (only the 1st candidate
has clean variables that can still unify correctly).
2023-02-19 18:35:35 +01:00
León Orell Valerian Liehr
cc65ebd0d2
Make use of ObligationCtxt 2023-02-19 18:35:34 +01:00
León Orell Valerian Liehr
488d0c9efd
Type-directed probing for inherent associated types 2023-02-19 18:35:28 +01:00
Jacob Pratt
378c4ab9ab
Make public API, docs algorithm-agnostic 2023-02-19 04:11:10 +00:00
Maybe Waffle
6a28fb42a8 Remove double spaces after dots in comments 2023-01-17 08:09:33 +00:00
Albert Larsan
40ba0e84d5
Change src/test to tests in source files, fix tidy and tests 2023-01-11 09:32:13 +00:00
Oli Scherer
ecea616052 Simplify astconv item def id handling 2022-11-02 12:03:59 +00:00
lcnr
1fc86a63f4 rustc_typeck to rustc_hir_analysis 2022-09-27 10:37:23 +02:00