Use a more detailed page type for C++ namespaces in navigator index

[mportiz08]

Bug/issue #, if applicable: 122340677

Summary

This adds a new namespace case to the NavigatorIndex.PageType enum that can be used in RenderIndex to emit a more specific "namespace" page type instead of a generic "symbol" type in the Render Index JSON.

This is needed so that Swift-DocC-Render can distinguish namespaces from other generic symbols in the navigator and render them appropriately, like choosing an icon that is specific to namespaces.

Testing

Steps:

1. Run swift run docc convert Tests/SwiftDocCTests/Test\ Bundles/CxxSymbols.docc
2. Verify that the node for the Foo namespace symbol in Tests/SwiftDocCTests/Test\ Bundles/CxxSymbols.docc/.docc-build/index/index.json now has a type value of "namespace" and not "symbol"

Checklist

Make sure you check off the following items. If they cannot be completed, provide a reason.

• Added tests
• Ran the ./bin/test script and it succeeded
• Updated documentation if necessary

[d-ronnqvist]

Looks good to me. I would just ask that we continue to be defined the page type enum cases in the order of their raw value.

[d-ronnqvist]

Just for how these enum cases are organized, please add this case above the special items so that the cases continue to be defined in the order of their raw value.

[d-ronnqvist]

I also believe that this is a source breaking change since any existing code that was switching over this public enum now has a new case that it would need to handle. Maybe there's nothing we can do about it but it's worth calling mentioning.

[mportiz08]

Just for how these enum cases are organized, please add this case above the special items so that the cases continue to be defined in the order of their raw value.

420502e

[mportiz08]

I also believe that this is a source breaking change since any existing code that was switching over this public enum now has a new case that it would need to handle. Maybe there's nothing we can do about it but it's worth calling mentioning.

Are you aware of any way to do this in a non source breaking manner?

[d-ronnqvist]

Unfortunately I don't know of any other way. If we need to make a source breaking change it might be worth discussing if we should make a larger change now so that future changes can be made in a non-source breaking manner.

[daniel-grumberg]

I think it's OK to break source compatibility here.

[d-ronnqvist]

I think it's OK to break source compatibility here.

@daniel-grumberg Do you think that we should add something like this _nonfrozenEnum_useDefaultCase case to signal to clients that this enum may get additional cases again in the future or do you think it's unlikely that we'll add any other cases to this enum in the future?

[daniel-grumberg]

I think it's OK to break source compatibility here.

@daniel-grumberg Do you think that we should add something like this _nonfrozenEnum_useDefaultCase case to signal to clients that this enum may get additional cases again in the future or do you think it's unlikely that we'll add any other cases to this enum in the future?

I think that would be a great idea but let's do it as a follow up patch.

[daniel-grumberg]

@swift-ci please test

[d-ronnqvist]

@swift-ci please test