Commit Graph

600 Commits

Author SHA1 Message Date
surechen
4ebbb5f048 Fix incorrect suggestion for undeclared hrtb lifetimes in where clauses.
fixes #122714
2024-05-20 20:28:57 +08:00
bors
36c0a6d40f Auto merge of #125105 - nnethercote:rustc_resolve-cleanups, r=estebank
`rustc_resolve` cleanups

Some improvements I found while looking through this code.

r? `@estebank`
2024-05-18 06:36:44 +00:00
Vadim Petrochenkov
c30b41012d delegation: Implement list delegation
```rust
reuse prefix::{a, b, c}
```
2024-05-15 02:32:59 +03:00
Nicholas Nethercote
d1f5beeed5 Remove #[macro_use] extern crate tracing from rustc_resolve.
Explicit imports are more standard nowadays and easier to read.
2024-05-10 15:34:41 +10:00
Vadim Petrochenkov
7b7c26f09b delegation: Support async, const, extern "ABI" and C-variadic functions
Also allow `impl Trait` in delegated functions.
The delegation item will refer to the original opaque type from the callee, fresh opaque type won't be created.
2024-04-23 23:05:39 +03:00
Michael Goulet
a076eae0d2 Parsing , pre-lowering support for precise captures 2024-04-15 16:45:01 -04:00
Michael Goulet
a4db3ffdcb Don't suggest deref macro since it's unstable 2024-03-21 11:42:49 -04:00
Shoyu Vanilla
c270a42fea Fix bad span for explicit lifetime suggestion
Move verbose logic to a function

Minor renaming
2024-03-21 10:31:04 +09:00
Nicholas Nethercote
5cce28725f Rename DiagnosticMetadata as DiagMetadata. 2024-03-05 12:15:13 +11:00
Nicholas Nethercote
7aa0eea19c Rename BuiltinLintDiagnostics as BuiltinLintDiag.
Not the dropping of the trailing `s` -- this type describes a single
diagnostic and its name should be singular.
2024-03-05 12:15:10 +11:00
Matthias Krüger
7a48987006 avoid collecting into vecs in some places 2024-03-02 14:18:47 +01:00
Nicholas Nethercote
899cb40809 Rename DiagnosticBuilder as Diag.
Much better!

Note that this involves renaming (and updating the value of)
`DIAGNOSTIC_BUILDER` in clippy.
2024-02-28 08:55:35 +11:00
Matthias Krüger
86a7fc840f compiler: clippy::complexity fixes 2024-02-23 19:56:35 +01:00
Nicholas Nethercote
b18f3e11fa Prefer DiagnosticBuilder over Diagnostic in diagnostic modifiers.
There are lots of functions that modify a diagnostic. This can be via a
`&mut Diagnostic` or a `&mut DiagnosticBuilder`, because the latter type
wraps the former and impls `DerefMut`.

This commit converts all the `&mut Diagnostic` occurrences to `&mut
DiagnosticBuilder`. This is a step towards greatly simplifying
`Diagnostic`. Some of the relevant function are made generic, because
they deal with both errors and warnings. No function bodies are changed,
because all the modifier methods are available on both `Diagnostic` and
`DiagnosticBuilder`.
2024-02-19 20:23:20 +11:00
Matthias Krüger
45d5773704
Rollup merge of #121085 - davidtwco:always-eager-diagnostics, r=nnethercote
errors: only eagerly translate subdiagnostics

Subdiagnostics don't need to be lazily translated, they can always be eagerly translated. Eager translation is slightly more complex as we need to have a `DiagCtxt` available to perform the translation, which involves slightly more threading of that context.

This slight increase in complexity should enable later simplifications - like passing `DiagCtxt` into `AddToDiagnostic` and moving Fluent messages into the diagnostic structs rather than having them in separate files (working on that was what led to this change).

r? ```@nnethercote```
2024-02-17 18:47:40 +01:00
David Wood
b80fc5d4e8
errors: only eagerly translate subdiagnostics
Subdiagnostics don't need to be lazily translated, they can always be
eagerly translated. Eager translation is slightly more complex as we need
to have a `DiagCtxt` available to perform the translation, which involves
slightly more threading of that context.

This slight increase in complexity should enable later simplifications -
like passing `DiagCtxt` into `AddToDiagnostic` and moving Fluent messages
into the diagnostic structs rather than having them in separate files
(working on that was what led to this change).

Signed-off-by: David Wood <david@davidtw.co>
2024-02-15 10:34:41 +00:00
yukang
2a229c96e8 remove importing suggestions when there is a shadowed typo canddiate 2024-02-14 14:08:51 +08:00
León Orell Valerian Liehr
285d8c225d
Suggest [tail @ ..] on [..tail] and [...tail] where tail is unresolved 2024-02-04 22:16:21 +01:00
Matthias Krüger
968cff7cf3
Rollup merge of #120592 - trevyn:cleanup-to-string, r=Nilstrieb
Remove unnecessary `.to_string()`/`.as_str()`s
2024-02-03 21:29:43 +01:00
trevyn
ef37dcb7db Remove unnecessary .to_string()/.as_str()s 2024-02-02 15:16:05 -08:00
León Orell Valerian Liehr
5906237b32
Suggest changing ty to const params if appropriate 2024-02-02 03:25:04 +01:00
León Orell Valerian Liehr
3f7b1a5f49
Clean up some things in the name resolver
* Get rid of a typo in a function name
* Rename `currently_processing_generics`: The old name confused me at first since
  I assumed it referred to generic *parameters* when it was in fact referring to
  generic *arguments*. Generics are typically short for generic params.
* Get rid of a few unwraps by properly leveraging slice patterns
2024-02-02 02:51:48 +01:00
Nicholas Nethercote
5d9dfbd08f Stop using String for error codes.
Error codes are integers, but `String` is used everywhere to represent
them. Gross!

This commit introduces `ErrCode`, an integral newtype for error codes,
replacing `String`. It also introduces a constant for every error code,
e.g. `E0123`, and removes the `error_code!` macro. The constants are
imported wherever used with `use rustc_errors::codes::*`.

With the old code, we have three different ways to specify an error code
at a use point:
```
error_code!(E0123)  // macro call

struct_span_code_err!(dcx, span, E0123, "msg");  // bare ident arg to macro call

\#[diag(name, code = "E0123")]  // string
struct Diag;
```

With the new code, they all use the `E0123` constant.
```
E0123  // constant

struct_span_code_err!(dcx, span, E0123, "msg");  // constant

\#[diag(name, code = E0123)]  // constant
struct Diag;
```

The commit also changes the structure of the error code definitions:
- `rustc_error_codes` now just defines a higher-order macro listing the
  used error codes and nothing else.
- Because that's now the only thing in the `rustc_error_codes` crate, I
  moved it into the `lib.rs` file and removed the `error_codes.rs` file.
- `rustc_errors` uses that macro to define everything, e.g. the error
  code constants and the `DIAGNOSTIC_TABLES`. This is in its new
  `codes.rs` file.
2024-01-29 07:41:41 +11:00
trevyn
de2575f35d Don't delete any lifetimes with bounds 2024-01-20 02:30:58 +04:00
Oli Scherer
557b111870 Make crate_inherent_impls fallible and stop using track_errors for it 2024-01-17 10:02:29 +00:00
Bryanskiy
d69cd6473c Delegation implementation: step 1 2024-01-12 14:11:16 +03:00
Nicholas Nethercote
ed76b0b882 Rename consuming chaining methods on DiagnosticBuilder.
In #119606 I added them and used a `_mv` suffix, but that wasn't great.

A `with_` prefix has three different existing uses.
- Constructors, e.g. `Vec::with_capacity`.
- Wrappers that provide an environment to execute some code, e.g.
  `with_session_globals`.
- Consuming chaining methods, e.g. `Span::with_{lo,hi,ctxt}`.

The third case is exactly what we want, so this commit changes
`DiagnosticBuilder::foo_mv` to `DiagnosticBuilder::with_foo`.

Thanks to @compiler-errors for the suggestion.
2024-01-10 07:40:00 +11:00
Nicholas Nethercote
4864cb8aef Rename struct_span_err! as struct_span_code_err!.
Because it takes an error code after the span. This avoids the confusing
overlap with the `DiagCtxt::struct_span_err` method, which doesn't take
an error code.
2024-01-10 07:33:04 +11:00
Nicholas Nethercote
6682f243dc Remove all eight DiagnosticBuilder::*_with_code methods.
These all have relatively low use, and can be perfectly emulated with
a simpler construction method combined with `code` or `code_mv`.
2024-01-08 16:00:34 +11:00
Nicholas Nethercote
bd4e623485 Use chaining for DiagnosticBuilder construction and emit.
To avoid the use of a mutable local variable, and because it reads more
nicely.
2024-01-08 15:45:29 +11:00
Nicholas Nethercote
589591efde Use chaining in DiagnosticBuilder construction.
To avoid the use of a mutable local variable, and because it reads more
nicely.
2024-01-08 15:43:07 +11:00
Michael Goulet
61c776ae0a
Rollup merge of #119638 - lukas-code:suggest-constructor-cycle-error, r=cjgillot
fix cyle error when suggesting to use associated function instead of constructor

Fixes https://github.com/rust-lang/rust/issues/119625.

The first commit fixes the infinite recursion and makes the cycle error actually show up. We do this by making the `Display` for `ty::Instance` impl  respect `with_no_queries` so that it can be used in query descriptions.

The second commit fixes the cycle error `resolver_for_lowering` -> `normalize` -> `resolve_instance` (for evaluating const) -> `lang_items` (for `drop_in_place`) -> `resolver_for_lowering` (for collecting lang items). We do this by simply skipping the suggestion when encountering an unnormalized type.
2024-01-05 23:41:43 -05:00
Lukas Markeffsky
339fa311ad fix cycle error for "use constructor" suggestion 2024-01-05 21:56:32 +01:00
Matthias Krüger
3a0536ab51
Rollup merge of #119151 - Jules-Bertholet:no-foreign-doc-hidden-suggest, r=davidtwco
Hide foreign `#[doc(hidden)]` paths in import suggestions

Stops the compiler from suggesting to import foreign `#[doc(hidden)]` paths.

```@rustbot``` label A-suggestion-diagnostics
2024-01-05 20:39:50 +01:00
Nicholas Nethercote
505c1371d0 Rename some Diagnostic setters.
`Diagnostic` has 40 methods that return `&mut Self` and could be
considered setters. Four of them have a `set_` prefix. This doesn't seem
necessary for a type that implements the builder pattern. This commit
removes the `set_` prefixes on those four methods.
2024-01-03 19:40:20 +11:00
Nicholas Nethercote
99472c7049 Remove Session methods that duplicate DiagCtxt methods.
Also add some `dcx` methods to types that wrap `TyCtxt`, for easier
access.
2023-12-24 08:05:28 +11:00
Nicholas Nethercote
757d6f6ef8 Give DiagnosticBuilder a default type.
`IntoDiagnostic` defaults to `ErrorGuaranteed`, because errors are the
most common diagnostic level. It makes sense to do likewise for the
closely-related (and much more widely used) `DiagnosticBuilder` type,
letting us write `DiagnosticBuilder<'a, ErrorGuaranteed>` as just
`DiagnosticBuilder<'a>`. This cuts over 200 lines of code due to many
multi-line things becoming single line things.
2023-12-23 13:23:10 +11:00
bors
208dd2032b Auto merge of #118847 - eholk:for-await, r=compiler-errors
Add support for `for await` loops

This adds support for `for await` loops. This includes parsing, desugaring in AST->HIR lowering, and adding some support functions to the library.

Given a loop like:
```rust
for await i in iter {
    ...
}
```
this is desugared to something like:
```rust
let mut iter = iter.into_async_iter();
while let Some(i) = loop {
    match core::pin::Pin::new(&mut iter).poll_next(cx) {
        Poll::Ready(i) => break i,
        Poll::Pending => yield,
    }
} {
    ...
}
```

This PR also adds a basic `IntoAsyncIterator` trait. This is partly for symmetry with the way `Iterator` and `IntoIterator` work. The other reason is that for async iterators it's helpful to have a place apart from the data structure being iterated over to store state. `IntoAsyncIterator` gives us a good place to do this.

I've gated this feature behind `async_for_loop` and opened #118898 as the feature tracking issue.

r? `@compiler-errors`
2023-12-22 14:17:10 +00:00
León Orell Valerian Liehr
5e4f12b41a
Refactor AST trait bound modifiers 2023-12-20 19:39:46 +01:00
Jules Bertholet
5c0e62cd3e
Hide foreign #[doc(hidden)] paths in import suggestions 2023-12-20 00:19:45 -05:00
Eric Holk
27d6539a46
Plumb awaitness of for loops 2023-12-19 12:26:20 -08:00
Jubilee
4583a0134f
Rollup merge of #118889 - matthiaskrgr:compl_2023_2, r=WaffleLapkin
more clippy::complexity fixes

      redundant_guards
      redundant_slicing
      filter_next
      needless_borrowed_reference
      useless_format
2023-12-12 18:48:54 -08:00
Jubilee
89d4a9bee9
Rollup merge of #118884 - matthiaskrgr:auszweimacheins, r=Nadrieril
NFC: simplify merging of two vecs
2023-12-12 18:48:52 -08:00
Matthias Krüger
3795cc8eb0 more clippy::complexity fixes
redundant_guards
      redundant_slicing
      filter_next
      needless_borrowed_reference
      useless_format
2023-12-12 20:41:51 +01:00
Matthias Krüger
6892fcd690 simplify merging of two vecs 2023-12-12 18:42:37 +01:00
Matthias Krüger
ffdb471872
Rollup merge of #117914 - estebank:issue-85843, r=wesleywiser
On borrow return type, suggest borrowing from arg or owned return type

When we encounter a function with a return type that has an anonymous lifetime with no argument to borrow from, besides suggesting the `'static` lifetime we now also suggest changing the arguments to be borrows or changing the return type to be an owned type.

```
error[E0106]: missing lifetime specifier
  --> $DIR/variadic-ffi-6.rs:7:6
   |
LL | ) -> &usize {
   |      ^ expected named lifetime parameter
   |
   = help: this function's return type contains a borrowed value, but there is no value for it to be borrowed from
help: consider using the `'static` lifetime, but this is uncommon unless you're returning a borrowed value from a `const` or a `static`
   |
LL | ) -> &'static usize {
   |       +++++++
help: instead, you are more likely to want to change one of the arguments to be borrowed...
   |
LL |     x: &usize,
   |        +
help: ...or alternatively, to want to return an owned value
   |
LL - ) -> &usize {
LL + ) -> usize {
   |
```

Fix #85843.
2023-12-12 17:40:53 +01:00
Michael Goulet
8490b8ec63 Dont suggest ! for path in function call if it has generic args 2023-11-27 01:02:37 +00:00
Michael Goulet
079a2e865f is_{some,ok}_and 2023-11-25 18:47:16 +00:00
bors
4fd68eb47b Auto merge of #117934 - Young-Flash:dev, r=petrochenkov
feat: make `let_binding_suggestion` more reasonable

This is my first PR for rustc, which trying to fix https://github.com/rust-lang/rust/issues/117894, I am not familiar with some internal api so maybe some modification here isn't the way to go, appreciated for any review suggestion.
2023-11-24 15:26:04 +00:00
Young-Flash
c710db8ea7 feat: make let_binding_suggestion more reasonable 2023-11-23 20:22:17 +08:00
Nilstrieb
21a870515b Fix clippy::needless_borrow in the compiler
`x clippy compiler -Aclippy::all -Wclippy::needless_borrow --fix`.

Then I had to remove a few unnecessary parens and muts that were exposed
now.
2023-11-21 20:13:40 +01:00
Esteban Küber
eee4cc6616 let-chain fmt 2023-11-20 23:44:37 +00:00
Esteban Küber
02bea16c08 Rely in resolve and not on path name for &str -> String suggestion 2023-11-20 23:44:37 +00:00
Esteban Küber
bb9d720a16 Do not consider traits as ownable in suggestion 2023-11-20 23:44:37 +00:00
Esteban Küber
85f26ade8d Account for '_ in lifetime suggestion 2023-11-20 23:44:37 +00:00
Esteban Küber
2a92d820c7 Suggest 'a when trait object assoc type has '_ 2023-11-20 23:44:37 +00:00
Esteban Küber
dec7f00e15 Fix incorrect lifetime suggestion 2023-11-20 23:44:37 +00:00
Esteban Küber
d30252e359 Tweak wording 2023-11-20 23:44:37 +00:00
Esteban Küber
5fce361d58 Account for impl Trait in lifetime suggestion
When encountering
```rust
fn g(mut x: impl Iterator<Item = &()>) -> Option<&()> { /* */ }
```
Suggest
```rust
fn g<'a>(mut x: impl Iterator<Item = &'a ()>) -> Option<&'a ()> { /* */ }
```
2023-11-20 23:44:37 +00:00
Esteban Küber
b7a23bc08b On borrow return type, suggest borrowing from arg or owned return type
When we encounter a function with a return type that has an anonymous
lifetime with no argument to borrow from, besides suggesting the
`'static` lifetime we now also suggest changing the arguments to be
borrows or changing the return type to be an owned type.

```
error[E0106]: missing lifetime specifier
  --> $DIR/variadic-ffi-6.rs:7:6
   |
LL | ) -> &usize {
   |      ^ expected named lifetime parameter
   |
   = help: this function's return type contains a borrowed value, but there is no value for it to be borrowed from
help: consider using the `'static` lifetime, but this is uncommon unless you're returning a borrowed value from a `const` or a `static`
   |
LL | ) -> &'static usize {
   |       +++++++
help: instead, you are more likely to want to change one of the arguments to be borrowed...
   |
LL |     x: &usize,
   |        +
help: ...or alternatively, to want to return an owned value
   |
LL - ) -> &usize {
LL + ) -> usize {
   |
```

Fix #85843.
2023-11-20 23:44:36 +00:00
Esteban Küber
ac56b06b44 fix rebase 2023-11-19 18:07:22 +00:00
Esteban Küber
a519c9b6b7 review comments 2023-11-19 17:50:47 +00:00
Esteban Küber
4d16171f56 Account for number of arguments in suggestion 2023-11-19 17:50:47 +00:00
Esteban Küber
00265f0cc0 fix tidy 2023-11-19 17:50:47 +00:00
Esteban Küber
987155f35d Suggest using builder on curly brace struct called as fn 2023-11-19 17:50:46 +00:00
Esteban Küber
12a8bb8d9b Do not suggest struct literal when fields are private 2023-11-19 17:50:46 +00:00
Esteban Küber
a4f47de7ff On private tuple struct, suggest Default::default when possible 2023-11-19 17:50:46 +00:00
Esteban Küber
f1ae02f4bd Don't sort span_suggestions, leave that to caller 2023-11-19 17:50:45 +00:00
Esteban Küber
42aa1273b0 When encountering struct fn call literal with private fields, suggest all builders
When encountering code like `Box(42)`, suggest `Box::new(42)` and *all*
other associated functions that return `-> Box<T>`.
2023-11-19 17:47:41 +00:00
Esteban Küber
5c3e01a340 On resolve error of [rest..], suggest [rest @ ..]
When writing a pattern to collect multiple entries of a slice in a
single binding, it is easy to misremember or typo the appropriate syntax
to do so, instead writing the experimental `X..` pattern syntax. When we
encounter a resolve error because `X` isn't available, we suggest
`X @ ..` as an alternative.

```
error[E0425]: cannot find value `rest` in this scope
  --> $DIR/range-pattern-meant-to-be-slice-rest-pattern.rs:3:13
   |
LL |         [1, rest..] => println!("{rest:?}"),
   |             ^^^^ not found in this scope
   |
help: if you meant to collect the rest of the slice in `rest`, use the at operator
   |
LL |         [1, rest @ ..] => println!("{rest:?}"),
   |                  +
```

Fix #88404.
2023-11-17 00:55:55 +00:00
Esteban Küber
87dc85d322 Suggest assoc fn new when trying to build tuple struct with private fields
Fix #22488.
2023-10-26 22:21:05 +00:00
Michael Goulet
b2d2184ede Format all the let chains in compiler 2023-10-13 08:59:36 +00:00
bors
c1f86f0bc8 Auto merge of #116089 - estebank:issue-115992-2, r=compiler-errors
When suggesting `self.x` for `S { x }`, use `S { x: self.x }`

Fix #115992.

r? `@compiler-errors`

Follow up to #116086.
2023-09-29 05:45:18 +00:00
Matthias Krüger
fd95627134 fix clippy::{redundant_guards, useless_format} 2023-09-27 23:49:15 +02:00
Michael Goulet
d6ce9ce115 Don't store lazyness in DefKind 2023-09-26 02:53:59 +00:00
Esteban Küber
d00c7e78ea Point at field definition when unresolved name exists in Self 2023-09-25 15:56:36 +00:00
Esteban Küber
81bca5f5cf When suggesting self.x for S { x }, use S { x: self.x }
Tweak output.

Fix #115992.
2023-09-25 15:56:36 +00:00
Esteban Küber
ac5e18756a Tweak wording and logic 2023-09-23 01:54:05 +00:00
Esteban Küber
0e98682576 When encountering method on Self that we can't suggest, mention it 2023-09-23 01:47:06 +00:00
Esteban Küber
c4a4926083 More accurate suggestion for self. and Self::
Fix #115992.
2023-09-23 01:34:50 +00:00
bohan
078b942fef fix: not insert missing lifetime for ConstParamTy 2023-08-08 14:48:17 +08:00
Matthias Krüger
3cd0a109a8
Rollup merge of #114566 - fmease:type-alias-laziness-is-crate-specific, r=oli-obk
Store the laziness of type aliases in their `DefKind`

Previously, we would treat paths referring to type aliases as *lazy* type aliases if the current crate had lazy type aliases enabled independently of whether the crate which the alias was defined in had the feature enabled or not.

With this PR, the laziness of a type alias depends on the crate it is defined in. This generally makes more sense to me especially if / once lazy type aliases become the default in a new edition and we need to think about *edition interoperability*:

Consider the hypothetical case where the dependency crate has an older edition (and thus eager type aliases), it exports a type alias with bounds & a where-clause (which are void but technically valid), the dependent crate has the latest edition (and thus lazy type aliases) and it uses that type alias. Arguably, the bounds should *not* be checked since at any time, the dependency crate should be allowed to change the bounds at will with a *non*-major version bump & without negatively affecting downstream crates.

As for the reverse case (dependency: lazy type aliases, dependent: eager type aliases), I guess it rules out anything from slight confusion to mild annoyance from upstream crate authors that would be caused by the compiler ignoring the bounds of their type aliases in downstream crates with older editions.

---

This fixes #114468 since before, my assumption that the type alias associated with a given weak projection was lazy (and therefore had its variances computed) did not necessarily hold in cross-crate scenarios (which [I kinda had a hunch about](https://github.com/rust-lang/rust/pull/114253#discussion_r1278608099)) as outlined above. Now it does hold.

`@rustbot` label F-lazy_type_alias
r? `@oli-obk`
2023-08-08 03:30:56 +02:00
León Orell Valerian Liehr
5468336d6b
Store the laziness of type aliases in the DefKind 2023-08-07 15:54:31 +02:00
yukang
eb0fcc5ad1 refactor on span_look_ahead 2023-08-06 22:44:11 +08:00
yukang
026c4b6a65 trivial style fix 2023-08-02 09:56:02 +08:00
Matthias Krüger
3ce90b1649 inline format!() args up to and including rustc_codegen_llvm 2023-07-30 14:22:50 +02:00
León Orell Valerian Liehr
da17134be0
Resolve generic const items 2023-07-28 22:21:41 +02:00
Mark Rousskov
cc907f80b9 Re-format let-else per rustfmt update 2023-07-12 21:49:27 -04:00
Matthias Krüger
70c637808f
Rollup merge of #113331 - chenyukang:yukang-fix-112590-false-positive, r=estebank
Add filter with following segment while lookup typo for path

From the discussion: https://github.com/rust-lang/rust/pull/112917#discussion_r1239150173

Seems we can not get the assoc items for `Struct`, `Enum` in the resolving phase.
A obvious filter is avoid suggesting the same name with the following segment path.

Use `following_seg` can extend the function `smart_resolve_partial_mod_path_errors` for more scenarios, such as `std::sync_error::atomic::AtomicBool` in test case.

r? `@estebank`
2023-07-10 12:01:32 +02:00
yukang
37b40e592a adjust smart_resolve_partial_mod_path_errors 2023-07-07 10:19:30 +08:00
yukang
9763472e2b smart_resolve_partial_mod_path_errors should not suggest parent 2023-07-07 10:18:20 +08:00
yukang
6f53e61887 Add filter with next segment while lookup typo for path 2023-07-07 09:00:50 +08:00
Vadim Petrochenkov
c1f412f9a9 resolve: Use Interned for Module 2023-07-05 13:47:36 +03:00
bors
e728b5b98d Auto merge of #112917 - chenyukang:yukang-fix-112590, r=estebank
Suggest importing for partial mod path matching in name resolving

Fixes #112590
2023-07-04 02:01:24 +00:00
yukang
b26701ea79 add testcase for 112590 2023-07-02 15:35:18 +08:00
Matthias Krüger
d505582ce2
Rollup merge of #113084 - WaffleLapkin:less_map_or, r=Nilstrieb
Simplify some conditions

r? `@Nilstrieb`

Some things taken out of my `is_none_or` pr.
2023-06-27 22:10:15 +02:00
Maybe Waffle
ef05533c39 Simplify some conditions 2023-06-27 07:40:47 +00:00
Esteban Küber
7dffd24da5 Tweak privacy errors to account for reachable items
Suggest publicly accessible paths for items in private mod:

  When encountering a path in non-import situations that are not reachable
  due to privacy constraints, search for any public re-exports that the
  user could use instead.

Track whether an import suggestion is offering a re-export.

When encountering a path with private segments, mention if the item at
the final path segment is not publicly accessible at all.

Add item visibility metadata to privacy errors from imports:

  On unreachable imports, record the item that was being imported in order
  to suggest publicly available re-exports or to be explicit that the item
  is not available publicly from any path.

  In order to allow this, we add a mode to `resolve_path` that will not
  add new privacy errors, nor return early if it encounters one. This way
  we can get the `Res` corresponding to the final item in the import,
  which is used in the privacy error machinery.
2023-06-22 16:50:31 +00:00
yukang
e7e1a39fa0 suggest importing for partial mod path in name resolving 2023-06-22 11:18:48 +08:00
许杰友 Jieyou Xu (Joe)
32ae8810fc
Fix suggestion for E0404 not dealing with multiple generics 2023-06-15 18:19:09 +08:00