@@ -101,8 +101,10 @@ class TypeHierarchyTreeItem extends vscode.TreeItem {
101101class TypeHierarchyFeature implements vscodelc . StaticFeature {
102102 private serverSupportsTypeHierarchy = false ;
103103 private state ! : vscodelc . State ;
104+ private context : ClangdContext ;
104105
105106 constructor ( context : ClangdContext ) {
107+ this . context = context ;
106108 new TypeHierarchyProvider ( context ) ;
107109 context . subscriptions . push ( context . client . onDidChangeState ( stateChange => {
108110 this . state = stateChange . newState ;
@@ -116,10 +118,21 @@ class TypeHierarchyFeature implements vscodelc.StaticFeature {
116118 initialize ( capabilities : vscodelc . ServerCapabilities ,
117119 documentSelector : vscodelc . DocumentSelector | undefined ) {
118120 const serverCapabilities : vscodelc . ServerCapabilities &
119- { typeHierarchyProvider ?: any } = capabilities ;
120- if ( serverCapabilities . typeHierarchyProvider ) {
121+ { standardTypeHierarchyProvider ?: any } = capabilities ;
122+ // Unfortunately clangd used the same capability name for its pre-standard
123+ // protocol as the standard ended up using. We need to prevent
124+ // vscode-languageclient from trying to query clangd versions that speak the
125+ // incompatible protocol.
126+ if ( serverCapabilities . typeHierarchyProvider &&
127+ ! serverCapabilities . standardTypeHierarchyProvider ) {
128+ // Disable mis-guided support for standard type-hierarchy feature.
129+ this . context . client . getFeature ( 'textDocument/prepareTypeHierarchy' )
130+ . dispose ( ) ;
121131 this . serverSupportsTypeHierarchy = true ;
122132 this . recomputeEnableTypeHierarchy ( ) ;
133+ } else {
134+ // Either clangd has support for the standard protocol, or no
135+ // implementation at all. In either case, don't turn on the extension.
123136 }
124137 }
125138 getState ( ) : vscodelc . FeatureState { return { kind : 'static' } ; }
0 commit comments