Tracking issue: Required schema additions to make new lints possible

[obi1kenobi]

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 be unsafe impl now)
    • unsafe trait became safe (unsafe impl cannot be used with safe traits)

• New schema and lints for const and static values #366

  • 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)

• Expose enum variant fields on interface Variant #253

  • 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

• expose enum variant discriminant existence and values: Add enum discriminants trustfall-rustdoc-adapter#337

  • new lints enabled by this:
    • variant discriminant removed
    • variant discriminant changed value
    • variant discriminant added (minor change, non-breaking)

• Lints related to function ABI changes #260

  • 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 to extern "system" fn (or, if extern is removed, to the default extern "Rust" fn)
    • ABI unwind ability removed, e.g. extern "C-unwind" fn to extern "C" fn
  • open questions:
    • is moving from extern "C" fn to extern "C-unwind" fn a breaking change?

• expose field ordering information within structs and enums' tuple/struct variants

  • 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 a StructField
  • new lints enabled by this:
    • repr(C) plain struct has its fields reordered
    • repr(C) enum tuple/struct variant has its fields reordered

• expose union types to the schema with all their subtleties: Implement the Union type, making union types queriable  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

• expose supertrait edge on type Trait which should probably point to type ImplementedTrait

  • new lints enabled by this:
    • trait removed supertrait

• 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

• 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 type
    • static 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