Tracking issue: Required schema additions to make new lints possible
obi1kenobi opened this issue · comments
Predrag Gruevski commented
In approximate order of increasing difficulty:
-
expose auto-trait / unsafe trait info on
type Trait
- new lints enabled by this:
- trait became unsafe (so its
impl
blocks need to beunsafe impl
now) - unsafe trait became safe (
unsafe impl
cannot be used with safe traits)
- trait became unsafe (so its
- new lints enabled by this:
-
- even without type information, there are lints to be checked here
- remaining lints here:
- mutable static became immutable
-
expose associated type info on
type Trait
- even without type information, we can still write lints about this
- new lints enabled by this:
- associated type missing (renamed or deleted, will break
Trait::Assoc
uses)
- associated type missing (renamed or deleted, will break
-
- they are already available on
type StructVariant
- the edge on
type PlainVariant
should exist but never produce any vertices - the edge on
type TupleVariant
should produce fields similarly to how tuple structs produce their fields - new lints enabled by this:
- tuple variant field removed
- exhaustive tuple variant field added
- they are already available on
-
expose enum variant discriminant existence and values
- new lints enabled by this:
- variant discriminant removed
- variant discriminant changed value
- variant discriminant added (minor change, non-breaking)
- new lints enabled by this:
-
- things like
extern "C" fn
: https://docs.rs/rustdoc-types/latest/rustdoc_types/enum.Abi.html - new lints enabled by this:
- ABI kind changed, e.g.
extern "C" fn
toextern "system" fn
(or, ifextern
is removed, to the defaultextern "Rust" fn
) - ABI unwind ability removed, e.g.
extern "C-unwind" fn
toextern "C" fn
- ABI kind changed, e.g.
- open questions:
- is moving from
extern "C" fn
toextern "C-unwind" fn
a breaking change?
- is moving from
- things like
-
expose field ordering information
- probably via a separate edge to a new type, like
field_index: [FieldIndex]
where that new type contains the field index number and points to aStructField
- new lints enabled by this:
repr(C)
plain struct has its fields reordered
- probably via a separate edge to a new type, like
-
expose
union
types to the schema with all their subtleties: obi1kenobi/trustfall-rustdoc-adapter#36- this would be a new
type Union implements Item & Importable & ImplOwner
- new lints:
- union missing
- union became
doc(hidden)
- union field missing
- union field became
doc(hidden)
repr(C)
removed from union- lots more here: https://doc.rust-lang.org/cargo/reference/semver.html
- this would be a new
-
expose supertrait edge on
type Trait
which should probably point totype ImplementedTrait
- new lints enabled by this:
-
expose manifest information: dependencies, features, etc.
- new lints enabled by this:
- feature renamed or deleted
- feature removed from default features
- dependency major version updated when that dependency's types are part of the current crate's pub API
- new lints enabled by this:
-
expose type information (including generics, lifetimes, impl trait, trait bounds, etc.)
- this is quite hard, but would unlock a ton of new lints
- new lints enabled by this (partial list, surely there are more):
- plain struct field changes type
- tuple struct field changes type
- enum struct variant field changes type
- enum tuple variant field changes type
const
value changed typestatic
value changed type- function argument changes type to a different non-generic type
- non-generic because then it's definitely breaking
- if the type is generic then it's more complex to determine whether the change is breaking
- function return value changes type to a different non-generic type
- non-generic: same as above
- associated type in trait implementation changed type to a different non-generic type
- non-generic: same as above