| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Suggest importing for partial mod path matching in name resolving
Fixes #112590
|
|
|
|
|
|
Use structured suggestion when telling user about `for<'a>`
```
error[E0637]: `&` without an explicit lifetime name cannot be used here
--> $DIR/E0637.rs:13:13
|
LL | T: Into<&u32>,
| ^ explicit lifetime name needed here
|
help: consider introducing a higher-ranked lifetime here
|
LL | T: for<'a> Into<&'a u32>,
| +++++++ ++
```
|
|
```
error[E0637]: `&` without an explicit lifetime name cannot be used here
--> $DIR/E0637.rs:13:13
|
LL | T: Into<&u32>,
| ^ explicit lifetime name needed here
|
help: consider introducing a higher-ranked lifetime here
|
LL | T: for<'a> Into<&'a u32>,
| +++++++ ++
```
|
|
|
|
Simplify some conditions
r? `@Nilstrieb`
Some things taken out of my `is_none_or` pr.
|
|
|
|
r=fee1-dead
Rewrite most diagnostics as translatable within resolve/imports
|
|
Add translatable diagnostic for cannot be reexported error
also added for subdiagnostics
Add translatable diagnostics for resolve_glob_import errors
Add translatable diag for unable to determine import resolution
Add translatable diag for is not directly importable
|
|
|
|
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.
|
|
|
|
A single-use closure is inlined and one unnecessary enum is removed.
|
|
This reverts commit 3b059e0fdbf0257ac4921552781d070e8288233a, reversing
changes made to d70be670474c98e62eefc67674b7bb3c7c4f5053.
|
|
Rewrite various resolve/diagnostics errors as translatable diagnostics
additional question:
For trivial strings is it ever accepted to use `fluent_generated::foo` in a `label` for example? Or is an empty struct `Diagnostic` preferred?
|
|
|
|
|
|
|
|
resolve::unresolved_macro_suggestions
|
|
|
|
|
|
|
|
|
|
Don't drain-on-drop in DrainFilter impls of various collections.
This removes drain-on-drop behavior from various unstable DrainFilter impls (not yet for HashSet/Map) because that behavior [is problematic](https://github.com/rust-lang/rust/issues/43244#issuecomment-641638196) (because it can lead to panic-in-drop when user closures panic) and may become forbidden if [this draft RFC passes](https://github.com/rust-lang/rfcs/pull/3288).
closes #101122
[ACP](https://github.com/rust-lang/libs-team/issues/136)
affected tracking issues
* #43244
* #70530
* #59618
Related hashbrown update: https://github.com/rust-lang/hashbrown/pull/374
|
|
|
|
|
|
Make "consider importing" consistent for macros
Fixes #112439
|
|
increase the accuracy of effective visibilities calculation
Effective visibilities are calculated lazily due to performance restrictions. Therefore
- crate should be walked at least 1 time in `compute_effective_visibilities` pass
- Impl's should always be in the effective visibilities table
to ensure that the table is filled in correctly.
r? `@petrochenkov`
|
|
|
|
|
|
`#[cfg]`s are frequently used to gate crate content behind cargo
features. This can lead to very confusing errors when features are
missing. For example, `serde` doesn't have the `derive` feature by
default. Therefore, `serde::Serialize` fails to resolve with a generic
error, even though the macro is present in the docs.
This commit adds a list of all stripped item names to metadata. This is
filled during macro expansion and then, through a fed query, persisted
in metadata. The downstream resolver can then access the metadata to
look at possible candidates for mentioning in the errors.
This slightly increases metadata (800k->809k for the feature-heavy
windows crate), but not enough to really matter.
|
|
Each of `{D,Subd}iagnosticMessage::{Str,Eager}` has a comment:
```
// FIXME(davidtwco): can a `Cow<'static, str>` be used here?
```
This commit answers that question in the affirmative. It's not the most
compelling change ever, but it might be worth merging.
This requires changing the `impl<'a> From<&'a str>` impls to `impl
From<&'static str>`, which involves a bunch of knock-on changes that
require/result in call sites being a little more precise about exactly
what kind of string they use to create errors, and not just `&str`. This
will result in fewer unnecessary allocations, though this will not have
any notable perf effects given that these are error paths.
Note that I was lazy within Clippy, using `to_string` in a few places to
preserve the existing string imprecision. I could have used `impl
Into<{D,Subd}iagnosticMessage>` in various places as is done in the
compiler, but that would have required changes to *many* call sites
(mostly changing `&format("...")` to `format!("...")`) which didn't seem
worthwhile.
|
|
item
|
|
|
|
|
|
Prevent crash when a path is not resolved in intra-doc link
Fixes https://github.com/rust-lang/rust/issues/111189.
cc `@petrochenkov`
r? `@notriddle`
|
|
|
|
|
|
Better diagnostic for `use Self::..`
Fixes #111627
cc `@petrochenkov,` you might have thoughts on a better way to handle this (https://github.com/rust-lang/rust/issues/63720#issuecomment-591597466)
|
|
fix(resolve): replace bindings to dummy for unresolved imports
close #109343
In #109343, `f` in `pub use f as g` points to:
|namespace| binding|
|-|-|
|type| `external crate f`|
|value| `None` |
|macro| `None` |
When resolve `value_ns` during `resolve_doc_links`, the value of the binding of single_import `pub use f as g` goes to `pub use inner::f`, and since it does not satisfy [!self.is_accessible_from(binding.vis, single_import.parent_scope.module)](https://github.com/rust-lang/rust/blob/master/compiler/rustc_resolve/src/ident.rs#L971) and returns `Err(Undetermined)`, which eventually goes to `PathResult::Indeterminate => unreachable!`.
This PR replace all namespace binding to `dummy_binding` for indeterminate import, so, the bindings of `pub use f as g` had been changed to followings after finalize:
|namespace| binding|
|-|-|
|type| `dummy`|
|value| `dummy` |
|macro| `dummy` |
r?`@petrochenkov`
|
|
|
|
|
|
Revert "Validate resolution for SelfCtor too."
This reverts commit 83453408a0ce91b9e3d3ae6e7f117b1fd28b487d.
That PR introduced a breaking change.
Fixes https://github.com/rust-lang/rust/issues/111541
Reopens https://github.com/rust-lang/rust/issues/89868
r? `@petrochenkov`
|
|
|
|
refactor(resolve): clean up the early error return caused by non-call
closes https://github.com/rust-lang/rust/issues/109250
It seems no bad happened, r? ``@Nilstrieb``
|
|
|
|
This reverts commit 83453408a0ce91b9e3d3ae6e7f117b1fd28b487d.
|
|
Populate effective visibilities in `rustc_privacy` (take 2)
Same as https://github.com/rust-lang/rust/pull/110907 + regressions fixes.
Fixes https://github.com/rust-lang/rust/issues/111359.
r? `@petrochenkov`
|
