@tslite/checker 1.9.0 → 1.13.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/LICENSE +55 -0
- package/NOTICE +14 -0
- package/dist/_namespaces/ts.d.ts +9 -0
- package/dist/_namespaces/ts.js +12 -0
- package/dist/_namespaces/ts.moduleSpecifiers.d.ts +1 -0
- package/dist/_namespaces/ts.moduleSpecifiers.js +2 -0
- package/dist/check.d.ts +75 -0
- package/dist/check.js +316 -0
- package/dist/checker.d.ts +5 -0
- package/dist/checker.js +20881 -0
- package/dist/index.d.ts +1 -1132
- package/dist/index.js +4 -1
- package/dist/moduleSpecifiers.d.ts +12 -0
- package/dist/moduleSpecifiers.js +104 -0
- package/dist/symbolWalker.d.ts +3 -0
- package/dist/symbolWalker.js +167 -0
- package/dist/types.d.ts +864 -0
- package/dist/types.js +355 -0
- package/dist/utilities.d.ts +34 -0
- package/dist/utilities.js +157 -0
- package/lib/lib.tslite.d.ts +56 -0
- package/package.json +28 -49
- package/dist/chunk-NXZILQOD.js +0 -1
- package/dist/index.cjs +0 -1
- package/dist/index.d.cts +0 -1132
- package/dist/types/index.cjs +0 -1
- package/dist/types/index.d.cts +0 -1135
- package/dist/types/index.d.ts +0 -1135
- package/dist/types/index.js +0 -1
package/dist/index.d.cts
DELETED
|
@@ -1,1132 +0,0 @@
|
|
|
1
|
-
import { VarSchema, Schema, Schemes, TypeScheme, ObjectSchema, Completion } from './types/index.cjs';
|
|
2
|
-
export { AnySchema, ApplySchema, ArraySchema, Bindings, Candidates, DEFAULT_TYPE_LIMITS, Discovery, ElementFlag, FnSchema, GuardSig, INSTANTIATION_COUNT_LIMIT, INSTANTIATION_DEPTH_LIMIT, Incompatibility, IncompatibilityKind, IndexSchema, InferencePriority, Instantiation, InstantiationLimitError, KeyofSchema, LiteralSchema, MappedSchema, OverloadSchema, Param, PathSegment, Prop, ScalarSchema, TYPE_EVAL_DEPTH_LIMIT, TupleSchema, TypeEvalLimitError, TypeEvalLimits, TypeForm, TypePosition, UnionSchema, UnionTooComplexError, UnknownSchema, VarCandidates, WriteKey, apparentType, asLiteralOrigin, baseLiteralType, bindTypeParams, comparable, configureTypeLimits, contravariantInference, covariantInference, createInferences, discover, equals, erasedSignature, expand1, flagAt, format, formatTypeArgs, formatTypeDiff, freeVars, groundVars, inferFromCandidates, inferTypes, inferredBindings, inferredTypes, instantiateInContextOf, instantiateLoose, isMissingType, isNumericLiteralName, isObjectOrArrayLiteral, isScheme, isSerializable, isVariadicTuple, join, joinAll, missingType, normalizeUnion, ownProp, readonlyMember, renameTypeParams, resetInstantiationCount, resetTypeLimits, resolveConditional, resolveOp, resolveTypeOp, restIndex, restTypeAtPosition, s, sampleValue, silentNever, substitute, subtype, typeAtPosition, typeDiff, typeFeatures, typeLimits, typeNameOf, typeNeedsParens, typeParamArity, version, widen, widenInferred, widenLiteral, widenOrigin, widenType, withUndefined, withoutUndefined } from './types/index.cjs';
|
|
3
|
-
import { BaseNode, Scope as Scope$1, Node, types, SourceLocation, Expression } from '@tslite/ast';
|
|
4
|
-
import { CapabilityProfile, CompiledProfile } from '@tslite/capability';
|
|
5
|
-
import { Span } from '@tslite/language-service';
|
|
6
|
-
|
|
7
|
-
/** As declarações de tipo nominal: o nome e os type params, em ordem. */
|
|
8
|
-
type Nominals = Readonly<Record<string, readonly VarSchema[]>>;
|
|
9
|
-
|
|
10
|
-
type Severity = "error" | "warning";
|
|
11
|
-
type DiagnosticCode = "not-assignable" | "unknown-name" | "not-callable" | "no-such-member" | "not-object" | "possibly-nullish" | "unknown-value" | "const-needs-init" | "cannot-redeclare" | "circular-type-alias" | "circular-type-annotation" | "unknown-module" | "not-a-schema" | "type-as-value" | "asserter-needs-name" | "shadows-schema" | "missing-argument" | "excess-argument" | "excess-property" | "spread-argument" | "required-after-optional" | "not-iterable" | "not-spreadable" | "overwritten-property" | "implicit-any" | "props-mismatch" | "no-matching-overload" | "constraint-violation" | "wrong-type-argument-count" | "unsupported" | "unused-name" | "assign-to-const" | "for-in-destructuring" | "for-in-not-object" | "readonly-write" | "cast-unsound" | "unprovable-value" | "not-arithmetic-operand" | "operator-not-applicable" | "no-overlap" | "uncalled-function-check" | "not-comparable" | "misplaced-namespace" | "misplaced-modifier" | "ambient-initializer" | "ambient-statement" | "used-before-assigned" | "used-before-declaration" | "implicit-coercion" | "node-not-allowed" | "name-not-allowed" | "type-feature-not-allowed" | "any-not-allowed" | "narrowing-cast-not-allowed" | "too-deep" | "too-complex-union" | "too-large" | "wrong-result-type";
|
|
12
|
-
/**
|
|
13
|
-
* A **classe** do diagnóstico — espelha a divisão de passes do `tsc` (que nós
|
|
14
|
-
* fundimos num walk só): `semantic` é o que o **binder** do tsc pega (validade do
|
|
15
|
-
* programa, independe de tipos — nome inexistente, redeclaração, módulo, `const`
|
|
16
|
-
* sem init, recurso fora da Linguagem); `type` é o que o **checker** de tipos pega
|
|
17
|
-
* (relações/compatibilidade); `capability` é política/limite (feature gated, caps).
|
|
18
|
-
* O `kind` deriva do `code` (fonte única, mapa `KIND`) — o consumidor (editor/nocode)
|
|
19
|
-
* distingue "isto é programa inválido" de "isto é incompatibilidade de tipo".
|
|
20
|
-
*/
|
|
21
|
-
type DiagnosticKind = "semantic" | "type" | "capability";
|
|
22
|
-
/**
|
|
23
|
-
* Uma propriedade que o tipo esperado exige e o valor não tem.
|
|
24
|
-
*
|
|
25
|
-
* O `type` é o ESPERADO — é o que permite a quem corrige inserir um valor
|
|
26
|
-
* plausível (`""`, `0`, `[]`) em vez de um buraco.
|
|
27
|
-
*/
|
|
28
|
-
interface MissingProperty {
|
|
29
|
-
readonly name: string;
|
|
30
|
-
readonly type: Schema;
|
|
31
|
-
}
|
|
32
|
-
/**
|
|
33
|
-
* Dado ESTRUTURADO do erro, para quem vai **agir** sobre ele.
|
|
34
|
-
*
|
|
35
|
-
* É o campo `data` do LSP, que existe exatamente para isto: levar informação do
|
|
36
|
-
* diagnóstico até o code action, sem que ninguém precise reconstruí-la. Aqui a
|
|
37
|
-
* motivação é concreta — o `notAssignable` já roda o `typeDiff` para escrever a
|
|
38
|
-
* mensagem; jogar o resultado fora obrigaria a camada de correção a recomputá-lo,
|
|
39
|
-
* e ela **não tem como**: o tipo ESPERADO não está no overlay.
|
|
40
|
-
*/
|
|
41
|
-
type DiagnosticData = {
|
|
42
|
-
readonly kind: "missing-properties";
|
|
43
|
-
/** As propriedades ausentes na RAIZ do valor (as aninhadas ficam de fora). */
|
|
44
|
-
readonly properties: readonly MissingProperty[];
|
|
45
|
-
} | {
|
|
46
|
-
/**
|
|
47
|
-
* `implicit-coercion` (D40): o `+` recusou uma mistura, ou um template
|
|
48
|
-
* recebeu algo que não converte.
|
|
49
|
-
*
|
|
50
|
-
* `textConvertible` diz se o valor culpado **poderia** virar texto (escalar)
|
|
51
|
-
* ou se é ESTRUTURA. É o que decide o conserto, e por isso vem estruturado em
|
|
52
|
-
* vez de deduzido da prosa: com escalar o auto-fix propõe template literal;
|
|
53
|
-
* com estrutura, template não conserta nada — só moveria o erro —, e o
|
|
54
|
-
* caminho é `stringify`.
|
|
55
|
-
*/
|
|
56
|
-
readonly kind: "implicit-coercion";
|
|
57
|
-
readonly textConvertible: boolean;
|
|
58
|
-
};
|
|
59
|
-
/**
|
|
60
|
-
* Outro lugar do programa que explica o diagnóstico — o `DiagnosticRelatedInformation` do
|
|
61
|
-
* tsc (`types.ts`), que o `addRelatedInfo` anexa, e o `relatedInformation` do LSP. O nó é
|
|
62
|
-
* por referência, como o do diagnóstico; a mensagem diz o papel dele ("This spread always
|
|
63
|
-
* overwrites this property.").
|
|
64
|
-
*/
|
|
65
|
-
interface DiagnosticRelatedInformation {
|
|
66
|
-
readonly node: BaseNode;
|
|
67
|
-
readonly message: string;
|
|
68
|
-
}
|
|
69
|
-
interface Diagnostic {
|
|
70
|
-
readonly code: DiagnosticCode;
|
|
71
|
-
/** A classe do diagnóstico (deriva do `code`) — ver {@link DiagnosticKind}. */
|
|
72
|
-
readonly kind: DiagnosticKind;
|
|
73
|
-
readonly severity: Severity;
|
|
74
|
-
/** O nó culpado — identidade por referência. */
|
|
75
|
-
readonly node: BaseNode;
|
|
76
|
-
readonly message: string;
|
|
77
|
-
/** Ver {@link DiagnosticData}. Presente só onde há o que agir. */
|
|
78
|
-
readonly data?: DiagnosticData;
|
|
79
|
-
/** Ver {@link DiagnosticRelatedInformation}. Presente só onde o tsc a anexa. */
|
|
80
|
-
readonly relatedInformation?: readonly DiagnosticRelatedInformation[];
|
|
81
|
-
}
|
|
82
|
-
/**
|
|
83
|
-
* Builder genérico de diagnóstico (severidade configurável). Usado pelos
|
|
84
|
-
* guardrails, que têm seu próprio catálogo de mensagens em `guard`. O `kind`
|
|
85
|
-
* deriva do `code` (mesma fonte única).
|
|
86
|
-
*/
|
|
87
|
-
declare const makeDiagnostic: (code: DiagnosticCode, node: BaseNode, message: string, severity?: Severity) => Diagnostic;
|
|
88
|
-
/**
|
|
89
|
-
* Um diagnóstico do AMBIENTE (D93): o erro no contrato que o host declara pelo `createEnv` —
|
|
90
|
-
* o equivalente dos erros de um `.d.ts` no tsc, que são do arquivo de declarações, e não do
|
|
91
|
-
* programa que o usa. O ambiente não tem nó: o lugar é o caminho dentro das opções do
|
|
92
|
-
* `createEnv` — a opção, a chave, e o caminho no `Schema` até o nome (`["vars",
|
|
93
|
-
* "state.phase"]`, `["schemes", "state.R", "body", "props", "a", "type"]`).
|
|
94
|
-
*/
|
|
95
|
-
interface EnvDiagnostic {
|
|
96
|
-
readonly code: DiagnosticCode;
|
|
97
|
-
/** A classe do diagnóstico (deriva do `code`) — ver {@link DiagnosticKind}. */
|
|
98
|
-
readonly kind: DiagnosticKind;
|
|
99
|
-
readonly severity: Severity;
|
|
100
|
-
readonly message: string;
|
|
101
|
-
/** Onde, no ambiente: a opção, a chave e o caminho no `Schema`. */
|
|
102
|
-
readonly path: readonly (string | number)[];
|
|
103
|
-
}
|
|
104
|
-
/**
|
|
105
|
-
* Fábricas de diagnósticos. Mensagens no estilo do tsc, com tipos renderizados
|
|
106
|
-
* por `format`.
|
|
107
|
-
*/
|
|
108
|
-
declare const diag: {
|
|
109
|
-
notAssignable: (node: BaseNode, actual: Schema, expected: Schema, schemes?: Schemes) => Diagnostic;
|
|
110
|
-
unknownName: (node: BaseNode, name: string) => Diagnostic;
|
|
111
|
-
notCallable: (node: BaseNode, type: Schema) => Diagnostic;
|
|
112
|
-
noSuchMember: (node: BaseNode, type: Schema, key: string) => Diagnostic;
|
|
113
|
-
notObject: (node: BaseNode, type: Schema) => Diagnostic;
|
|
114
|
-
/**
|
|
115
|
-
* Ler ou chamar através de um valor que pode ser `null`/`undefined` — o
|
|
116
|
-
* `checkNonNullTypeWithReporter` do tsc (`checker.ts:24098`), que tem uma mensagem por
|
|
117
|
-
* combinação, e a variante "Cannot invoke" quando o valor é chamado.
|
|
118
|
-
*/
|
|
119
|
-
possiblyNullish: (node: BaseNode, nullish: {
|
|
120
|
-
readonly null: boolean;
|
|
121
|
-
readonly undefined: boolean;
|
|
122
|
-
}, invoked?: boolean) => Diagnostic;
|
|
123
|
-
/**
|
|
124
|
-
* Usar um valor `unknown` como objeto — ler dele, chamá-lo, indexá-lo ou operar
|
|
125
|
-
* sobre ele. É o mesmo `checkNonNullTypeWithReporter` (`checker.ts:24102`), no ramo
|
|
126
|
-
* que vem ANTES do nullish e em três linhas:
|
|
127
|
-
*
|
|
128
|
-
* if (strictNullChecks && type.flags & TypeFlags.Unknown) {
|
|
129
|
-
* error(node, Diagnostics.Object_is_of_type_unknown);
|
|
130
|
-
* return errorType;
|
|
131
|
-
* }
|
|
132
|
-
*
|
|
133
|
-
* Um código só e uma mensagem só, para os seis usos (o TS2571 da 3.9.10 — o
|
|
134
|
-
* TS18046 é de versão posterior e não existe na tag).
|
|
135
|
-
*/
|
|
136
|
-
unknownValue: (node: BaseNode) => Diagnostic;
|
|
137
|
-
constNeedsInit: (node: BaseNode) => Diagnostic;
|
|
138
|
-
/** TS1182: o padrão sem valor, de qualquer kind, fora do contexto ambiente — o
|
|
139
|
-
* `checkGrammarVariableDeclaration` o testa antes do TS1155. */
|
|
140
|
-
destructuringNeedsInit: (node: BaseNode) => Diagnostic;
|
|
141
|
-
missingArgument: (node: BaseNode, name: string, expected: Schema) => Diagnostic;
|
|
142
|
-
notASchema: (node: BaseNode, name: string) => Diagnostic;
|
|
143
|
-
typeAsValue: (node: BaseNode, name: string) => Diagnostic;
|
|
144
|
-
asserterNeedsName: (node: BaseNode, asserter: string) => Diagnostic;
|
|
145
|
-
shadowsSchema: (node: BaseNode, name: string) => Diagnostic;
|
|
146
|
-
unknownModule: (node: BaseNode, source: string) => Diagnostic;
|
|
147
|
-
/**
|
|
148
|
-
* O mesmo nome declarado de novo onde não pode, com o texto de cada mecanismo do tsc
|
|
149
|
-
* 3.9.10. O conceito é um só, o do `cannot-redeclare` (D2), e o nó é o NOME de cada
|
|
150
|
-
* declaração acusada.
|
|
151
|
-
*/
|
|
152
|
-
redeclaration: {
|
|
153
|
-
/** TS2451: o que está na tabela é variável de escopo de bloco (o `declareSymbol` do
|
|
154
|
-
* binder, `binder.ts:476`), em cada declaração. */
|
|
155
|
-
blockScoped: (node: BaseNode, name: string) => Diagnostic;
|
|
156
|
-
/** TS2300: o que está na tabela é outra coisa (um parâmetro, um import, um alias, um
|
|
157
|
-
* namespace), em cada declaração. */
|
|
158
|
-
duplicate: (node: BaseNode, name: string) => Diagnostic;
|
|
159
|
-
/** TS2440: o import fundido com uma declaração local que ocupa o significado do alvo
|
|
160
|
-
* dele (o `checkAliasSymbol`, `checker.ts:34279`), no especificador. */
|
|
161
|
-
importConflict: (node: BaseNode, name: string) => Diagnostic;
|
|
162
|
-
/** TS2492: o bloco do `catch` declara de novo o binding dele (o `checkTryStatement`,
|
|
163
|
-
* `checker.ts:33056`), na declaração do bloco. */
|
|
164
|
-
catchClause: (node: BaseNode, name: string) => Diagnostic;
|
|
165
|
-
/** TS2395: declarações do mesmo símbolo, umas exportadas e outras locais, no mesmo
|
|
166
|
-
* espaço (o `checkExportsOnMergedDeclarations`, `checker.ts:30401`), em cada uma. */
|
|
167
|
-
mixedExport: (node: BaseNode, name: string) => Diagnostic;
|
|
168
|
-
};
|
|
169
|
-
circularTypeAlias: (node: BaseNode, name: string) => Diagnostic;
|
|
170
|
-
circularTypeAnnotation: (node: BaseNode, name: string) => Diagnostic;
|
|
171
|
-
excessArgument: (node: BaseNode, expected: number, got: number) => Diagnostic;
|
|
172
|
-
/**
|
|
173
|
-
* A ARIDADE de uma chamada, com o texto do `getArgumentArityError` do tsc
|
|
174
|
-
* (`checker.ts:25477`): `Expected {range} arguments, but got {got}.` (TS2554), e
|
|
175
|
-
* `Expected at least {min} arguments, but got {got}.` quando a assinatura tem rest
|
|
176
|
-
* (TS2555). O `range` é `min` ou `min-max`, e o plural é sempre plural, como lá.
|
|
177
|
-
*
|
|
178
|
-
* O CÓDIGO continua dizendo a direção — `missing-argument` quando faltam, e
|
|
179
|
-
* `excess-argument` quando sobram —, que é informação que o texto do tsc perdeu ao
|
|
180
|
-
* usar um único TS2554 para os dois. A régua é a D2: o código é o contrato, a mensagem
|
|
181
|
-
* é prosa.
|
|
182
|
-
*/
|
|
183
|
-
argumentArity: (node: BaseNode, range: string, got: number, kind: "missing" | "excess", atLeast?: boolean) => Diagnostic;
|
|
184
|
-
excessProperty: (node: BaseNode, name: string, target: Schema) => Diagnostic;
|
|
185
|
-
spreadArgument: (node: BaseNode) => Diagnostic;
|
|
186
|
-
requiredAfterOptional: (node: BaseNode) => Diagnostic;
|
|
187
|
-
notIterable: (node: BaseNode, type: Schema) => Diagnostic;
|
|
188
|
-
/**
|
|
189
|
-
* A fonte não se espalha: o `isValidSpreadType` do tsc (`checker.ts:23342`) a recusa. O
|
|
190
|
-
* código é o do conceito, par do `not-iterable` do padrão de array; a mensagem diz o caso.
|
|
191
|
-
*/
|
|
192
|
-
notSpreadable: {
|
|
193
|
-
/** TS2700: o rest de um padrão de objeto (`{ a, ...rest }`), no elemento do rest
|
|
194
|
-
* (`getTypeForBindingElement`, `checker.ts:7439`). D80. */
|
|
195
|
-
rest: (node: BaseNode) => Diagnostic;
|
|
196
|
-
/** TS2698: o spread num literal de objeto (`{ ...x }`), no membro `...x`
|
|
197
|
-
* (`checkObjectLiteral`, `checker.ts:23254`). */
|
|
198
|
-
spread: (node: BaseNode) => Diagnostic;
|
|
199
|
-
};
|
|
200
|
-
/**
|
|
201
|
-
* A chave escrita duas vezes num literal de objeto. O tsc a acusa por três mecanismos, e
|
|
202
|
-
* cada um é um diagnóstico com o texto e o nó dele; o conceito é um só, o do
|
|
203
|
-
* `cannot-redeclare` (D25).
|
|
204
|
-
*/
|
|
205
|
-
duplicateKey: {
|
|
206
|
-
/** TS1117: a chave IDENTIFICADOR repetida, no modo estrito (o `bindObjectLiteralExpression`
|
|
207
|
-
* do binder, `binder.ts:2037`), na repetição. */
|
|
208
|
-
strict: (node: BaseNode) => Diagnostic;
|
|
209
|
-
/** TS2300: o nome repetido (o `checkGrammarObjectLiteralExpression`), na repetição, com o
|
|
210
|
-
* texto do nome como escrito. */
|
|
211
|
-
identifier: (node: BaseNode, text: string) => Diagnostic;
|
|
212
|
-
/** TS2718: a chave computada ligada tarde com o nome de uma prop ligada cedo (o
|
|
213
|
-
* `lateBindMember`), na chave tardia. */
|
|
214
|
-
lateBound: (node: BaseNode, name: string) => Diagnostic;
|
|
215
|
-
/** TS2733: a primeira declaração ligada cedo desse nome, no mesmo `lateBindMember`. */
|
|
216
|
-
alsoDeclared: (node: BaseNode, name: string) => Diagnostic;
|
|
217
|
-
};
|
|
218
|
-
/**
|
|
219
|
-
* TS2783: a prop escrita num literal de objeto que um spread seguinte sempre sobrescreve,
|
|
220
|
-
* na prop escrita, com o spread na informação relacionada (TS2785) — o
|
|
221
|
-
* `checkSpreadPropOverrides` do tsc (`checker.ts:23558`).
|
|
222
|
-
*/
|
|
223
|
-
overwrittenProperty: (node: BaseNode, name: string, spread: BaseNode) => Diagnostic;
|
|
224
|
-
/**
|
|
225
|
-
* O `any` que ninguém escreveu — o `noImplicitAny` do tsc 3.9.10, que faz parte do
|
|
226
|
-
* `--strict` e está sempre ligado aqui (D81). Um código só, com o texto de cada caso (o
|
|
227
|
-
* `reportImplicitAny`, `checker.ts:18198`, e os sítios do acesso e do `let` evolving): o
|
|
228
|
-
* código é o conceito, a mensagem diz qual é o caso (D2), como o `possibly-nullish`.
|
|
229
|
-
*/
|
|
230
|
-
implicitAny: {
|
|
231
|
-
/** TS7006, no nome do parâmetro sem anotação e sem contexto. */
|
|
232
|
-
parameter: (node: BaseNode, name: string) => Diagnostic;
|
|
233
|
-
/** TS7019, no nome do rest sem anotação e sem contexto. */
|
|
234
|
-
rest: (node: BaseNode, name: string) => Diagnostic;
|
|
235
|
-
/** TS7031, em cada folha de um parâmetro-padrão sem anotação nem contexto. */
|
|
236
|
-
bindingElement: (node: BaseNode, name: string) => Diagnostic;
|
|
237
|
-
/** TS7034, no nome do `let` evolving que uma closure lê. */
|
|
238
|
-
evolving: (node: BaseNode, name: string) => Diagnostic;
|
|
239
|
-
/** TS7005, na leitura desse `let` dentro da closure. */
|
|
240
|
-
variable: (node: BaseNode, name: string) => Diagnostic;
|
|
241
|
-
/** TS7053, no acesso inteiro: a chave não indexa o objeto. */
|
|
242
|
-
index: (node: BaseNode, key: Schema, target: Schema) => Diagnostic;
|
|
243
|
-
/** TS7015, na chave: o objeto só tem índice numérico, e a chave não é número. */
|
|
244
|
-
indexNotNumber: (node: BaseNode) => Diagnostic;
|
|
245
|
-
};
|
|
246
|
-
/**
|
|
247
|
-
* A posição de um padrão de array além do comprimento de uma tupla — o TS2493 do tsc, no
|
|
248
|
-
* nome (`getPropertyTypeForIndexType`, `checker.ts:12886`). O código é o `no-such-member`,
|
|
249
|
-
* o mesmo do acesso `t[5]` (TC43): a posição é uma propriedade que a tupla não tem.
|
|
250
|
-
*/
|
|
251
|
-
tupleIndexOutOfRange: (node: BaseNode, tuple: Schema, length: number, index: number) => Diagnostic;
|
|
252
|
-
propsMismatch: (node: BaseNode, props: Schema, detail: string) => Diagnostic;
|
|
253
|
-
noMatchingOverload: (node: BaseNode, type: Schema, argTypes: readonly Schema[]) => Diagnostic;
|
|
254
|
-
/** O argumento de tipo fora do bound — o texto do TS2344 da tag, com a constraint no
|
|
255
|
-
* lugar do `{1}`. */
|
|
256
|
-
constraintViolation: (node: BaseNode, actual: Schema, bound: Schema) => Diagnostic;
|
|
257
|
-
unsupported: (node: BaseNode, what: string) => Diagnostic;
|
|
258
|
-
/**
|
|
259
|
-
* O nome usado antes da declaração dele, com o texto de cada mecanismo do tsc 3.9.10. O
|
|
260
|
-
* conceito é um só (D2), e o nó é o USO.
|
|
261
|
-
*/
|
|
262
|
-
usedBeforeDeclaration: {
|
|
263
|
-
/** TS2448: a variável de escopo de bloco (o `checkResolvedBlockScopedVariable`,
|
|
264
|
-
* `checker.ts:2259`), com a declaração na informação relacionada (TS2728). */
|
|
265
|
-
blockScoped: (node: BaseNode, name: string, declaration: BaseNode) => Diagnostic;
|
|
266
|
-
/** TS2372: o default de um parâmetro cita o próprio parâmetro (`checker.ts:2009`). */
|
|
267
|
-
parameterSelf: (node: BaseNode, parameter: string) => Diagnostic;
|
|
268
|
-
/** TS2373: o default de um parâmetro cita um declarado depois dele (`checker.ts:2013`). */
|
|
269
|
-
parameterAfter: (node: BaseNode, parameter: string, name: string) => Diagnostic;
|
|
270
|
-
};
|
|
271
|
-
/** TS2454: a leitura de uma variável que, por algum caminho, ainda não recebeu valor. */
|
|
272
|
-
usedBeforeAssigned: (node: BaseNode, name: string) => Diagnostic;
|
|
273
|
-
/** O namespace (D83), com o texto do tsc em cada um. */
|
|
274
|
-
namespace: {
|
|
275
|
-
/** TS2503: o primeiro segmento de um nome qualificado não é namespace nenhum. O
|
|
276
|
-
* código é o do nome que não existe, como o TS2304. */
|
|
277
|
-
notFound: (node: BaseNode, name: string) => Diagnostic;
|
|
278
|
-
/** TS2694: o namespace não exporta o membro, no segmento do membro. */
|
|
279
|
-
noExportedMember: (node: BaseNode, namespace: string, member: string) => Diagnostic;
|
|
280
|
-
/** TS2708: um namespace só de tipos numa posição de valor — o par do TS2693. */
|
|
281
|
-
asValue: (node: BaseNode, name: string) => Diagnostic;
|
|
282
|
-
/** TS1235: a declaração fora do topo e de outro namespace, no primeiro token. */
|
|
283
|
-
misplaced: (node: BaseNode) => Diagnostic;
|
|
284
|
-
};
|
|
285
|
-
/** O lugar do modificador `declare` — o `checkGrammarModifiers` do tsc, no primeiro token
|
|
286
|
-
* da declaração, que é o `declare`. */
|
|
287
|
-
modifier: {
|
|
288
|
-
/** TS1184: o `declare` numa declaração fora do topo e do bloco de um namespace. */
|
|
289
|
-
cannotAppearHere: (node: BaseNode) => Diagnostic;
|
|
290
|
-
/** TS1038: o `declare` numa declaração que já está num contexto ambiente. */
|
|
291
|
-
alreadyAmbient: (node: BaseNode) => Diagnostic;
|
|
292
|
-
};
|
|
293
|
-
/** O contexto ambiente (`declare namespace`, e a declaração com `declare`) só declara — o
|
|
294
|
-
* `checkAmbientInitializer` e o `checkGrammarStatementInAmbientContext` do tsc, no nó de
|
|
295
|
-
* lá. */
|
|
296
|
-
ambient: {
|
|
297
|
-
/** TS1039: o inicializador que o contexto ambiente não aceita, nele. */
|
|
298
|
-
initializer: (node: BaseNode) => Diagnostic;
|
|
299
|
-
/** TS1254: o `const` sem anotação com um inicializador que não é literal, nele. */
|
|
300
|
-
constInitializer: (node: BaseNode) => Diagnostic;
|
|
301
|
-
/** TS1036: o statement que não é declaração, uma vez por bloco, no primeiro token. */
|
|
302
|
-
statement: (node: BaseNode) => Diagnostic;
|
|
303
|
-
};
|
|
304
|
-
/**
|
|
305
|
-
* Argumento de tipo explícito com aridade errada. Assinatura **sem** type params
|
|
306
|
-
* declarados conta como `expected: 0` — é o que o tsc faz quando
|
|
307
|
-
* `Signature.typeParameters` é `undefined` (ele nunca infere a lista). Com default, o
|
|
308
|
-
* esperado é a faixa (`"1-2"`). Mensagem no texto do TS2558, que é sempre plural.
|
|
309
|
-
*/
|
|
310
|
-
wrongTypeArgumentCount: (node: BaseNode, expected: number | string, got: number) => Diagnostic;
|
|
311
|
-
/** Nenhuma sobrecarga aceita a aridade, e há uma abaixo e outra acima (≅ TS2743). */
|
|
312
|
-
noOverloadTypeArgumentCount: (node: BaseNode, got: number, below: number, above: number) => Diagnostic;
|
|
313
|
-
/** Referência a um alias com aridade errada — as frases do tsc: TS2315 para um
|
|
314
|
-
* tipo que não é genérico, TS2314 para o resto (com o intervalo quando há default). */
|
|
315
|
-
genericTypeArity: (node: BaseNode, name: string, min: number, max: number) => Diagnostic;
|
|
316
|
-
/**
|
|
317
|
-
* Binding declarado e nunca lido. **Warning**, não erro: é higiene, não
|
|
318
|
-
* incompatibilidade — e o consumidor de editor o renderiza APAGADO (marker
|
|
319
|
-
* `Unnecessary`), não sublinhado. Mensagem no texto do TS6133.
|
|
320
|
-
*/
|
|
321
|
-
unusedName: (node: BaseNode, name: string) => Diagnostic;
|
|
322
|
-
/**
|
|
323
|
-
* Reatribuição de um binding IMUTÁVEL. Não é capability: a capability decide se
|
|
324
|
-
* `=` existe na Linguagem; se um `const` pode ser reatribuído é outra pergunta, e
|
|
325
|
-
* a resposta é sempre não (D9 — o piso é `const`). Mensagem no texto do TS2588 /
|
|
326
|
-
* TS2632 (import). Ver `mutation.ts`.
|
|
327
|
-
*/
|
|
328
|
-
assignToConst: (node: BaseNode, name: string, kind: "const" | "import" | "not-a-variable") => Diagnostic;
|
|
329
|
-
/**
|
|
330
|
-
* As chaves de um `for…in` não cabem no alvo dele (`let n: number; for (n in o)`). É a
|
|
331
|
-
* relação que falha — o tipo das chaves contra o tipo declarado do alvo —, e por isso
|
|
332
|
-
* o código é o `not-assignable`; o texto é o do TS2405 (`checkForInStatement`).
|
|
333
|
-
*/
|
|
334
|
-
forInTarget: (node: BaseNode) => Diagnostic;
|
|
335
|
-
/** `for ([a] in o)` — o alvo de um `for…in` é uma chave, não se desestrutura. TS2491. */
|
|
336
|
-
forInDestructuring: (node: BaseNode) => Diagnostic;
|
|
337
|
-
/** `for (k in n)` com `n` que não é objeto, `any` nem type param — o TS2407 do
|
|
338
|
-
* `checkForInStatement` do tsc (`checker.ts:32148`), no que se percorre, com o tipo sem o
|
|
339
|
-
* nulo. */
|
|
340
|
-
forInNotObject: (node: BaseNode, type: Schema) => Diagnostic;
|
|
341
|
-
/**
|
|
342
|
-
* Escrita por um ÍNDICE readonly — `readonly T[]` ou `{ readonly [k: string]: V }`. É
|
|
343
|
-
* a outra metade do modificador: a relação (TC29) diz quem pode ser ATRIBUÍDO a quem;
|
|
344
|
-
* isto diz quem pode ser ESCRITO. Texto do TS2542, no acesso inteiro. Os três casos de
|
|
345
|
-
* escrita recusada pelo `readonly` têm um código só (D77): o nó e o texto são os do tsc.
|
|
346
|
-
*/
|
|
347
|
-
readonlyWrite: (node: BaseNode, target: Schema) => Diagnostic;
|
|
348
|
-
/** Escrita numa PROPRIEDADE readonly — o TS2540, no nome (`o.a`) ou no argumento
|
|
349
|
-
* (`o["a"]`). O acesso vira o tipo-erro: a atribuição não é checada depois. D77. */
|
|
350
|
-
readonlyProperty: (node: BaseNode, name: string) => Diagnostic;
|
|
351
|
-
/** `delete` de uma PROPRIEDADE readonly — o TS2704, no operando. D77. */
|
|
352
|
-
readonlyDelete: (node: BaseNode) => Diagnostic;
|
|
353
|
-
/**
|
|
354
|
-
* Cast (`x as T`) entre tipos que não se sobrepõem na régua do tsc (`castOverlaps`:
|
|
355
|
-
* literal da origem alargado + comparabilidade). Erro, como o TS2352 — o texto é o
|
|
356
|
-
* dele. Se o cast pode estreitar é outra pergunta, de política: o
|
|
357
|
-
* `narrowing-cast-not-allowed` do `strict`.
|
|
358
|
-
*/
|
|
359
|
-
castUnsound: (node: BaseNode, from: Schema, to: Schema) => Diagnostic;
|
|
360
|
-
/**
|
|
361
|
-
* `parseAs(T, v)` em que o tipo de `v` não se sobrepõe a `T` na régua do `as`
|
|
362
|
-
* (`castOverlaps`). O asserter não confere o valor em build — a prova é de
|
|
363
|
-
* runtime —, mas aqui o build já sabe a resposta: a prova não é incerta, é
|
|
364
|
-
* impossível, e falhar é a única coisa que ela pode fazer. Erro, com a mesma
|
|
365
|
-
* severidade do `cast-unsound` (TS2352). Ancorado no VALOR: o tipo escolhido
|
|
366
|
-
* pode estar certo, e o valor errado é o caso comum.
|
|
367
|
-
*/
|
|
368
|
-
unprovableValue: (node: BaseNode, value: Schema, target: Schema, name: string) => Diagnostic;
|
|
369
|
-
/**
|
|
370
|
-
* Operando de operação aritmética (`*` `-` `/` `%` `**`, bitwise) ou de `++`/`--`
|
|
371
|
-
* que não é numérico. Espelha TS2362 (esquerdo) / TS2363 (direito) / TS2356 (`++`/`--`).
|
|
372
|
-
* `bigint`/enum ficam fora do vocabulário do TSL, então a mensagem cita só `number`/`any`.
|
|
373
|
-
*/
|
|
374
|
-
arithmeticOperand: (node: BaseNode, side: "left" | "right" | "operand") => Diagnostic;
|
|
375
|
-
/**
|
|
376
|
-
* `+` (nenhum lado string, nem ambos numéricos) ou relacional (`<` `>` `<=` `>=`)
|
|
377
|
-
* entre tipos incompatíveis. Espelha TS2365.
|
|
378
|
-
*/
|
|
379
|
-
operatorNotApplicable: (node: BaseNode, op: string, left: Schema, right: Schema) => Diagnostic;
|
|
380
|
-
/**
|
|
381
|
-
* TS2678: o `case` de um `switch` que não é comparável ao discriminante, no `case` — o
|
|
382
|
-
* `checkTypeComparableTo` do `checkSwitchStatement` do tsc (`checker.ts:32977`). Os tipos
|
|
383
|
-
* chegam como a comparação os viu: alargados até a base, a menos que os dois sejam
|
|
384
|
-
* literais. O tsc elabora a relação num objeto (TS2741, TS2740); aqui a mensagem é a do
|
|
385
|
-
* TS2678, e o código é o contrato (D2).
|
|
386
|
-
*/
|
|
387
|
-
notComparable: (node: BaseNode, source: Schema, target: Schema) => Diagnostic;
|
|
388
|
-
/**
|
|
389
|
-
* TS2774: a condição de um `if` ou de um `?:` é uma função que nunca é falsy, e o ramo
|
|
390
|
-
* verdadeiro não a usa — o `checkTestingKnownTruthyCallableType` do tsc
|
|
391
|
-
* (`checker.ts:31963`), na condição.
|
|
392
|
-
*/
|
|
393
|
-
uncalledFunctionCheck: (node: BaseNode) => Diagnostic;
|
|
394
|
-
/**
|
|
395
|
-
* TS2367: uma igualdade entre tipos sem sobreposição, cujo resultado já é sabido — o
|
|
396
|
-
* `tryGiveBetterPrimaryError` do tsc (`checker.ts`, no `reportOperatorError`): `'false'`
|
|
397
|
-
* para `===`/`==`, `'true'` para `!==`/`!=`. Os tipos chegam como a mensagem os mostra
|
|
398
|
-
* (as bases, quando os literais também não se relacionam). Com `missingAwait`, os dois
|
|
399
|
-
* lados se relacionariam desembrulhando o `Promise`, e a informação relacionada é o
|
|
400
|
-
* TS2773 (o `errorAndMaybeSuggestAwait`).
|
|
401
|
-
*/
|
|
402
|
-
noOverlap: (node: BaseNode, op: string, left: Schema, right: Schema, missingAwait: boolean) => Diagnostic;
|
|
403
|
-
/**
|
|
404
|
-
* `"x" + n` — o `+` não converte para texto (Proposal 009).
|
|
405
|
-
*
|
|
406
|
-
* A mensagem carrega o CONSERTO porque a recusa é deliberada e **diverge do
|
|
407
|
-
* `tsc`**, que aceita: sem dizer o que fazer, o autor lê como defeito nosso. O
|
|
408
|
-
* template literal segue coagindo e não alonga o código: `"total: " + n` vira
|
|
409
|
-
* `` `total: ${n}` ``, do MESMO tamanho — e a partir de duas interpolações o
|
|
410
|
-
* template encurta.
|
|
411
|
-
*/
|
|
412
|
-
implicitCoercion: (node: BaseNode, left: Schema, right: Schema, textConvertible: boolean) => Diagnostic;
|
|
413
|
-
/**
|
|
414
|
-
* `` `${obj}` `` — o template converte ESCALAR, não estrutura (D40).
|
|
415
|
-
*
|
|
416
|
-
* Mesmo código do `+` de propósito: é a mesma decisão vista por outra sintaxe, e
|
|
417
|
-
* quem filtra por `code` quer as duas juntas. A mensagem é que muda, porque aqui
|
|
418
|
-
* o conserto é outro (`stringify`, não template).
|
|
419
|
-
*/
|
|
420
|
-
notTextConvertible: (node: BaseNode, t: Schema) => Diagnostic;
|
|
421
|
-
};
|
|
422
|
-
/**
|
|
423
|
-
* Coletor de diagnósticos — acumula durante o walk, sem `throw`.
|
|
424
|
-
*
|
|
425
|
-
* Guarda cada diagnóstico UMA vez: um segundo com o mesmo nó, o mesmo código, a mesma
|
|
426
|
-
* mensagem e a mesma informação relacionada não entra. É a coleção do tsc
|
|
427
|
-
* (`createDiagnosticCollection`, que insere pelo `insertSorted` e não repete o que o
|
|
428
|
-
* `compareDiagnostics` acha igual — ele compara também o `relatedInformation`), e é o que
|
|
429
|
-
* deixa um argumento ser tipado mais de uma vez — as rodadas da chamada (D53, D81) — sem
|
|
430
|
-
* que o erro de dentro dele saia duas vezes. Dois diagnósticos que só diferem na
|
|
431
|
-
* informação relacionada são dois: `{ a: 1, ...o1, ...o2 }` acusa o `a` uma vez por spread.
|
|
432
|
-
*/
|
|
433
|
-
interface DiagnosticSink {
|
|
434
|
-
/** Diagnósticos coletados, na ordem em que foram reportados, sem repetição. */
|
|
435
|
-
readonly all: readonly Diagnostic[];
|
|
436
|
-
/** Quantas vezes o `report` foi chamado, as repetições inclusive: é o que responde "esta
|
|
437
|
-
* operação acusou algo?", mesmo quando o que ela acusou já tinha sido acusado. */
|
|
438
|
-
readonly reported: number;
|
|
439
|
-
report(d: Diagnostic): void;
|
|
440
|
-
/** `true` se há ao menos um diagnóstico de severidade `error`. */
|
|
441
|
-
hasErrors(): boolean;
|
|
442
|
-
}
|
|
443
|
-
/** Cria um coletor vazio. */
|
|
444
|
-
declare function createSink(): DiagnosticSink;
|
|
445
|
-
|
|
446
|
-
/** O que uma declaração de namespace declara com um nome. */
|
|
447
|
-
interface NamespaceMember {
|
|
448
|
-
/** Visível de fora: tem `export`, ou está num contexto ambiente que exporta tudo. */
|
|
449
|
-
readonly exported: boolean;
|
|
450
|
-
/** O nome, onde o diagnóstico sobre a declaração pousa; `null` num membro do ambiente,
|
|
451
|
-
* que não tem texto. */
|
|
452
|
-
readonly id: BaseNode | null;
|
|
453
|
-
/** A chave do tipo no catálogo, quando não é o nome qualificado (`path.nome`): a de um
|
|
454
|
-
* tipo que outra declaração do mesmo namespace também declara (checker D88). */
|
|
455
|
-
readonly key?: string;
|
|
456
|
-
}
|
|
457
|
-
/** Uma declaração de namespace — um bloco. `namespace A.B { … }` são duas: o `A` e o `B`. */
|
|
458
|
-
interface NamespaceDeclaration {
|
|
459
|
-
/** O `TSModuleDeclaration`; `null` num namespace do ambiente, que vem das chaves do
|
|
460
|
-
* catálogo e não de texto. */
|
|
461
|
-
readonly node: BaseNode | null;
|
|
462
|
-
/** O caminho qualificado (`app.router`). */
|
|
463
|
-
readonly path: string;
|
|
464
|
-
/** A declaração de fora, ou `null` no topo. */
|
|
465
|
-
readonly parent: NamespaceDeclaration | null;
|
|
466
|
-
/** No contexto ambiente (`declare namespace`, e o que está dentro dele). */
|
|
467
|
-
readonly ambient: boolean;
|
|
468
|
-
/** O bloco tem valores (o `Instantiated` do `getModuleInstanceState`). */
|
|
469
|
-
readonly instantiated: boolean;
|
|
470
|
-
/** Os tipos que ESTE bloco declara (os locais do tsc, com o sentido de tipo). Um tipo e
|
|
471
|
-
* um namespace com o mesmo nome convivem, por isso as duas tabelas. */
|
|
472
|
-
readonly types: ReadonlyMap<string, NamespaceMember>;
|
|
473
|
-
/** Os namespaces que ESTE bloco declara. */
|
|
474
|
-
readonly namespaces: ReadonlyMap<string, NamespaceMember>;
|
|
475
|
-
/** Os valores que ESTE bloco declara — só no namespace do AMBIENTE (as variáveis do host
|
|
476
|
-
* com o nome qualificado, D93). Os do programa são tipados pelo walk (D90). */
|
|
477
|
-
readonly values?: ReadonlyMap<string, NamespaceMember>;
|
|
478
|
-
}
|
|
479
|
-
/** As declarações de namespace de uma raiz — o programa, ou o ambiente. */
|
|
480
|
-
interface Namespaces {
|
|
481
|
-
/** As declarações de cada namespace, pelo caminho, na ordem. */
|
|
482
|
-
readonly byPath: ReadonlyMap<string, readonly NamespaceDeclaration[]>;
|
|
483
|
-
/** A declaração de cada nó `TSModuleDeclaration` que está num lugar permitido. */
|
|
484
|
-
readonly byNode: WeakMap<BaseNode, NamespaceDeclaration>;
|
|
485
|
-
/** Os aliases escritos num namespace: o nó da declaração do alias → a do namespace. */
|
|
486
|
-
readonly aliasOwner: WeakMap<BaseNode, NamespaceDeclaration>;
|
|
487
|
-
}
|
|
488
|
-
|
|
489
|
-
/**
|
|
490
|
-
* Um nível de escopo léxico (nome → `Schema`), sobre o `Scope<T>` genérico do
|
|
491
|
-
* `ast` — a mesma cadeia que o `behavior` usa, com o payload do eixo de tipos.
|
|
492
|
-
*/
|
|
493
|
-
type Scope = Scope$1<Schema>;
|
|
494
|
-
/** Cria um escopo raiz (sem pai). */
|
|
495
|
-
declare const rootScope: (vars?: Record<string, Schema>) => Scope;
|
|
496
|
-
/** Estende `parent` com novos bindings, criando um escopo filho. */
|
|
497
|
-
declare const childScope: (parent: Scope, vars: Record<string, Schema>) => Scope;
|
|
498
|
-
/** Resolve `name` subindo a cadeia léxica. `undefined` se não existir. */
|
|
499
|
-
declare const lookup: (scope: Scope, name: string) => Schema | undefined;
|
|
500
|
-
/**
|
|
501
|
-
* Todos os nomes visíveis a partir de `scope`, com shadowing — o binding mais
|
|
502
|
-
* interno vence. É o que alimenta o autocomplete de identificadores. Duas
|
|
503
|
-
* chaves moram no mesmo escopo e não são nomes: a que tem `.` é um caminho
|
|
504
|
-
* estreitado por guard (`narrow`, D13), e a que termina em `#` é o tipo
|
|
505
|
-
* DECLARADO de um binding mutável (D63) — nenhum identificador tem esses
|
|
506
|
-
* caracteres.
|
|
507
|
-
*
|
|
508
|
-
* Um binding do programa tem a chave do SÍMBOLO (`nome@id`, D87), e dois símbolos com
|
|
509
|
-
* o mesmo nome são chaves diferentes: o nome visível é o de fora do `@`, e vale o mais
|
|
510
|
-
* interno. A cadeia vem de dentro para fora, e um refinamento de um símbolo só existe
|
|
511
|
-
* onde o nome dele não está sombreado — então a primeira chave de cada nome é a que ele
|
|
512
|
-
* denota ali.
|
|
513
|
-
*/
|
|
514
|
-
declare const visibleNames: (scope: Scope) => Map<string, Schema>;
|
|
515
|
-
/**
|
|
516
|
-
* `name`, visto de `scope`, denota um nome do AMBIENTE (a DI, a lib) — e não um símbolo
|
|
517
|
-
* do programa? É o que o tsc responde olhando a declaração do símbolo resolvido (o
|
|
518
|
-
* `defaultLibrary` do `classifier2020`). A primeira ligação do nome, de dentro para fora, é
|
|
519
|
-
* a que ele denota ali (ver `visibleNames`); `false` quando nada o liga.
|
|
520
|
-
*/
|
|
521
|
-
declare function resolvesToEnvironment(scope: Scope, name: string): boolean;
|
|
522
|
-
/**
|
|
523
|
-
* O ambiente injetado pela aplicação — a fronteira de tipos do sistema.
|
|
524
|
-
* `scope` é a raiz da DI; `types` resolve tipos nomeados em anotações.
|
|
525
|
-
*/
|
|
526
|
-
/**
|
|
527
|
-
* O ambiente é **só tipos** (a fronteira da DI). Capability — o que pode ser
|
|
528
|
-
* programado — é ortogonal e mora no `CapabilityProfile` (`@tslite/capability`),
|
|
529
|
-
* passado ao `check` por `{ profile }`. Não há mais noção de capability no Env.
|
|
530
|
-
*/
|
|
531
|
-
interface Env {
|
|
532
|
-
readonly scope: Scope;
|
|
533
|
-
readonly types: Readonly<Record<string, Schema>>;
|
|
534
|
-
/** Type schemes parametrizados (`type Pair<A, B> = …`), expandidos sob demanda. */
|
|
535
|
-
readonly schemes: Schemes;
|
|
536
|
-
/**
|
|
537
|
-
* Acessores **indexados por path literal**: nome → schema-base que ele navega.
|
|
538
|
-
* Ex.: `get` sobre o schema dos States → `get("hp","value")` tipa como
|
|
539
|
-
* `discover(base, ["hp","value"])`. É como a fronteira tipa leituras de estado
|
|
540
|
-
* sem `unknown` (o app declara o shape; o checker indexa). Default: nenhum.
|
|
541
|
-
*/
|
|
542
|
-
readonly accessors?: Readonly<Record<string, Schema>>;
|
|
543
|
-
/**
|
|
544
|
-
* **Asserters** (a fronteira sã): nomes de funções cujo retorno é o **tipo do
|
|
545
|
-
* schema nomeado** no 1º argumento. Ex.: com `parse` aqui, `parse(User, x)`
|
|
546
|
-
* tipa como `User` (e em runtime o `@tslite/validate` valida o valor). É o
|
|
547
|
-
* `parse()` estilo zod: fecha `unknown`/complexidade — o tipo "reseta" limpo
|
|
548
|
-
* na fronteira, **provado** em runtime (≠ `as`). Default: nenhum.
|
|
549
|
-
*/
|
|
550
|
-
readonly asserters?: ReadonlySet<string>;
|
|
551
|
-
/**
|
|
552
|
-
* **Matchers de props** (o diferencial): nomes de funções que checam, em
|
|
553
|
-
* edit-time, se um **payload** (saída de um serviço de automação / nocode) é
|
|
554
|
-
* **compatível com as props de um componente** react-like. Ex.: com
|
|
555
|
-
* `matchesProps` aqui, `matchesProps(Card, request)` extrai as props de `Card`
|
|
556
|
-
* (`(props) => Element`, agnóstico ao framework — Element é `apply` opaco) e
|
|
557
|
-
* verifica `request ≤ props` (campos a mais no request são OK; faltar/tipo-errado
|
|
558
|
-
* em prop obrigatória → diagnóstico `props-mismatch`). Retorna `boolean`. Default:
|
|
559
|
-
* nenhum.
|
|
560
|
-
*/
|
|
561
|
-
readonly matchers?: ReadonlySet<string>;
|
|
562
|
-
/**
|
|
563
|
-
* **Módulos** (a borda DI NOMEADA): especificador → o `object` Schema dos
|
|
564
|
-
* exports daquele módulo (`{ map: fn, filter: fn, …, default: … }`). É o D3
|
|
565
|
-
* estendido a módulos: `import { map } from "@x/ops"` liga `map` ao
|
|
566
|
-
* `modules["@x/ops"].props.map`. O checker **não resolve** o módulo (sem file
|
|
567
|
-
* system) — consome o tipo já provido; a *resolução* (qual módulo é o
|
|
568
|
-
* especificador) é da app (Proposal 005). Default: nenhum.
|
|
569
|
-
*/
|
|
570
|
-
readonly modules?: Readonly<Record<string, Schema>>;
|
|
571
|
-
/**
|
|
572
|
-
* Os aliases da **lib padrão** (`Partial`, `Pick`, `Record`, `Omit`, `ReturnType`…),
|
|
573
|
-
* o texto do `lib.es5.d.ts` do tsc 3.9.10 com o corte do TSLite (D79). Ficam ABAIXO
|
|
574
|
-
* de tudo: um tipo do host ou um alias do programa com o mesmo nome os sombreia.
|
|
575
|
-
* Vazio com `noLib`.
|
|
576
|
-
*/
|
|
577
|
-
readonly lib?: Schemes;
|
|
578
|
-
/**
|
|
579
|
-
* Os tipos **nominais** que um texto de tipo pode citar pelo nome: o nome e os type
|
|
580
|
-
* params de cada um. São os `interface` da lib (`Array`, `ReadonlyArray`, `Promise`)
|
|
581
|
-
* e os que o host declara (`Map`, `Element`…). Um nominal é o `apply` opaco (types
|
|
582
|
-
* TC2): o texto `Promise<User>` e o construtor `s.apply("Promise", [User])` são o
|
|
583
|
-
* mesmo tipo, e a aridade é cobrada como a de um alias.
|
|
584
|
-
*/
|
|
585
|
-
readonly nominals?: Nominals;
|
|
586
|
-
/**
|
|
587
|
-
* Os namespaces do ambiente (D83), lidos das chaves de `types` e `schemes`: um tipo com o
|
|
588
|
-
* nome qualificado (`state.Config`) é o membro `Config` do namespace `state`, como num
|
|
589
|
-
* `.d.ts` com `declare namespace state { … }`. Os corpos já chegam com os nomes
|
|
590
|
-
* resolvidos a partir do namespace de cada um — um `Config` no corpo de `state.Result` é
|
|
591
|
-
* o `state.Config` —, sem o host reescrever nada.
|
|
592
|
-
*/
|
|
593
|
-
readonly namespaces?: Namespaces;
|
|
594
|
-
/**
|
|
595
|
-
* Os erros do contrato que o host declarou (D93) — o equivalente dos erros de um `.d.ts`
|
|
596
|
-
* no tsc, que são do arquivo de declarações e não do programa que o usa. Achados uma vez,
|
|
597
|
-
* no `createEnv`; o `check` não os repete. Um nome que não resolve em lugar nenhum do
|
|
598
|
-
* ambiente é o `unknown-name` (TS2304), e vale o tipo-erro.
|
|
599
|
-
*/
|
|
600
|
-
readonly diagnostics?: readonly EnvDiagnostic[];
|
|
601
|
-
}
|
|
602
|
-
/**
|
|
603
|
-
* O que um `Env` tem além das variáveis. Cada campo espelha o de {@link Env}, e
|
|
604
|
-
* todos são opcionais.
|
|
605
|
-
*/
|
|
606
|
-
interface EnvOptions {
|
|
607
|
-
readonly types?: Readonly<Record<string, Schema>>;
|
|
608
|
-
readonly schemes?: Readonly<Record<string, TypeScheme>>;
|
|
609
|
-
readonly accessors?: Readonly<Record<string, Schema>>;
|
|
610
|
-
readonly asserters?: ReadonlySet<string>;
|
|
611
|
-
readonly matchers?: ReadonlySet<string>;
|
|
612
|
-
readonly modules?: Readonly<Record<string, Schema>>;
|
|
613
|
-
/** Os nominais do host, somados aos da lib (ver {@link Env.nominals}). */
|
|
614
|
-
readonly nominals?: Nominals;
|
|
615
|
-
/**
|
|
616
|
-
* Sem a lib padrão — nem os aliases, nem os nominais dela. É o `--noLib` do tsc: os
|
|
617
|
-
* nomes da lib passam a ser `unknown-name`, como lá.
|
|
618
|
-
*/
|
|
619
|
-
readonly noLib?: boolean;
|
|
620
|
-
}
|
|
621
|
-
/**
|
|
622
|
-
* Um catálogo (`Record<string, Schema>`) passado no lugar das opções é o erro que a
|
|
623
|
-
* forma antiga convida (`createEnv(vars, types)`), e o TypeScript o aceitaria em
|
|
624
|
-
* silêncio: um tipo com índice de string cabe num objeto de opções todas
|
|
625
|
-
* opcionais. Este tipo o recusa na compilação — `keyof` de um catálogo é `string`.
|
|
626
|
-
*/
|
|
627
|
-
type NoCatalog<O> = string extends keyof O ? never : unknown;
|
|
628
|
-
/**
|
|
629
|
-
* Cria um `Env`: as variáveis injetadas (a raiz da DI) e, por nome, o resto —
|
|
630
|
-
* tipos nomeados, type schemes, acessores, asserters, matchers, módulos.
|
|
631
|
-
* Capability é separada (passe um `profile` ao `check`).
|
|
632
|
-
*
|
|
633
|
-
* As opções são NOMEADAS porque a forma posicional já custou um defeito: uma
|
|
634
|
-
* chamada que parava no quarto argumento compilava, e o asserter (o quinto) ficava
|
|
635
|
-
* fora do ambiente — `parseAs` virava `unknown-name` só naquele lugar. Uma chave
|
|
636
|
-
* fora do vocabulário (um catálogo no lugar das opções, um `type` no lugar de
|
|
637
|
-
* `types`) é `invalid-env-options`, na montagem: o `Env` não nasce com uma metade
|
|
638
|
-
* calada.
|
|
639
|
-
*/
|
|
640
|
-
declare const createEnv: <O extends EnvOptions = EnvOptions>(vars?: Readonly<Record<string, Schema>>, options?: O & NoCatalog<O>) => Env;
|
|
641
|
-
/**
|
|
642
|
-
* Um `Schema` como se estivesse escrito DENTRO do namespace `namespace` do ambiente
|
|
643
|
-
* (`"state"`, `"app.router"`; `null` na raiz): os nomes dele resolvidos como os do `createEnv`
|
|
644
|
-
* — no namespace e nos de fora, depois entre os tipos do ambiente e da lib (D83, D93) —, com o
|
|
645
|
-
* nome qualificado no lugar. É o `getTypeFromTypeNode` do tsc, que resolve um tipo pelo
|
|
646
|
-
* contêiner em que ele está escrito; aqui o contêiner é dito, porque o `Schema` não tem
|
|
647
|
-
* posição. Serve ao host que monta tipos por código e os publica no namespace do dono.
|
|
648
|
-
*
|
|
649
|
-
* O que não resolve vale o tipo-erro, e volta em `diagnostics`, com o caminho a partir da raiz
|
|
650
|
-
* do `Schema`. Um namespace que o ambiente não declara resolve como o mais próximo de fora que
|
|
651
|
-
* ele declara. O mesmo `Schema` volta quando nada muda (os caches são por referência, TC17).
|
|
652
|
-
*/
|
|
653
|
-
declare function resolveTypeNamesIn(env: Env, namespace: string | null, type: Schema): {
|
|
654
|
-
readonly type: Schema;
|
|
655
|
-
readonly diagnostics: readonly EnvDiagnostic[];
|
|
656
|
-
};
|
|
657
|
-
/** Os erros que a MONTAGEM do ambiente lança (o `check` em si nunca lança — D2). */
|
|
658
|
-
type CheckerErrorCode = "invalid-env-options";
|
|
659
|
-
/** Resolve um tipo nomeado (`type User = …`) declarado no ambiente. */
|
|
660
|
-
declare const resolveNamed: (env: Env, name: string) => Schema | undefined;
|
|
661
|
-
/** Resolve um type scheme (`type Pair<A, B> = …`) declarado no ambiente. */
|
|
662
|
-
declare const resolveScheme: (env: Env, name: string) => TypeScheme | undefined;
|
|
663
|
-
|
|
664
|
-
/** Liga a análise de não-usados. Dois eixos independentes, como no tsc. */
|
|
665
|
-
interface UnusedOptions {
|
|
666
|
-
/** ≅ `noUnusedLocals`: `const` e `import` nunca lidos. */
|
|
667
|
-
readonly locals?: boolean;
|
|
668
|
-
/** ≅ `noUnusedParameters`: parâmetros de arrow nunca lidos. */
|
|
669
|
-
readonly parameters?: boolean;
|
|
670
|
-
}
|
|
671
|
-
/**
|
|
672
|
-
* Coleta os bindings declarados e nunca lidos, como diagnósticos `unused-name`
|
|
673
|
-
* (severidade **warning** — é aviso de higiene, não erro de tipo).
|
|
674
|
-
*
|
|
675
|
-
* **Fora de escopo, de propósito** (limitação declarada, nunca divergência —
|
|
676
|
-
* [[tslite-is-ts-subset]]):
|
|
677
|
-
*
|
|
678
|
-
* - **`type X = …` não-usado** (o TS6196 do tsc). Num TSLite, um alias de `.d.ts`
|
|
679
|
-
* é contrato ENTRE arquivos por construção — a gramática não tem `export type`
|
|
680
|
-
* (playground ARCHITECTURE §5), então "não usado neste arquivo" não significa
|
|
681
|
-
* não usado. Reportar daria falso-positivo em todo `.d.ts`.
|
|
682
|
-
* - **Write-only** (`let x = 1; x = 2` sem leitura — o `noUnusedLocals_writeOnly`
|
|
683
|
-
* do tsc). Aqui a atribuição conta como leitura, então reportamos MENOS.
|
|
684
|
-
* Mutação é capability gated (D9), então o caso é raro.
|
|
685
|
-
*
|
|
686
|
-
* **Diferença de MENSAGEM conhecida** (o comportamento bate; a apresentação não —
|
|
687
|
-
* mesmo precedente do D2/D18): o tsc agrupa (`All variables are unused` /
|
|
688
|
-
* `All destructured elements are unused`) quando TODOS os nomes de uma declaração
|
|
689
|
-
* caem. Aqui cada nome sai como um diagnóstico próprio, porque o consumidor é o
|
|
690
|
-
* editor: o fade precisa do range POR NOME, e um diagnóstico na lista inteira não
|
|
691
|
-
* apagaria os nomes individualmente.
|
|
692
|
-
*/
|
|
693
|
-
declare function collectUnused(root: BaseNode, opts: UnusedOptions): Diagnostic[];
|
|
694
|
-
|
|
695
|
-
/** O overlay de tipos: tipo + escopo de cada nó, por referência (ESTree não tem id). */
|
|
696
|
-
type TypeOverlay = WeakMap<BaseNode, {
|
|
697
|
-
readonly type: Schema;
|
|
698
|
-
readonly scope: Scope;
|
|
699
|
-
}>;
|
|
700
|
-
interface CheckResult {
|
|
701
|
-
/** Tipo do nó raiz. */
|
|
702
|
-
readonly type: Schema;
|
|
703
|
-
readonly overlay: TypeOverlay;
|
|
704
|
-
readonly diagnostics: readonly Diagnostic[];
|
|
705
|
-
/**
|
|
706
|
-
* Os tipos nomeados resolvíveis (`env.types` ∪ `env.schemes`), já unificados na
|
|
707
|
-
* forma de scheme. Publicado porque QUEM CONSULTA precisa dele: `discover`
|
|
708
|
-
* (completions, navegação de membro) só expande um `apply` se receber este
|
|
709
|
-
* catálogo. Sem publicar, cada consumidor re-derivaria a união — e derivações
|
|
710
|
-
* paralelas divergem. Num programa sem alias é o catálogo do `Env`, o mesmo objeto em
|
|
711
|
-
* toda checagem, e congelado (D87).
|
|
712
|
-
*/
|
|
713
|
-
readonly schemes: Schemes;
|
|
714
|
-
/**
|
|
715
|
-
* Os tipos NOMINAIS que um texto de tipo pode citar (`Promise`, `Array`, e os do
|
|
716
|
-
* host), com os type params de cada um — os que nenhum scheme sombreia. Publicado
|
|
717
|
-
* pela mesma razão dos `schemes`: é a outra metade do catálogo de nomes de tipo
|
|
718
|
-
* (D79).
|
|
719
|
-
*/
|
|
720
|
-
readonly nominals: Nominals;
|
|
721
|
-
}
|
|
722
|
-
/**
|
|
723
|
-
* Tipa `node` no ambiente `env` (a borda da DI: data, states, funções globais).
|
|
724
|
-
* Nunca lança; devolve o overlay e os diagnósticos coletados.
|
|
725
|
-
*/
|
|
726
|
-
/** Opções do `check`. */
|
|
727
|
-
interface CheckOptions {
|
|
728
|
-
/**
|
|
729
|
-
* Capability profile a enforçar. Quando dado, o `check` roda o guard de capability
|
|
730
|
-
* (`fromCapability`) além do type-checking e funde os diagnósticos (`node-not-allowed`).
|
|
731
|
-
* Sem ele, `check` faz **só type-checking** (sem opinar sobre capability).
|
|
732
|
-
*
|
|
733
|
-
* Capability **desinstala** features (o que pode existir em runtime — junto do
|
|
734
|
-
* interpret/codegen); é ortogonal aos `limits`/`resultType` abaixo, que **validam**.
|
|
735
|
-
*/
|
|
736
|
-
readonly profile?: CapabilityProfile;
|
|
737
|
-
/**
|
|
738
|
-
* Limites estruturais (anti-DoS) — validações do checker, cada uma opt-in.
|
|
739
|
-
* Reportam `too-deep`/`too-large`.
|
|
740
|
-
*/
|
|
741
|
-
readonly limits?: {
|
|
742
|
-
/** Profundidade total de aninhamento do AST (qualquer nó). */
|
|
743
|
-
readonly maxDepth?: number;
|
|
744
|
-
/** Número total de nós (custo/complexidade). */
|
|
745
|
-
readonly maxNodes?: number;
|
|
746
|
-
/** Argumentos por chamada. */
|
|
747
|
-
readonly maxArgs?: number;
|
|
748
|
-
/** Aninhamento de funções (função-dentro-de-função). */
|
|
749
|
-
readonly maxFunctionNesting?: number;
|
|
750
|
-
/** Aninhamento de chamadas (`f(g(h(x)))`). */
|
|
751
|
-
readonly maxCallNesting?: number;
|
|
752
|
-
/** Profundidade de cadeia de membros (`a.b.c.d`). */
|
|
753
|
-
readonly memberDepth?: number;
|
|
754
|
-
};
|
|
755
|
-
/**
|
|
756
|
-
* Contrato de tipo de retorno: o tipo da expressão-raiz deve ser atribuível a
|
|
757
|
-
* `resultType`. Reporta `wrong-result-type`. (Ex.: uma condition deve ser `boolean`.)
|
|
758
|
-
*/
|
|
759
|
-
readonly resultType?: Schema;
|
|
760
|
-
/**
|
|
761
|
-
* Análise de bindings declarados e nunca lidos (`unused-name`, **warning**).
|
|
762
|
-
* Opt-in e com dois eixos independentes, como o `noUnusedLocals` /
|
|
763
|
-
* `noUnusedParameters` do tsc. Ver [`unused`](./unused.ts) para as isenções.
|
|
764
|
-
*/
|
|
765
|
-
readonly unused?: UnusedOptions;
|
|
766
|
-
}
|
|
767
|
-
declare function check(node: Node, env: Env, opts?: CheckOptions): CheckResult;
|
|
768
|
-
/**
|
|
769
|
-
* Extrai o **tipo-superfície** de um módulo (o ".d.ts sem arquivo", o dual do import):
|
|
770
|
-
* roda o `check` e projeta os bindings de topo (`const`/`function`) num `object` Schema
|
|
771
|
-
* `{ nome: tipoInferido }`. É como o `tsc` faz o declaration emit — só que aqui o checker
|
|
772
|
-
* **já infere** os tipos (D5/D6 scope-flow), então é uma projeção do overlay, sem Babel
|
|
773
|
-
* nem serialização pra sintaxe. O resultado é exatamente o que outro módulo consome via
|
|
774
|
-
* `env.modules[especificador]` — os dois lados se fecham. (Filtragem por `export` explícito
|
|
775
|
-
* entra quando `export` for implementado; hoje projeta toda a superfície de topo — o caso
|
|
776
|
-
* "inferir o tipo de um algoritmo que não declarou tipos".)
|
|
777
|
-
*/
|
|
778
|
-
declare function extractModuleType(program: Node, env: Env, opts?: CheckOptions): {
|
|
779
|
-
type: ObjectSchema;
|
|
780
|
-
diagnostics: readonly Diagnostic[];
|
|
781
|
-
};
|
|
782
|
-
/**
|
|
783
|
-
* O DIFERENCIAL — `matchesProps(Component, payload)`: extrai as props do componente
|
|
784
|
-
* react-like (`(props) => Element`; agnóstico ao framework, `Element` é `apply` opaco)
|
|
785
|
-
* e verifica, em edit-time, se o `payload` (saída de um serviço de automação/nocode) é
|
|
786
|
-
* **compatível** com elas: `payload ≤ props`. Campos a MAIS no payload são OK (o
|
|
787
|
-
* componente usa um subconjunto); faltar prop obrigatória ou tipo-errado →
|
|
788
|
-
* `props-mismatch`. Retorna `boolean` (a resposta de runtime). Componente inválido
|
|
789
|
-
* (sem assinatura de função) → não checa.
|
|
790
|
-
*/
|
|
791
|
-
/**
|
|
792
|
-
* As props de um componente react-like (`(props) => Element`): a 1ª assinatura, 1º
|
|
793
|
-
* param. É o SSOT da extração — o `matchesProps` (D24, VALIDAÇÃO) e o
|
|
794
|
-
* `componentProps` (AUTORIA, o matchesProps invertido) consomem os dois. Devolve o
|
|
795
|
-
* tipo CRU do param (o `matchesProps` o passa pro `typeDiff`, que resolve).
|
|
796
|
-
*/
|
|
797
|
-
declare function componentPropsOf(componentType: Schema, schemes: Schemes): Schema | undefined;
|
|
798
|
-
/**
|
|
799
|
-
* As props do componente registrado como `name` no `env`, para AUTORIA — gerar um
|
|
800
|
-
* form (um campo por prop). É o `matchesProps` **INVERTIDO** (validação → autoria):
|
|
801
|
-
* lê o prop-schema em vez de casar um payload contra ele. Devolve o objeto de props
|
|
802
|
-
* JÁ RESOLVIDO (nome → forma), ou `undefined` se `name` não é `(props) => Element`.
|
|
803
|
-
*/
|
|
804
|
-
declare function componentProps(env: Env, name: string): Schema | undefined;
|
|
805
|
-
|
|
806
|
-
/** Contexto opcional de um guard — o que as regras type-aware leem do `check`. */
|
|
807
|
-
interface GuardContext {
|
|
808
|
-
readonly overlay?: TypeOverlay;
|
|
809
|
-
/** Os tipos nomeados do programa: sem eles, uma relação sobre `apply` não expande. */
|
|
810
|
-
readonly schemes?: Schemes;
|
|
811
|
-
}
|
|
812
|
-
/** Um guard: percorre `root` e devolve os diagnósticos que encontrar. */
|
|
813
|
-
type Guard = (root: BaseNode, ctx: GuardContext) => Diagnostic[];
|
|
814
|
-
/** Um profile é uma composição de guards. */
|
|
815
|
-
type Profile = readonly Guard[];
|
|
816
|
-
/** Roda um profile sobre `root`, concatenando todos os diagnósticos. */
|
|
817
|
-
declare function guard(root: BaseNode, profile: Profile, ctx?: GuardContext): Diagnostic[];
|
|
818
|
-
/** Os kinds que **definem** uma função. */
|
|
819
|
-
declare const FUNCTION_KINDS: readonly ["ArrowFunctionExpression", "FunctionExpression", "FunctionDeclaration"];
|
|
820
|
-
/**
|
|
821
|
-
* O guard de **capability**: percorre `root` e reporta `node-not-allowed` em todo
|
|
822
|
-
* nó proibido por `compiled` — via `nodeViolation`, a **fonte única** de gating
|
|
823
|
-
* compartilhada com o interpret e o codegen. É o que `fromCapability` monta (+ o
|
|
824
|
-
* host allowlist). Garante que os 3 consumidores concordam por construção.
|
|
825
|
-
*
|
|
826
|
-
* Cada nó vai com o pai: é ele que separa o `export` de um membro de namespace
|
|
827
|
-
* (a visibilidade, como o modificador do tsc) do `export` de módulo do teto
|
|
828
|
-
* (capability CP1).
|
|
829
|
-
*
|
|
830
|
-
* O profile diz o que um lugar da aplicação pode EXECUTAR, e o corpo de um namespace que não
|
|
831
|
-
* vira código não executa: o nó do namespace é gateado, e o corpo dele não
|
|
832
|
-
* (`bodyDoesNotRun`). Os guards de autoria de tipo, abaixo, julgam o texto escrito e descem
|
|
833
|
-
* nele.
|
|
834
|
-
*/
|
|
835
|
-
declare function capabilityNodes(compiled: CompiledProfile, severity?: Severity): Guard;
|
|
836
|
-
/**
|
|
837
|
-
* O callee de toda chamada deve ser um identificador direto ∈ `names`. É o gate
|
|
838
|
-
* do **host** (a família `host.allow` do `CapabilityProfile`): só as funções
|
|
839
|
-
* liberadas pela DI podem ser chamadas. Montado por `fromCapability`.
|
|
840
|
-
*/
|
|
841
|
-
declare function calleeAllowlist(names: readonly string[], severity?: Severity): Guard;
|
|
842
|
-
/**
|
|
843
|
-
* Limita o **aninhamento de um kind** ao longo de qualquer caminho raiz→folha.
|
|
844
|
-
* Ex.: `maxNestingOf(FUNCTION_KINDS, 3)` barra a 4ª função aninhada.
|
|
845
|
-
*/
|
|
846
|
-
declare function maxNestingOf(kinds: string | readonly string[], max: number, opts?: {
|
|
847
|
-
hint?: string;
|
|
848
|
-
severity?: Severity;
|
|
849
|
-
}): Guard;
|
|
850
|
-
/** Aninhamento de funções (função-dentro-de-função). Padrão: 3 → use um pipe. */
|
|
851
|
-
declare const maxFunctionNesting: (max?: number, severity?: Severity) => Guard;
|
|
852
|
-
/** Aninhamento de chamadas (`f(g(h(x)))`). */
|
|
853
|
-
declare const maxCallNesting: (max: number, severity?: Severity) => Guard;
|
|
854
|
-
/** Profundidade de cadeia de membros (`a.b.c.d`). */
|
|
855
|
-
declare const memberDepth: (max: number, severity?: Severity) => Guard;
|
|
856
|
-
/** Profundidade total de aninhamento do AST (qualquer nó). */
|
|
857
|
-
declare function maxDepth(max: number, severity?: Severity): Guard;
|
|
858
|
-
/** Número total de nós (custo/complexidade). */
|
|
859
|
-
declare function maxNodes(max: number, severity?: Severity): Guard;
|
|
860
|
-
/** Número máximo de argumentos por chamada. */
|
|
861
|
-
declare function maxArgs(max: number, severity?: Severity): Guard;
|
|
862
|
-
/** O tipo da expressão-raiz deve ser atribuível a `expected`. */
|
|
863
|
-
declare function resultType(expected: Schema, schemes?: Schemes, severity?: Severity): Guard;
|
|
864
|
-
|
|
865
|
-
/** Traduz um `CompiledProfile` (já compilado) num `Profile` de guards. */
|
|
866
|
-
declare function guardsFromCompiled(c: CompiledProfile): Profile;
|
|
867
|
-
/**
|
|
868
|
-
* Compila um `CapabilityProfile` e o traduz num `Profile` de guards. Use com
|
|
869
|
-
* `guard(ast, fromCapability(PRESETS.predicate))`. Assume um profile válido
|
|
870
|
-
* (rode `validateProfile` antes p/ pegar combinações ilegais).
|
|
871
|
-
*/
|
|
872
|
-
declare function fromCapability(profile: CapabilityProfile): Profile;
|
|
873
|
-
|
|
874
|
-
type BinaryOpCategory = "additive" | "arithmetic" | "bitwise" | "relational" | "equality";
|
|
875
|
-
/**
|
|
876
|
-
* O tipo que o operador PRODUZ — como marcador. `"additive"` é o `+` (condicional:
|
|
877
|
-
* `string`|`number`), resolvido no checker. Os demais mapeiam 1:1 num `Schema`.
|
|
878
|
-
*/
|
|
879
|
-
type OpResult = "number" | "boolean" | "string" | "additive";
|
|
880
|
-
interface BinaryOpSpec {
|
|
881
|
-
readonly op: types.BinaryOperator;
|
|
882
|
-
readonly category: BinaryOpCategory;
|
|
883
|
-
readonly result: OpResult;
|
|
884
|
-
}
|
|
885
|
-
/** O catálogo dos binários da Linguagem (o `in`/`instanceof` ficam fora: OO/nicho). */
|
|
886
|
-
declare const BINARY_OPS: readonly BinaryOpSpec[];
|
|
887
|
-
/** Lookup O(1) por operador. */
|
|
888
|
-
declare const BINARY_OP: ReadonlyMap<string, BinaryOpSpec>;
|
|
889
|
-
/** O `Schema` que o operador produz — o SSOT do tipo de retorno. `+` (additive) é
|
|
890
|
-
* condicional e NÃO tem schema fixo: quem chama trata (ver `binaryType` no checker). */
|
|
891
|
-
declare const opResultSchema: (r: Exclude<OpResult, "additive">) => Schema;
|
|
892
|
-
interface UnaryOpSpec {
|
|
893
|
-
readonly op: types.UnaryOperator;
|
|
894
|
-
/** O tipo ao qual o resultado é ASSIGNÁVEL (upper bound). O `unaryType` faz
|
|
895
|
-
* folding de literal (`-1`→`-1`, `!0`→`true`), então o real é um subtipo disto. */
|
|
896
|
-
readonly result: "number" | "boolean" | "string" | "undefined";
|
|
897
|
-
}
|
|
898
|
-
declare const UNARY_OPS: readonly UnaryOpSpec[];
|
|
899
|
-
interface LogicalOpSpec {
|
|
900
|
-
readonly op: types.LogicalOperator;
|
|
901
|
-
}
|
|
902
|
-
/** Os lógicos COMPÕEM o tipo dos operandos (`a && b` refina; não é tipo fixo) —
|
|
903
|
-
* por isso sem `result`. No slot, um lógico serve quando os operandos servem. */
|
|
904
|
-
declare const LOGICAL_OPS: readonly LogicalOpSpec[];
|
|
905
|
-
/**
|
|
906
|
-
* Os operadores BINÁRIOS cujo resultado é assignável a `target` — a base das
|
|
907
|
-
* sugestões de um slot. Num slot `boolean`: relacionais + igualdades. Num slot
|
|
908
|
-
* `number`: aritméticos/bitwise + `+`. O `+` (additive) serve a slot string OU
|
|
909
|
-
* number. `any`/`unknown` no `target` casa tudo (`subtype` já resolve).
|
|
910
|
-
*/
|
|
911
|
-
declare function binaryOpsProducing(target: Schema, schemes?: Schemes): readonly BinaryOpSpec[];
|
|
912
|
-
/** Os operadores UNÁRIOS cujo resultado (upper bound) é assignável a `target`. */
|
|
913
|
-
declare function unaryOpsProducing(target: Schema, schemes?: Schemes): readonly UnaryOpSpec[];
|
|
914
|
-
|
|
915
|
-
/**
|
|
916
|
-
* Diagnósticos de reatribuição de binding imutável (`const`, `import`).
|
|
917
|
-
*
|
|
918
|
-
* **Sempre roda** — não é opt-in nem gateado por capability, porque `const` é o
|
|
919
|
-
* piso da Linguagem (D9). Um profile que liga mutação libera `let`, não `const`.
|
|
920
|
-
*
|
|
921
|
-
* Roda **ANTES** do walk, e devolve também os alvos recusados: o walk pula a
|
|
922
|
-
* checagem de assignability neles, para não cascatear. É a ordem do tsc — *"to
|
|
923
|
-
* avoid cascading errors check assignability only if 'isReference' check succeeded
|
|
924
|
-
* and no errors were reported"* (`checker.ts:41076`). Sem isso `const c = 1; c = 2`
|
|
925
|
-
* reportaria DOIS erros, sendo que o segundo (`2 ⊄ 1`) é consequência do primeiro.
|
|
926
|
-
*/
|
|
927
|
-
declare function collectMutations(root: BaseNode): {
|
|
928
|
-
readonly diagnostics: readonly Diagnostic[];
|
|
929
|
-
readonly invalidTargets: WeakSet<BaseNode>;
|
|
930
|
-
};
|
|
931
|
-
|
|
932
|
-
/** Referência → o `Identifier` que a DECLARA. Por referência, como o overlay. */
|
|
933
|
-
type BindingMap = WeakMap<BaseNode, BaseNode>;
|
|
934
|
-
/**
|
|
935
|
-
* Mapeia cada REFERÊNCIA ao `Identifier` que a declara.
|
|
936
|
-
*
|
|
937
|
-
* É a base de "ir para a definição" (e, no futuro, rename / find-references).
|
|
938
|
-
* **Não** é chamado pelo `check`: é consulta de editor, e o checker roda
|
|
939
|
-
* por-keystroke — quem quer, paga.
|
|
940
|
-
*
|
|
941
|
-
* **Limites** (ambos por ausência de posição, não por preguiça):
|
|
942
|
-
* - **membro** (`obj.price`) não resolve: exigiria a origem do tipo, e `Schema`
|
|
943
|
-
* não carrega posição;
|
|
944
|
-
* - **nome de tipo em ANOTAÇÃO** (`r: RawViaCep`) não resolve: a anotação é
|
|
945
|
-
* `Schema` apagável, não nó (E6). O nome de um `type X = …` resolve.
|
|
946
|
-
*/
|
|
947
|
-
declare function collectBindings(root: BaseNode): BindingMap;
|
|
948
|
-
|
|
949
|
-
/** O que um nome denota. */
|
|
950
|
-
type ReferenceSymbol = {
|
|
951
|
-
readonly kind: "local";
|
|
952
|
-
/** O `Identifier` que declara — a identidade, por referência. */
|
|
953
|
-
readonly declaration: BaseNode;
|
|
954
|
-
} | {
|
|
955
|
-
readonly kind: "environment";
|
|
956
|
-
/** O caminho a partir da raiz da DI: `["params"]`, `["params", "id"]`. */
|
|
957
|
-
readonly path: readonly string[];
|
|
958
|
-
};
|
|
959
|
-
/**
|
|
960
|
-
* Onde o nome aparece como SHORTHAND, e portanto nomeia duas coisas ao mesmo tempo
|
|
961
|
-
* — o `prefixText`/`suffixText` do `findRenameLocations` do TypeScript:
|
|
962
|
-
*
|
|
963
|
-
* - `"property"`: o nome é o valor e também a PROPRIEDADE (`{ x }`, ou `const { x
|
|
964
|
-
* } = o` renomeando o `x` local). A propriedade continua com o nome antigo:
|
|
965
|
-
* `{ x: x2 }`;
|
|
966
|
-
* - `"binding"`: o nome é a propriedade e também um BINDING (`const { id } =
|
|
967
|
-
* params`, renomeando o `params.id`). O binding continua com o nome antigo:
|
|
968
|
-
* `{ id2: id }`;
|
|
969
|
-
* - `"import"`: o nome importado é também o local (`import { a } from "m"`,
|
|
970
|
-
* renomeando o local): `import { a as a2 }`.
|
|
971
|
-
*/
|
|
972
|
-
type Shorthand = "property" | "binding" | "import";
|
|
973
|
-
/** Uma referência a tipo nomeado escrita numa anotação (a `typeRefs` do parser). */
|
|
974
|
-
interface TypeRefSite {
|
|
975
|
-
readonly name: string;
|
|
976
|
-
readonly loc: SourceLocation;
|
|
977
|
-
}
|
|
978
|
-
/** Um lugar onde o nome aparece. */
|
|
979
|
-
type Occurrence = {
|
|
980
|
-
/** O nó cujo texto É o nome: `Identifier`, `JSXIdentifier` ou a chave literal. */
|
|
981
|
-
readonly site: "node";
|
|
982
|
-
readonly node: BaseNode;
|
|
983
|
-
readonly symbol: ReferenceSymbol;
|
|
984
|
-
/** A declaração do símbolo, e não um uso. */
|
|
985
|
-
readonly isDeclaration?: true;
|
|
986
|
-
readonly shorthand?: Shorthand;
|
|
987
|
-
} | {
|
|
988
|
-
/** Um segmento do `typeof a.b` numa anotação: o nó não tem posição por segmento. */
|
|
989
|
-
readonly site: "typeQuery";
|
|
990
|
-
readonly node: BaseNode;
|
|
991
|
-
readonly segment: number;
|
|
992
|
-
readonly symbol: ReferenceSymbol;
|
|
993
|
-
} | {
|
|
994
|
-
/** Um nome de tipo numa anotação, que não é nó (E6 do editor). */
|
|
995
|
-
readonly site: "typeRef";
|
|
996
|
-
readonly ref: TypeRefSite;
|
|
997
|
-
readonly symbol: ReferenceSymbol;
|
|
998
|
-
};
|
|
999
|
-
/** Os dois símbolos são o mesmo? */
|
|
1000
|
-
declare function sameSymbol(a: ReferenceSymbol, b: ReferenceSymbol): boolean;
|
|
1001
|
-
/**
|
|
1002
|
-
* Todas as ocorrências de nome do programa, cada uma com o símbolo que denota.
|
|
1003
|
-
*
|
|
1004
|
-
* Quem renomeia escolhe o símbolo sob o cursor (`occurrenceAt` do editor) e pega as
|
|
1005
|
-
* ocorrências com `sameSymbol`; quem renomeia um caminho do ambiente sem cursor (o
|
|
1006
|
-
* host que renomeou a declaração no `Env`) filtra pelo caminho direto.
|
|
1007
|
-
*/
|
|
1008
|
-
declare function collectReferences(root: BaseNode): readonly Occurrence[];
|
|
1009
|
-
|
|
1010
|
-
/** Anota uma ligação/parâmetro: `x` → `x: T`. */
|
|
1011
|
-
declare const annotate: <N extends BaseNode>(node: N, type: Schema) => N & {
|
|
1012
|
-
typeAnnotation: Schema;
|
|
1013
|
-
};
|
|
1014
|
-
/** Anota o retorno de uma função: `() => …` → `(): R => …`. */
|
|
1015
|
-
declare const annotateReturn: <N extends BaseNode>(fn: N, type: Schema) => N & {
|
|
1016
|
-
returnType: Schema;
|
|
1017
|
-
};
|
|
1018
|
-
/** Cast `x as T` — `{ expression, typeAnnotation }`; tipa a expressão, resulta `T`. */
|
|
1019
|
-
declare const asExpression: (expression: BaseNode, type: Schema) => BaseNode;
|
|
1020
|
-
|
|
1021
|
-
/** O tipo inferido de `node`, ou `undefined` se o nó não foi tipado. */
|
|
1022
|
-
declare function typeAt(overlay: TypeOverlay, node: BaseNode): Schema | undefined;
|
|
1023
|
-
/** O escopo léxico vigente em `node`, ou `undefined` se o nó não foi tipado. */
|
|
1024
|
-
declare function scopeAt(overlay: TypeOverlay, node: BaseNode): Scope | undefined;
|
|
1025
|
-
/**
|
|
1026
|
-
* Completions de **membro**: o que pode seguir a partir do tipo de `node`
|
|
1027
|
-
* (ex.: após `obj.` → as props de `obj`; após um array → `[]`). Vazio se o nó
|
|
1028
|
-
* não foi tipado ou se o tipo não tem membros navegáveis.
|
|
1029
|
-
*/
|
|
1030
|
-
declare function memberCompletions(overlay: TypeOverlay, node: BaseNode): readonly Completion[];
|
|
1031
|
-
/**
|
|
1032
|
-
* Completions de **escopo**: os nomes visíveis no contexto de `node` — params,
|
|
1033
|
-
* `const`s já declaradas acima e as raízes injetadas pela DI. É o que pode
|
|
1034
|
-
* preencher um slot de expressão livre nesse ponto. O mais interno sombreia o
|
|
1035
|
-
* externo. Vazio se o nó não foi tipado.
|
|
1036
|
-
*/
|
|
1037
|
-
declare function scopeCompletions(overlay: TypeOverlay, node: BaseNode): readonly Completion[];
|
|
1038
|
-
/**
|
|
1039
|
-
* O tipo CONTEXTUAL de `ancestors[i]` — o que o nó em torno espera ali.
|
|
1040
|
-
*
|
|
1041
|
-
* É o `getContextualType` do tsc: **computado sob demanda** a partir da cadeia de
|
|
1042
|
-
* ancestrais, não gravado no overlay. O overlay guarda o tipo RESULTANTE de cada
|
|
1043
|
-
* nó; o contextual é outra pergunta ("o que caberia aqui?"), e a resposta vive nas
|
|
1044
|
-
* anotações do pai — que o parser deixa no nó como `Schema` (`typeAnnotation`,
|
|
1045
|
-
* `returnType`).
|
|
1046
|
-
*
|
|
1047
|
-
* Mora no checker (e não no editor) porque é **semântica**: resolve anotação,
|
|
1048
|
-
* consulta o overlay e navega tipo nomeado. O editor faz posição→nó e pergunta.
|
|
1049
|
-
*
|
|
1050
|
-
* `ancestors` vem do mais interno para o mais externo (`ancestors[i+1]` é o pai de
|
|
1051
|
-
* `ancestors[i]`). Devolve `undefined` quando o contexto não determina um tipo —
|
|
1052
|
-
* e aí o consumidor não deve inventar.
|
|
1053
|
-
*/
|
|
1054
|
-
declare function contextualTypeAt(ancestors: readonly BaseNode[], i: number, overlay: TypeOverlay, schemes?: Schemes): Schema | undefined;
|
|
1055
|
-
/** Os diagnósticos que apontam para `node`. */
|
|
1056
|
-
declare function diagnosticsAt(diagnostics: readonly Diagnostic[], node: BaseNode): readonly Diagnostic[];
|
|
1057
|
-
|
|
1058
|
-
/** Nó → âncora do domínio. Identidade por referência; `A` é opaca. */
|
|
1059
|
-
interface Anchors<A> {
|
|
1060
|
-
/** Carimba o nó e o devolve — para carimbar na própria construção. */
|
|
1061
|
-
stamp<T extends object>(node: T, anchor: A): T;
|
|
1062
|
-
get(node: object): A | undefined;
|
|
1063
|
-
}
|
|
1064
|
-
declare function createAnchors<A>(): Anchors<A>;
|
|
1065
|
-
interface LowerValueOptions<A> {
|
|
1066
|
-
/** A âncora de um filho: chave de objeto ou índice de lista. */
|
|
1067
|
-
readonly child: (anchor: A, key: string | number) => A;
|
|
1068
|
-
/**
|
|
1069
|
-
* O nó de uma ilha. Padrão: `fromExprMarker`, carimbado com a âncora da
|
|
1070
|
-
* posição. Quem tem os nós em memória (com `loc` no texto do campo — os
|
|
1071
|
-
* `islands[].node` do `parseValue` do `@tslite/template`) os entrega aqui, e
|
|
1072
|
-
* o span de um erro dentro da ilha passa a existir.
|
|
1073
|
-
*/
|
|
1074
|
-
readonly island?: (marker: object, anchor: A) => Expression;
|
|
1075
|
-
}
|
|
1076
|
-
/**
|
|
1077
|
-
* Um valor JSON com ilhas → uma expressão de nós PRÓPRIOS, carimbados.
|
|
1078
|
-
*
|
|
1079
|
-
* Por que não entregar o `JsonExpression` ao checker: ele decodifica cada ilha
|
|
1080
|
-
* em nós novos para tipá-la, e um erro dentro da ilha aponta um nó que não é do
|
|
1081
|
-
* consumidor — o mapa não o conhece, e o diagnóstico cai no fallback. Baixando
|
|
1082
|
-
* aqui, o nó é seu, carimbável, e a subida pelos pais alcança.
|
|
1083
|
-
*
|
|
1084
|
-
* - objeto → `ObjectExpression`; a raiz leva `anchor`; cada chave (um
|
|
1085
|
-
* `Literal`, para representar qualquer chave JSON) e cada `Property` levam
|
|
1086
|
-
* `child(anchor, key)`, e o valor é baixado com a mesma âncora filha. Um
|
|
1087
|
-
* `not-assignable` do objeto inteiro pousa no objeto; um `excess-property`
|
|
1088
|
-
* pousa na chave;
|
|
1089
|
-
* - array → `ArrayExpression`, com `child(anchor, i)` por elemento;
|
|
1090
|
-
* - ilha → `island(marker, anchor)`;
|
|
1091
|
-
* - primitivo → `Literal`.
|
|
1092
|
-
*/
|
|
1093
|
-
declare function lowerValue<A>(value: unknown, anchor: A, anchors: Anchors<A>, opts: LowerValueOptions<A>): Expression;
|
|
1094
|
-
interface AnchoredDiagnostic<A> {
|
|
1095
|
-
/** O diagnóstico do checker, com `node` e `data` — intacto. */
|
|
1096
|
-
readonly diagnostic: Diagnostic;
|
|
1097
|
-
readonly anchor: A;
|
|
1098
|
-
/** Offsets no texto da âncora, quando há texto e o nó tem `loc`. */
|
|
1099
|
-
readonly span?: Span;
|
|
1100
|
-
}
|
|
1101
|
-
interface AnchorDiagnosticsOptions<A> {
|
|
1102
|
-
/** A âncora de quem nada responde. Um diagnóstico sem âncora some. */
|
|
1103
|
-
readonly fallback: A;
|
|
1104
|
-
/** O texto em que a âncora mora — o do campo. Sem ele, não há span. */
|
|
1105
|
-
readonly textOf?: (anchor: A) => string | undefined;
|
|
1106
|
-
}
|
|
1107
|
-
/**
|
|
1108
|
-
* Cada diagnóstico, levado à âncora do nó acusado ou do primeiro pai carimbado.
|
|
1109
|
-
*
|
|
1110
|
-
* A subida existe por correção, não por economia: o checker ancora um erro no nó
|
|
1111
|
-
* mais preciso que tem — o literal de uma chave, o argumento de uma chamada —, e
|
|
1112
|
-
* nem todo nó precisa ter sido carimbado (um sub-nó que um builder gerou, um
|
|
1113
|
-
* nó sintético). Sem nenhum carimbo no caminho, vale o `fallback`.
|
|
1114
|
-
*
|
|
1115
|
-
* O `data` do diagnóstico atravessa intacto: é dele que o quick-fix de
|
|
1116
|
-
* propriedade faltante vive. O span sai do `loc` do nó acusado, convertido no
|
|
1117
|
-
* texto da âncora (`textOf`); sem texto ou sem `loc`, não há span — inventar um
|
|
1118
|
-
* seria pior que não ter.
|
|
1119
|
-
*/
|
|
1120
|
-
declare function anchorDiagnostics<A>(root: object, diagnostics: readonly Diagnostic[], anchors: Anchors<A>, opts: AnchorDiagnosticsOptions<A>): AnchoredDiagnostic<A>[];
|
|
1121
|
-
/**
|
|
1122
|
-
* `loc` do AST → offsets num texto.
|
|
1123
|
-
*
|
|
1124
|
-
* `loc` ausente → sem span (um nó construído por builder não tem posição, e
|
|
1125
|
-
* inventar uma seria pior que não ter); `end` ausente → span de tamanho zero no
|
|
1126
|
-
* início; posição fora do texto é presa ao tamanho do texto, e o fim nunca fica
|
|
1127
|
-
* antes do início. Para converter muitos `loc` sobre o mesmo texto, use
|
|
1128
|
-
* `anchorDiagnostics`, que constrói o mapa de posições uma vez por texto.
|
|
1129
|
-
*/
|
|
1130
|
-
declare function spanOf(text: string, loc: SourceLocation | null | undefined): Span | undefined;
|
|
1131
|
-
|
|
1132
|
-
export { type AnchorDiagnosticsOptions, type AnchoredDiagnostic, type Anchors, BINARY_OP, BINARY_OPS, type BinaryOpCategory, type BinaryOpSpec, type BindingMap, type CheckOptions, type CheckResult, type CheckerErrorCode, Completion, type Diagnostic, type DiagnosticCode, type DiagnosticData, type DiagnosticKind, type DiagnosticRelatedInformation, type DiagnosticSink, type Env, type EnvDiagnostic, type EnvOptions, FUNCTION_KINDS, type Guard, type GuardContext, LOGICAL_OPS, type LogicalOpSpec, type LowerValueOptions, type MissingProperty, type Nominals, ObjectSchema, type Occurrence, type OpResult, type Profile, type ReferenceSymbol, Schema, Schemes, type Scope, type Severity, type Shorthand, type TypeOverlay, type TypeRefSite, TypeScheme, UNARY_OPS, type UnaryOpSpec, type UnusedOptions, VarSchema, anchorDiagnostics, annotate, annotateReturn, asExpression, binaryOpsProducing, calleeAllowlist, capabilityNodes, check, childScope, collectBindings, collectMutations, collectReferences, collectUnused, componentProps, componentPropsOf, contextualTypeAt, createAnchors, createEnv, createSink, diag, diagnosticsAt, extractModuleType, fromCapability, guard, guardsFromCompiled, lookup, lowerValue, makeDiagnostic, maxArgs, maxCallNesting, maxDepth, maxFunctionNesting, maxNestingOf, maxNodes, memberCompletions, memberDepth, opResultSchema, resolveNamed, resolveScheme, resolveTypeNamesIn, resolvesToEnvironment, resultType, rootScope, sameSymbol, scopeAt, scopeCompletions, spanOf, typeAt, unaryOpsProducing, visibleNames };
|