Type references can resolve to classes

[Julow]

In the example below, type-c resolves to `Identifier (`Class (`Root (Common.root, Root), c)) but we'd expect a type.

class c : object
  method m : int
end

Currently type-c.m resolves but shouldn't because the type c would be an object type and not a class (#525)

[lpw25]

This is the intended behaviour, or at least it was when I wrote it. The Class in the identifier refers to the definition that is actually in the file -- which is indeed a class. The "kinds" on identifiers and paths are actually slightly different concepts: the kind of an identifier refers to the nature of the definition that is referred to, whilst the kind of a path refers to the nature of the thing itself. For instance a type identifier refers to an actual type definition in the source, whilst a type path refers to a semantic type and may actually point to e.g. a class definition.

[lpw25]

(type-c.m resolving is indeed a bug though)

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. The main purpose of this is to keep the issue tracker focused to what is actively being worked on, so that the amount and variety of open yet inactive issues does not overwhelm contributors.

An issue closed as stale is not rejected — further discussion is welcome in its closed state, and it can be resurrected at any time. odoc maintainers regularly check issues that were closed as stale in the past, to see if the time is right to reopen and work on them again. PRs addressing issues closed as stale are as welcome as PRs for open issues. They will be given the same review attention, and any other help.

[Julow]

Let's leave this closed.

[panglesd]

(type-c.m resolving is indeed a bug though)

This might be solved depending on how far #933 goes