| Age | Commit message (Collapse) | Author | Lines |
|
Instead add a disambiguator to the keys used for distinguishing
resolutions.
|
|
Use a more traditional scheme with providing them as a resolver output
|
|
|
|
|
|
Remove implicit dependencies on syntax::pprust
Part of https://github.com/rust-lang/rust/pull/65324.
The main goal here is to facilitate the eventual move of pprust out from libsyntax and because an AST definition typically should not depend on its pretty printer.
r? @estebank
|
|
|
|
resolve: fix error title regarding private constructors
One reason is that constructors can be private while their types can be
public.
Idea credit to @petrochenkov, discussed at #65153
|
|
Instead just use `pprust::path_to_string(..)` where needed.
This has two benefits:
a) The AST definition is now independent of printing it.
(Therefore we get closer to extracting a data-crate.)
b) Debugging should be easier as program flow is clearer.
|
|
stability: Do not use `buffer_lint` after lowering to HIR
Fixes https://github.com/rust-lang/rust/issues/65253
|
|
|
|
The constructor is private, not the type.
Idea credit to @petrochenkov, discussed at #65153
|
|
Stabilize mem::take (mem_take)
Tracking issue: https://github.com/rust-lang/rust/issues/61129
r? @matklad
|
|
|
|
Improve message when attempting to instantiate tuple structs with private fields
Fixes #58017, fixes #39703.
```
error[E0603]: tuple struct `Error` is private
--> main.rs:22:16
|
2 | pub struct Error(usize, pub usize, usize);
| ----- ----- field is private
| |
| field is private
...
22 | let x = a::Error(3, 1, 2);
| ^^^^^
|
= note: a tuple struct constructor is private if any of its fields is private
```
|
|
resolve: Remove an incorrect assert
Fixes https://github.com/rust-lang/rust/issues/64803.
|
|
|
|
|
|
|
|
Tracking issue: https://github.com/rust-lang/rust/issues/61129
|
|
davidtwco:issue-65035-static-with-generic-in-foreign-mod, r=petrochenkov
typeck: prohibit foreign statics w/ generics
Fixes #65035 and fixes #65025.
This PR modifies resolve to disallow foreign statics that have
generics.
`improper_ctypes` is not written to support type parameters, as these
are normally disallowed before the lint is run. Thus, type parameters in
foreign statics must be prohibited before the lint.
The only other case where this *could* have occured is in functions,
but typeck prohibits this with a "foreign items may not have type
parameters" error - a similar error did not exist for statics, because
statics cannot have type parameters, but they can use any
type parameters that are in scope (which isn't the case for functions).
|
|
This commit modifies resolve to disallow foreign statics that use
parent generics.
`improper_ctypes` is not written to support type parameters, as these
are normally disallowed before the lint is run. Thus, type parameters in
foreign statics must be prohibited before the lint.
The only other case where this *could* have occured is in functions,
but typeck prohibits this with a "foreign items may not have type
parameters" error - a similar error did not exist for statics, because
statics cannot have type parameters, but they can use any
type parameters that are in scope (which isn't the case for functions).
Signed-off-by: David Wood <david@davidtw.co>
|
|
Make re-export collection deterministic
Fixes https://github.com/rust-lang/rust/issues/65036
Previously, we were using an `FxHashMap` to collect module re-exports.
However, re-exports end up getting serialized into crate metadata, which
means that metadata generation was non-deterministic. This resulted in
spurious error messages changes (e.g. PR #64906) due to pretty-printing
implicitly depending on the order of re-exports when computing the
proper path to show to the user.
See #65042 for a long-term strategy to detect this kind of issue
|
|
Stabilize `Option::as_deref` and `Option::as_deref_mut`
The tracking issue https://github.com/rust-lang/rust/issues/50264 still has unresolved question for the corresponding `Result` methods.
|
|
|
|
Now that `Resolutions` has a deterministic iteration order, it's no
longer necessary to sort its entries before iterating over them
|
|
Previously, we were using an `FxHashMap` to collect module re-exports.
However, re-exports end up getting serialized into crate metadata, which
means that metadata generation was non-deterministic. This resulted in
spurious error messages changes (e.g. PR #64906) due to pretty-printing
implicitly depending on the order of re-exports when computing the
proper path to show to the user.
See #65042 for a long-term strategy to detect this kind of issue
|
|
(Without this commit, you still get an error (a very similar one, at
that), but it complains about use of forward declaration, which is
confusing since people do not necessarily think of `Self` as being
declared at all.)
Update: incorporate review feedback.
|
|
Update: review feedback
Update: placate tidy
|
|
Point at definition when misusing ADT
When given `struct Foo(usize)` and using it as `Foo {}` or `Foo`, point at `Foo`'s definition in the error.
|
|
Add Long error explanation for E0531
Part of #61137.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
For both `ast::Expr` and `hir::Expr`.
|
|
|
|
Remove unused dependencies
|
|
The tracking issue https://github.com/rust-lang/rust/issues/50264
still has unresolved question for the corresponding `Result` methods.
|
|
|
|
When given `struct Foo(usize)` and using it as `Foo {}` or `Foo`, point at
`Foo`'s definition in the error.
|
|
|
|
unify errors for tuple/struct variants
fix #63983
|
|
fix #63983
|
|
remove the extra comma after the match arm
This would follow the same coding style as all the other match arms in this file.
|
|
This would follow the same coding style as all the other match arms in this file.
|
|
|