A path type argument could be a generic const argument due to
limitations as to what we can determine at parsing. We double check just
to be sure by trying to resolve in the type namespace first, and if that
fails we try again in the value namespace. If resolution in the value
namespace succeeds, we have a generic const argument on our hands.
Push `ast::{ItemKind, ImplItemKind}::OpaqueTy` hack down into lowering
We currently have a hack in the form of `ast::{ItemKind, ImplItemKind}::OpaqueTy` which is constructed literally when you write `type Alias = impl Trait;` but not e.g. `type Alias = Vec<impl Trait>;`. Per https://github.com/rust-lang/rfcs/pull/2515, this needs to change to allow `impl Trait` in nested positions. This PR achieves this change for the syntactic aspect but not the semantic one, which will require changes in lowering and def collection. In the interim, `TyKind::opaque_top_hack` is introduced to avoid knock-on changes in lowering, collection, and resolve. These hacks can then be removed and fixed one by one until the desired semantics are supported.
r? @varkor
`MethodSig` -> `FnSig` & Use it in `ItemKind::Fn`
In both AST & HIR, rename `MethodSig` to `FnSig` and then proceed to use it in `ItemKind::Fn` so that the overall structure is more regular.
r? @davidtwco
Rename `LocalInternedString` and more
This PR renames `LocalInternedString` as `SymbolStr`, removes an unnecessary `impl` from it, improves comments, and cleans up some `SymbolStr` uses.
r? @estebank
Point at the span for the definition of ADTs internal to the current
crate.
Look at the leading char of the ident to determine whether we're
expecting a likely fn or any of a fn, a tuple struct or a tuple variant.
Turn fn `add_typo_suggestion` into a `Resolver` method.
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>
