Introduce first-class support for duplicate or cross-kind top-level name
conflicts in the fine-grained analyzer pipeline.
- Add `declaredConflicts` to `LibraryManifest` to record names that are
declared more than once (e.g., two classes) or across kinds (e.g., a
class and a top-level function). Conflicts are assigned a generated
`ManifestItemId` that is exported and used consistently.
- Ensure conflict handling covers related lookup names (e.g., getter/
setter pairs `foo` and `foo=`), removing them from per-kind declared
maps and placing a single entry in `declaredConflicts`.
- Update manifest building to detect conflicts deterministically:
- Stage variables, then getters/setters, then non-property members.
- Track `conflictingTopLevelElements` to skip invalid incremental
updates.
- Include `declaredConflicts` in serialization/deserialization and in
`exportMap` / `exportedIds`. Make `getDeclaredId` prefer conflicts.
- In `manifest_context`, resolve top-level IDs via `declaredConflicts`
before per-kind maps for stable identity.
- In requirements computation, skip conflicted names when producing
instances/interfaces, preventing inconsistent shapes and crashes.
- Make exported extensions resolution null-safe when duplicates exist.
- Extend result printing to display `declaredConflicts`.
- Bump `DATA_VERSION` to 580.
Why: Previously the analyzer assumed unique top-level names, which led
to crashes and inconsistent IDs when a library contained duplicates
(e.g., duplicate extension types, multiple classes named the same, or a
class/function collision). Representing conflicts explicitly yields
stable IDs, predictable exports, and reliable incremental linking and
diagnostics.
Bug: https://github.com/dart-lang/sdk/issues/61741
Change-Id: If153ce467f45156ee3918b5211b8e5e7b7f164ea
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/456485
Reviewed-by: Paul Berry <paulberry@google.com>
Konstantin Shcheglov
cba0ec6ec5