- Add a better class comment.
- Remove the obsolete `type_ids_for_type_constants_` and `TypeNode`.
- For `bind_name_map`, fix declaration order and move comment to be
consistent with other members.
- Reorder accessors to better match order of data members.
- This is how I noticed `type_ids_for_type_constants_`
- Put a bigger notice so that `sem_ir` helper functions don't end up in
the middle of other members again.
Small cleanup for code sharing. Note, `*ReadFile` will trigger a
CHECK-failure on error; the relevant implementations would previously
have failed silently (empty string).
---------
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
Without this, diagnostics will linger after closing a file.
This refactors towards a pattern of putting outgoing calls as methods on
`Context`. I'm mixed on this, mainly thinking it's an improvement on
using `outgoing` directly (because it shares the name and structure),
might want to move it to a side-class later that is _only_ LSP wrappers.
I could also make inheritance private on OutgoingMessages and these
kinds of methods public there, but I'm hesitant to adopt that approach
versus a type separation.
Cycles are defined as reaching two independent lookups in a chain that
have all the same types involved. The acyclic rule states that this is
not possible and results in an error:
https://docs.carbon-lang.dev/docs/design/generics/details.html#acyclic-rule
To do this we need to track the types involved in impl lookup. The
interface constant includes the whole facet type being looked up, which
includes any specific types for generics or where constraints. Thus we
just need to compare the constant ids to look for this condition.
---------
Co-authored-by: josh11b <15258583+josh11b@users.noreply.github.com>
Currently it returns false which just ends typechecking. Instead handle
the error state later and avoid firing overlapping diagnostics in
'extend impl as'.
---------
Co-authored-by: josh11b <15258583+josh11b@users.noreply.github.com>
This in particular uses free functions because it's likely to end up
more consistent with types (versus a wrapper object for InstStore).
Note, this is unlikely to have a performance impact, but if it does, we
can look into related approaches (and we've already discussed using
LTO).
Renames `PendingBlock::AddInst` to `PendingBlock::Add` because
`MakeElementAccessInst` expects the matching name to exist.
When I open a .def file, there are often 4 errors:
- The #error
- The #define is not defined
- Missing `;`
- Identifier naming
This PR is meant to disable all of these, since they can be distracting
from fixable diagnostics.
rules_cc@0.1.0 was yanked from
[BCR](https://registry.bazel.build/modules/rules_cc) due to prematurely
removing cc_proto_library, this inconsistently causes the following
build error:
> ERROR: Error computing the main repository mapping: Yanked version
detected in your resolved dependency graph: rules_cc@0.1.0, for the
reason: rules_cc 0.1.0 is yanked due to incompatible change (prematurely
removing cc_proto_library from defs.bzl), please upgrade to 0.1.1.
Yanked versions may contain serious vulnerabilities and should not be
used. To fix this, use a bazel_dep on a newer version of this module. To
continue using this version, allow it using the --allow_yanked_versions
flag or the BZLMOD_ALLOW_YANKED_VERSIONS env variable.
This PR updates to 0.1.1 as recomended in warning and
[bazelbuild/rules_cc#268](https://github.com/bazelbuild/rules_cc/issues/268#issuecomment-2651269117).
This creates a new check/type.h for most logic, and also moves some
functions to TypeStore in sem_ir/type.h. My approach for TypeStore is to
focus on moving the read-only functions there.
This ensures the data is available for more uses (specifically for
diagnosing virtual/abstract/impl functions on non-instance methods).
It still doesn't quite address the TODO to move the Self param search
all the way back to the param walk in all cases. To do that in the case
that still has a separate search loop, I think we'd have to change
`Check::NameComponent` to carry this information (as it carries the
implicit_param_patterns-id) - though there's comments in NameComponent
suggesting it shouldn't carry function-specific things like
`call_params_id` and `return_slot_pattern_id` - so I wasn't sure if it
was suitable to add more there, but I can - possibly in a follow-up
change.
---------
Co-authored-by: Jon Ross-Perkins <jperkins@google.com>
Change parse tree from `template (T:! type)` to `(template T):! type`,
so that we have information about whether a binding is a template
binding available when forming the representation of the binding
pattern. This incidentally fixes a bug that we would accept `template
addr A:! B` instead of the intended `addr template A:! B`.
Track whether a symbolic binding is a template binding on the
`EntityName` object. I'm borrowing a bit from the `CompileTimeBindIndex`
for this in order to avoid making `EntityName`s larger. Longer-term, we
should think about using a different representation for symbolic
bindings, to avoid including these fields in all `EntityName`s, but
that's out of scope for this change.
So far, template bindings are treated as having the same phase as
checked bindings, but that will change in a future PR.
To do this, we restructure the parse tree to make `forall` a leaf node
that comes before the parameter list.
---------
Co-authored-by: Jon Ross-Perkins <jperkins@google.com>
The explorer interpreter is still there, but it's non-default so it's a
little hard to link to (we could do a shortlink like
https://carbon.compiler-explorer.com/z/8P1WE97nn if you want to keep
that). As is, I assume it's okay to just state that this is now the
toolchain.
This adds a `SemIR::File` pointer to `scope_stack` so that
`GetCurrentScopeAs` doesn't require the argument, which would be why the
helper existed on `context`.
Note this mirrors parse_tree().packaging_decl().is_impl, but I'm
preferring to keep the version that doesn't access the parse tree so
that we could change tree storage without hurting as much.
Note this is building on #4927 which factors out RegionStack, because
this heavily uses the region stack. However, it's a more complex level
of logic that appears specific to pattern handling.
I've moved InsertHere to pattern_match.cpp because it appears to be in
specific use there.
If 'extend impl' is invalid, mark the impl as invalid by putting an
ErrorInst in the witness_id field.
The construction of the witness_id can otherwise return an ErrorInst but
impl lookup was not checking for that. Now have impl lookup check for an
error there before attempting to deduce generic parameters, which avoids
infinite recursion through deduction in cases like a cyclical impl of
itself.
Adds a testcase for infinite impl-of-itself lookup found by fuzzer.
The GetTypeIdForTypeConstant() and GetTypeIdForTypeInst() methods
convert from a type value to the type id of that value. The comments say
it can only be done for values of type `type` but it can be done for any
type value, which are either `TypeType` (aka `type`) or `FacetType`.
For example, for a `FacetValue` instruction as follows:
```
inst116: {kind: FacetValue, arg0: inst46, arg1: inst59, type: type(inst52)}
- type type(inst52): Generic(GenericParam); {kind: FacetType, arg0: facet_type2, type: type(TypeType)}
- value template_constant(inst117): {kind: FacetValue, arg0: inst46, arg1: inst59, type: type(inst52)}
```
The GetTypeIdForTypeInst() method will give the type id of the type
value (the type _in_ the FacetValue instruction) such as:
```
type(inst117): ImplsGeneric as Generic(GenericParam); {kind: FacetValue, arg0: inst46, arg1: inst59, type: type(inst52)}
```
---------
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
When attempting to convert to a value of type FacetType, and the source
value is a FacetAccessType, then if the type of the underlying
FacetValue is the same as the target, we can use the FacetValue there as
the conversion output.
If the type of the FacetValue differs, then we still want to do impl
lookup with the FacetValue to see if it matches with the target
FacetType, but that is still a TODO.
This allows a generic function with a value whose type is constrained by
a FacetType (thus the value's type is a FacetAccessType), to call other
functions with the value as an argument when it is constrained by the
same FacetType:
```
fn F[T:! FacetType](x: T);
fn G[T:! FacetType](x: T) { F(x); }
```
It is also an optimization to avoid impl lookup where we've already done
it to produce the FacetAccessType.
Adds a bunch of new tests with values of types which are constrained by
a facet type (or "facet value value" for short), with some more tests
that currently fail and should be made to pass.
We propose updating our milestones to accelerate design and
implementation of
memory safety in Carbon, and a roadmap for 2025 reflecting this change.
We also
provide a retrospective for 2024's progress.
---------
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
This PR updates the HandleDocumentSymbol function to build a tree of
symbols, rather than a flat list. Symbols found while traversing another
symbols body are added as a child.
Adds a simple test showing functions within nested class.
---------
Co-authored-by: David Blaikie <dblaikie@gmail.com>
context.cpp is getting large, so I'm looking at a few ways to cut out
clusters of functions. This felt like a logical cluster of functions to
move to their own file.
Note this doesn't touch the implementation at all, beyond what's needed
to change from `Context` members to context args.
Change representation of package names from `IdentifierId` to
`PackageNameId`, and add a special value `PackageNameId::Core` for the
Core package. Add a `Core` expression to name the Core package, and
support for parsing the `Core` keyword in `package` and `import`
declarations.
For now, I've made no changes to instruction fingerprinting or name
mangling. This means that fingerprints and mangled names will collide
between names in the `Core` package and names in a `r#Core` package. See
#4908.
---------
Co-authored-by: Jon Ross-Perkins <jperkins@google.com>
BuildValueRepr is used to determine the value representation of a type,
but the instruction determining the type may be an indirection through
to another instruction, such as a TupleAccess with `T.0` or a
StructAccess with `T.f`. In these cases, step through the indirection
and try again on the resulting type.
This eliminates a crash as these Access instructions do not resolve to a
type themselves and would otherwise end up in this FATAL line:
```
CARBON_FATAL("Type refers to non-type inst {0}", inst);
```
While here, remove the reference to TupleIndex in typed_insts.h as it
has been subsumed by TupleAccess in 7f930d0f58.
ClassElementAccess is not yet handled, but a fail_todo test is added. It
fails because `ConvertToValueOfType()` in `ExprAsType()` returns a
non-constant value for a ClassElementAccess instruction, where it must
not for a StructAccess.
context.cpp is getting large, so I'm looking at a few ways to cut out
clusters of functions. This felt like a logical cluster of functions to
move to their own file.
Note I have two commits in this PR: one moving the functionality to a
new file, and one specifically changing TypeCompleter to use out-of-line
function implementations. This is to assist reviewability.
Also makes the style guide explicitly comment on void, but this was the
intent IIRC because it matches Carbon's `-> ()` (and "always" versus
"except for void", which we definitely went back and forth on).
Includes adjusting function pointers, which I definitely forget this
syntax works sometimes.
Excludes utils/tree_sitter/src/scanner.c because it claims to be C, but
really we should probably fix that to be cpp.
The fn receiving a facet type needs to deduce a type from a
FacetAccessType, which is the SemIR type representing the parameter type
that is a generic parameter. For example:
```
fn F[T: Interface](val: T);
```
Here T is a generic parameter that is a facet value, but the `val`
parameter's type is the facet value converted from a FacetType to a
TypeType, with `as type`. The result of that conversion is a
FacetAccessType. So the deduction code sees a FacetAccessType for the
type of `val`.
We make deduction undo the `as type` conversion to move back to the `T`
parameter declaration, which has type FacetType in order to deduce the
required facet value (which is itself a type constrained by the
FacetType). And when we have a facet value (of type FacetType) to be
deduced, we will also convert the argument if it is of an appropriate
type to a FacetValue that matches the FacetType using the changes from
PR #4863.
Tests with `impl forall` can cause impl deduction to recurse forever and
crash, so those tests are omitted in this PR and they will come in
follow-up work that address the infinite recursion.
Rebased on top of PR #4885
Bumps the npm_and_yarn group with 1 update in the /utils/vscode
directory: [esbuild](https://github.com/evanw/esbuild).
Updates `esbuild` from 0.24.0 to 0.25.0
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/evanw/esbuild/releases">esbuild's
releases</a>.</em></p>
<blockquote>
<h2>v0.25.0</h2>
<p><strong>This release deliberately contains backwards-incompatible
changes.</strong> To avoid automatically picking up releases like this,
you should either be pinning the exact version of <code>esbuild</code>
in your <code>package.json</code> file (recommended) or be using a
version range syntax that only accepts patch upgrades such as
<code>^0.24.0</code> or <code>~0.24.0</code>. See npm's documentation
about <a
href="https://docs.npmjs.com/cli/v6/using-npm/semver/">semver</a> for
more information.</p>
<ul>
<li>
<p>Restrict access to esbuild's development server (<a
href="https://github.com/evanw/esbuild/security/advisories/GHSA-67mh-4wv8-2f99">GHSA-67mh-4wv8-2f99</a>)</p>
<p>This change addresses esbuild's first security vulnerability report.
Previously esbuild set the <code>Access-Control-Allow-Origin</code>
header to <code>*</code> to allow esbuild's development server to be
flexible in how it's used for development. However, this allows the
websites you visit to make HTTP requests to esbuild's local development
server, which gives read-only access to your source code if the website
were to fetch your source code's specific URL. You can read more
information in <a
href="https://github.com/evanw/esbuild/security/advisories/GHSA-67mh-4wv8-2f99">the
report</a>.</p>
<p>Starting with this release, <a
href="https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS">CORS</a>
will now be disabled, and requests will now be denied if the host does
not match the one provided to <code>--serve=</code>. The default host is
<code>0.0.0.0</code>, which refers to all of the IP addresses that
represent the local machine (e.g. both <code>127.0.0.1</code> and
<code>192.168.0.1</code>). If you want to customize anything about
esbuild's development server, you can <a
href="https://esbuild.github.io/api/#serve-proxy">put a proxy in front
of esbuild</a> and modify the incoming and/or outgoing requests.</p>
<p>In addition, the <code>serve()</code> API call has been changed to
return an array of <code>hosts</code> instead of a single
<code>host</code> string. This makes it possible to determine all of the
hosts that esbuild's development server will accept.</p>
<p>Thanks to <a
href="https://github.com/sapphi-red"><code>@sapphi-red</code></a> for
reporting this issue.</p>
</li>
<li>
<p>Delete output files when a build fails in watch mode (<a
href="https://redirect.github.com/evanw/esbuild/issues/3643">#3643</a>)</p>
<p>It has been requested for esbuild to delete files when a build fails
in watch mode. Previously esbuild left the old files in place, which
could cause people to not immediately realize that the most recent build
failed. With this release, esbuild will now delete all output files if a
rebuild fails. Fixing the build error and triggering another rebuild
will restore all output files again.</p>
</li>
<li>
<p>Fix correctness issues with the CSS nesting transform (<a
href="https://redirect.github.com/evanw/esbuild/issues/3620">#3620</a>,
<a
href="https://redirect.github.com/evanw/esbuild/issues/3877">#3877</a>,
<a
href="https://redirect.github.com/evanw/esbuild/issues/3933">#3933</a>,
<a
href="https://redirect.github.com/evanw/esbuild/issues/3997">#3997</a>,
<a
href="https://redirect.github.com/evanw/esbuild/issues/4005">#4005</a>,
<a href="https://redirect.github.com/evanw/esbuild/pull/4037">#4037</a>,
<a
href="https://redirect.github.com/evanw/esbuild/pull/4038">#4038</a>)</p>
<p>This release fixes the following problems:</p>
<ul>
<li>
<p>Naive expansion of CSS nesting can result in an exponential blow-up
of generated CSS if each nesting level has multiple selectors.
Previously esbuild sometimes collapsed individual nesting levels using
<code>:is()</code> to limit expansion. However, this collapsing wasn't
correct in some cases, so it has been removed to fix correctness
issues.</p>
<pre lang="css"><code>/* Original code */
.parent {
> .a,
> .b1 > .b2 {
color: red;
}
}
<p>/* Old output (with --supported:nesting=false) */<br />
.parent > :is(.a, .b1 > .b2) {<br />
color: red;<br />
}</p>
<p>/* New output (with --supported:nesting=false) */<br />
.parent > .a,<br />
.parent > .b1 > .b2 {<br />
color: red;<br />
}<br />
</code></pre></p>
<p>Thanks to <a
href="https://github.com/tim-we"><code>@tim-we</code></a> for working
on a fix.</p>
</li>
<li>
<p>The <code>&</code> CSS nesting selector can be repeated multiple
times to increase CSS specificity. Previously esbuild ignored this
possibility and incorrectly considered <code>&&</code> to have
the same specificity as <code>&</code>. With this release, this
should now work correctly:</p>
<pre lang="css"><code>/* Original code (color should be red) */
</code></pre>
</li>
</ul>
</li>
</ul>
<!-- raw HTML omitted -->
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/evanw/esbuild/blob/main/CHANGELOG-2024.md">esbuild's
changelog</a>.</em></p>
<blockquote>
<h1>Changelog: 2024</h1>
<p>This changelog documents all esbuild versions published in the year
2024 (versions 0.19.12 through 0.24.2).</p>
<h2>0.24.2</h2>
<ul>
<li>
<p>Fix regression with <code>--define</code> and
<code>import.meta</code> (<a
href="https://redirect.github.com/evanw/esbuild/issues/4010">#4010</a>,
<a
href="https://redirect.github.com/evanw/esbuild/issues/4012">#4012</a>,
<a
href="https://redirect.github.com/evanw/esbuild/pull/4013">#4013</a>)</p>
<p>The previous change in version 0.24.1 to use a more expression-like
parser for <code>define</code> values to allow quoted property names
introduced a regression that removed the ability to use
<code>--define:import.meta=...</code>. Even though <code>import</code>
is normally a keyword that can't be used as an identifier, ES modules
special-case the <code>import.meta</code> expression to behave like an
identifier anyway. This change fixes the regression.</p>
<p>This fix was contributed by <a
href="https://github.com/sapphi-red"><code>@sapphi-red</code></a>.</p>
</li>
</ul>
<h2>0.24.1</h2>
<ul>
<li>
<p>Allow <code>es2024</code> as a target in <code>tsconfig.json</code>
(<a
href="https://redirect.github.com/evanw/esbuild/issues/4004">#4004</a>)</p>
<p>TypeScript recently <a
href="https://devblogs.microsoft.com/typescript/announcing-typescript-5-7/#support-for---target-es2024-and---lib-es2024">added
<code>es2024</code></a> as a compilation target, so esbuild now supports
this in the <code>target</code> field of <code>tsconfig.json</code>
files, such as in the following configuration file:</p>
<pre lang="json"><code>{
"compilerOptions": {
"target": "ES2024"
}
}
</code></pre>
<p>As a reminder, the only thing that esbuild uses this field for is
determining whether or not to use legacy TypeScript behavior for class
fields. You can read more in <a
href="https://esbuild.github.io/content-types/#tsconfig-json">the
documentation</a>.</p>
<p>This fix was contributed by <a
href="https://github.com/billyjanitsch"><code>@billyjanitsch</code></a>.</p>
</li>
<li>
<p>Allow automatic semicolon insertion after
<code>get</code>/<code>set</code></p>
<p>This change fixes a grammar bug in the parser that incorrectly
treated the following code as a syntax error:</p>
<pre lang="ts"><code>class Foo {
get
*x() {}
set
*y() {}
}
</code></pre>
<p>The above code will be considered valid starting with this release.
This change to esbuild follows a <a
href="https://redirect.github.com/microsoft/TypeScript/pull/60225">similar
change to TypeScript</a> which will allow this syntax starting with
TypeScript 5.7.</p>
</li>
<li>
<p>Allow quoted property names in <code>--define</code> and
<code>--pure</code> (<a
href="https://redirect.github.com/evanw/esbuild/issues/4008">#4008</a>)</p>
<p>The <code>define</code> and <code>pure</code> API options now accept
identifier expressions containing quoted property names. Previously all
identifiers in the identifier expression had to be bare identifiers.
This change now makes <code>--define</code> and <code>--pure</code>
consistent with <code>--global-name</code>, which already supported
quoted property names. For example, the following is now possible:</p>
<pre lang="js"><code></code></pre>
</li>
</ul>
<!-- raw HTML omitted -->
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="https://github.com/evanw/esbuild/commit/e9174d671b1882758cd32ac5e146200f5bee3e45"><code>e9174d6</code></a>
publish 0.25.0 to npm</li>
<li><a
href="https://github.com/evanw/esbuild/commit/c27dbebb9e7a55dd9a084dd151dddd840787490e"><code>c27dbeb</code></a>
fix <code>hosts</code> in <code>plugin-tests.js</code></li>
<li><a
href="https://github.com/evanw/esbuild/commit/6794f602a453cf0255bcae245871de120a89a559"><code>6794f60</code></a>
fix <code>hosts</code> in <code>node-unref-tests.js</code></li>
<li><a
href="https://github.com/evanw/esbuild/commit/de85afd65edec9ebc44a11e245fd9e9a2e99760d"><code>de85afd</code></a>
Merge commit from fork</li>
<li><a
href="https://github.com/evanw/esbuild/commit/da1de1bf77a65f06654b49878d9ec4747ddaa21f"><code>da1de1b</code></a>
fix <a
href="https://redirect.github.com/evanw/esbuild/issues/4065">#4065</a>:
bitwise operators can return bigints</li>
<li><a
href="https://github.com/evanw/esbuild/commit/f4e9d19fb20095a98bf40634f0380f6a16be91e7"><code>f4e9d19</code></a>
switch case liveness: <code>default</code> is always last</li>
<li><a
href="https://github.com/evanw/esbuild/commit/7aa47c3e778ea04849f97f18dd9959df88fa0886"><code>7aa47c3</code></a>
fix <a
href="https://redirect.github.com/evanw/esbuild/issues/4028">#4028</a>:
minify live/dead <code>switch</code> cases better</li>
<li><a
href="https://github.com/evanw/esbuild/commit/22ecd306190b8971ec4474b5485266c20350e266"><code>22ecd30</code></a>
minify: more constant folding for strict equality</li>
<li><a
href="https://github.com/evanw/esbuild/commit/4cdf03c03697128044fa8fb76e5c478e9765b353"><code>4cdf03c</code></a>
fix <a
href="https://redirect.github.com/evanw/esbuild/issues/4053">#4053</a>:
reordering of <code>.tsx</code> in <code>node_modules</code></li>
<li><a
href="https://github.com/evanw/esbuild/commit/dc719775b7140120916bd9e6777ca1cb8a1cdc0e"><code>dc71977</code></a>
fix <a
href="https://redirect.github.com/evanw/esbuild/issues/3692">#3692</a>:
<code>0</code> now picks a random ephemeral port</li>
<li>Additional commits viewable in <a
href="https://github.com/evanw/esbuild/compare/v0.24.0...v0.25.0">compare
view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore <dependency name> major version` will close this
group update PR and stop Dependabot creating any more for the specific
dependency's major version (unless you unignore this specific
dependency's major version or upgrade to it yourself)
- `@dependabot ignore <dependency name> minor version` will close this
group update PR and stop Dependabot creating any more for the specific
dependency's minor version (unless you unignore this specific
dependency's minor version or upgrade to it yourself)
- `@dependabot ignore <dependency name>` will close this group update PR
and stop Dependabot creating any more for the specific dependency
(unless you unignore this specific dependency or upgrade to it yourself)
- `@dependabot unignore <dependency name>` will remove all of the ignore
conditions of the specified dependency
- `@dependabot unignore <dependency name> <ignore condition>` will
remove the ignore condition of the specified dependency and ignore
conditions
You can disable automated security fix PRs for this repo from the
[Security Alerts
page](https://github.com/carbon-language/carbon-lang/network/alerts).
</details>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
This PR updates the construction of clang::clangd::DocumentSymbol to
produce "range" and "selectionRange" properties that match the
[textDocument/documentSymbol](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#textDocument_documentSymbol)
spec.
"selectionRange" is constructed by finding start and end position of the
symbols identifier.
"range" property is constructed by finding the left most and right most
token of the AST, the code makes an assumption that left most token is
always the first node in postorder traversal from that node, and the
right most is the node itself. AFAIK this is true for most of the
grammar other than infix operators. For symbols with a body, the right
most token is the open bracket, so we extend the range to its matching
closing bracket.
Jon Ross-Perkins
Dana Jansensandjosh11b
Boaz Brickner
DavidLoftus
David BlaikieandJon Ross-Perkins
Geoff RomerandJon Ross-Perkins
czapiga
Chandler CarruthandRichard Smith
dependabot[bot]