Constructor ordering, defaults, and overloads

[Soreloser2]

Extension of #63320

Completion list copied with new items bolded/italicized:

• Implement quick action with positional parameters
  • Move Properties to positional parameters
    • With modified Attributes
    • With modified documentation comments
      • Single line
      • Multi line (too hard/not much support from syntax generators 😢)
    • Structs and readonly structs
    • Tests
  • Analyzing statements to delete members
    • Constructor conflicting with primary constructor
    • Equality operator overloads
    • Equals method(s)
    • HashCode method
    • Clone method
    • ToString (optional? Need design discussion)
    • Copy constructor
    • Tests
  • Analyzing declarations to modify members (mostly accessibility stuff)
    • EqualityContract, PrintMembers
      • not really necessary
    • Non-primary constructors (analyze and provide values instead of this(default, default...))
    • Modify order of positional params based on primary constructor order
    • Supply default values to primary constructor from removed primary constructor
    • Tests
  • Inheritance
    • Basic (copy previous list)
    • If base is record w/ positional params, give defaults
    • Modify members if they have a base initializer already
    • Tests (not for base handling)
  • Refactoring other locations
    • Turn property constructor into positional params
    • Tests
  • Minimum/Maximum # of props to move to positional params
    • Need design discussion (Is it reasonable to move 1 property or more than like 10?)
    • Tests
• Implement quick action w/o positional parameters
  • Abstract and modify analysis portion so we can use same code to delete things
  • Allow positional records to convert to non-positional and vice versa
    • Documentation comments
    • Attributes
    • This initializer
    • Refactoring (convert back to property initializer)
  • Tests

[jasonmalinowski]

Can we have a generic catch-all that just walks the child operations without having to special case all of these?

[jasonmalinowski]

We don't still need to check for IMemberReferenceOperation?

[Soreloser2]

Ah right, I forgot about the case where we access static members/methods. Any other member reference or invocation should have the instance and the member as ChildOperations so if a member reference of a local we should still hit it here.

[jasonmalinowski]

My main concern was whether a this reference counted as a local reference or as something else.