Imported From: https://issues.scala-lang.org/browse/SI-5287?orig=1
Reporter: @dcsobral
Affected Versions: 2.10.0

@VladUreche said:
Fixed in pull request 46.

@dcsobral said:
It is not fixed. See List, for instance:

trunk:

Definition Classes GenTraversableLike

2.9.1:

Definition Classes TraversableLike → GenTraversableLike → FilterMonadic

@VladUreche said:
Hi Daniel,

What method are you referring to?

@VladUreche said:
Now I see what you mean, the Definition Classes field is different for use cases and their corresponding full signatures.

Okay, this is starting to annoy me... Both this problem and the abstract annotation are related to how Symbol is initialized: at the time the use cases are generated, the member's Symbol has flag DEFERRED and is not (completely) initialized. Now I need to find out what exactly needs to be done to force initialization, as cloning it at the time it's DEFERRED yields all these incorrect results. It's funny that the problem was there all along, but nobody noticed the use case problems until I removed the full signatures. :))

Thanks for pointing it out, I'll look into it. Hopefully I'll fix it for good this time.

@paulp said:

Now I need to find out what exactly needs to be done to force initialization

In general, you call .initialize.

@paulp said:
But if the situation is really that the info is not up to date (I'm not plugged into the details here) then you might want to call sym.info before you do anything else with it.

@VladUreche said:
Seems the flags are not forced to the correct values upon calling .initialize. There's something I must be missing here...

@paulp said:
Did you do what it says in my second comment?

@VladUreche said:
Yes, I did. It turns out we're talking about two different symbols: One that is inserted in the use case by the typer (stored in UseCase.defined) and the actual symbol that scaladoc sees, after the typers phase ran. I would have expected they are the same, but they're not: they share the name, the type but not the flags.

The Usecase symbol is added when typers encounters a DocDef (Typers.scala:4017) by calling typedUseCase on Typers.scala:1643 and setting useCase.defined in Typers.scala:1669.

So the fix should be pretty simple: we need not rely on the symbol set by typers but on the symbol provided by scaladoc. On the other hand, I really want to understand why isn't the UseCase.defined symbol updated properly.

@VladUreche said:
Closing this bug as a duplicate of #5054, if you notice other strange behaviors in usecases please comment there.