Implement document symbols for validations

[aryan-soni]

Implements document symbol for the various types of Rails validations.

The remaining dsl feature is relationships. Based on my experience in this PR, it looks like the manner in which we handle each type of dsl feature doesn't generalize particularly cleanly. Consequently, after all the features are implemented, we can then reflect on the appropriate abstraction. Abstracting before comprehensive feature completion might cause us to create abstractions that we have to later rectify.

For now, these changes are scoped to focus on implementing validations exclusively.

[andyw8]

Suggested change

	message = node.message
	message = T.must(node.message)

then we can remove the T.musts below.

[aryan-soni]

Not sure about this one.

node.message is nilable. Once we enter the switch-case, we know for sure that it's not nil, but I don't think we can guarantee that before entering.

[aryan-soni]

Merged it without this, but we can fix this in the next PR based on your thoughts.

[andyw8]

Although it began with #280, I'm now thinking more that we should have a visual distinction between macros and plain methods:

[andyw8]

(we could perhaps push for a Macro type, as suggested here).

[andyw8]

One slight oddity: if you have multiple validations for one field, such as:

  validates :price, presence: true
  validates :price,
    numericality: { greater_than_or_equal_to: 0 },

Then you end up with multiple identical symbol entries.

ProductVariant in Core has a lot of this. I can't think of a better approach, but just wanted to highlight it.

[andyw8]

Tried on large files in Core and didn't see any issues. As mentioned in the PR description, we'll need to do some refactoring afterwards to help separate the different aspects relating to symbols.

[aryan-soni]

Although it began with #280, I'm now thinking more that we should have a visual distinction between macros and plain methods:

I agree, nothing in the set of symbols offered seems like a good fit.

It is fairly easy to change down the road, so if something new is eventually released, it will be easy for us to change things.

[aryan-soni]

One slight oddity: if you have multiple validations for one field, such as:

  validates :price, presence: true
  validates :price,
    numericality: { greater_than_or_equal_to: 0 },

Then you end up with multiple identical symbol entries.

ProductVariant in Core has a lot of this. I can't think of a better approach, but just wanted to highlight it.

Yeah, it comes down to whether we leverage the additional arguments.

I'm reflecting on this for the changes needed for relationships as well. For example, something like has_many :clients, :through => :appointments should potentially be displayed as has_many(clients, through: appointments).

As you mentioned, I don't think it's optimal to leverage something like this for validations. If someone specifies many arguments, it'll introduce a lot of complexity.

For each use case, we have to decide the benefits and costs of factoring in the arguments.