:smaug has a use case that currently involves doing (what ends up being) a [text search on `nsCOMPtr<nsILoadInfo> m`](https://searchfox.org/mozilla-central/search?q=nsCOMPtr%3CnsILoadInfo%3E+m&path=&case=false®exp=false). This hinges on the naming convention of prefixing member fields with `m`. We briefly discussed this in channel and tentatively it seems like the UX flow people would expect would be to first start with locating the type `nsILoadInfo` and then refining from there. ## Data ### Data we currently have Currently, for [this matching definition line](https://searchfox.org/mozilla-central/rev/79f93e7a8b9aa1903f1349f2dd46fb71596f2ae9/image/decoders/icon/mac/nsIconChannel.h#46): ```cpp nsCOMPtr<nsILoadInfo> mLoadInfo; ``` The analysis data we have is: Target records: ```json {"loc":"00046:11-22","target":1,"kind":"use","pretty":"nsILoadInfo","sym":"T_nsILoadInfo","context":"nsIconChannel","contextsym":"T_nsIconChannel"} {"loc":"00046:2-10","target":1,"kind":"use","pretty":"nsCOMPtr","sym":"T_nsCOMPtr","context":"nsIconChannel","contextsym":"T_nsIconChannel"} {"loc":"00046:24-33","target":1,"kind":"def","pretty":"nsIconChannel::mLoadInfo","sym":"F_<T_nsIconChannel>_mLoadInfo","context":"nsIconChannel","contextsym":"T_nsIconChannel","peekRange":"46-46"} ``` Source records: ```json {"loc":"00046:11-22","target":1,"kind":"use","pretty":"nsILoadInfo","sym":"T_nsILoadInfo","context":"nsIconChannel","contextsym":"T_nsIconChannel"} {"loc":"00046:2-10","target":1,"kind":"use","pretty":"nsCOMPtr","sym":"T_nsCOMPtr","context":"nsIconChannel","contextsym":"T_nsIconChannel"} {"loc":"00046:24-33","target":1,"kind":"def","pretty":"nsIconChannel::mLoadInfo","sym":"F_<T_nsIconChannel>_mLoadInfo","context":"nsIconChannel","contextsym":"T_nsIconChannel","peekRange":"46-46"} ``` Structured record for the type directly: ```json {"loc":"00046:24-33","structured":1,"pretty":"nsIconChannel::mLoadInfo","sym":"F_<T_nsIconChannel>_mLoadInfo","kind":"field","parentsym":"T_nsIconChannel"} ``` Structured sub-record for the containing type in the "fields" array: ```json {"offsetBytes":72,"pretty":"nsIconChannel::mLoadInfo","sizeBytes":8,"sym":"F_<T_nsIconChannel>_mLoadInfo","type":"nsCOMPtr<class nsILoadInfo>","typesym":"T_nsCOMPtr"} ``` ## Implementation Options ### Option: Introduce use sub-kinds for target records and support faceting on them? The sole target record we have for the line of interest in the example is: ```json {"loc":"00046:11-22","target":1,"kind":"use","pretty":"nsILoadInfo","sym":"T_nsILoadInfo","context":"nsIconChannel","contextsym":"T_nsIconChannel"} ``` I'm reasonably confident we could annotate that use as happening inside a field definition. We could also indicate when it's used in a local definition. Maybe we could even do a first attempt at bug 1419018's wish of attempting to indicate LHS/RHS usages. ### Option: Structured analysis type refinement via use in templates This is somewhat orthogonal to the above use-classification (which is probably what we should do), but it could make sense for the structured analysis data to have relationships that indicate: - The type nsILoadInfo is used in an nsCOMPtr template expansion which has type T_whatever and you can click to see the uses of this specific type. - This specific type would then again be filterable by the previous options ability to distinguish field uses from local uses and such. - It would also depend on us actually exposing the template's use on that line. - A meta-question here is whether the existing use should be transformed to only be the nsCOMPtr<T=nsILoadInfo> use or if we would emit both. My current thoughts are: - only emitting the template usage would be over-normalization and it's better for us to probably do what we're currently doing which could be thought of as de-normalized, and just make sure we can easily filter out classes of results that people don't want - any rationale around this should probably be aware of our smart pointer classes being implementation details that are usually not interesting on their own. - performance data at the granularity of text search/identifier lookup/symbol lookup/json-eval should be provided in the search results (or in a parallel resulting data structure accessible from the web) and drive these decisions, as I don't think these costs are at all intuitive. Also, in my attempts to address the changes made to how we handle overrides it's clear we potentially need to do a bunch of related look-ups and those costs definitely need to be known as we move forward with addressing those.
Bug 1733217 Comment 0 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
:smaug has a use case that currently involves doing (what ends up being) a [text search on `nsCOMPtr<nsILoadInfo> m`](https://searchfox.org/mozilla-central/search?q=nsCOMPtr%3CnsILoadInfo%3E+m&path=&case=false®exp=false). This hinges on the naming convention of prefixing member fields with `m`. We briefly discussed this in channel and tentatively it seems like the UX flow people would expect would be to first start with locating the type `nsILoadInfo` and then refining from there. ## Data ### Data we currently have Currently, for [this matching definition line](https://searchfox.org/mozilla-central/rev/79f93e7a8b9aa1903f1349f2dd46fb71596f2ae9/image/decoders/icon/mac/nsIconChannel.h#46): ```cpp nsCOMPtr<nsILoadInfo> mLoadInfo; ``` The analysis data we have is: Target records: ```json {"loc":"00046:11-22","target":1,"kind":"use","pretty":"nsILoadInfo","sym":"T_nsILoadInfo","context":"nsIconChannel","contextsym":"T_nsIconChannel"} {"loc":"00046:2-10","target":1,"kind":"use","pretty":"nsCOMPtr","sym":"T_nsCOMPtr","context":"nsIconChannel","contextsym":"T_nsIconChannel"} {"loc":"00046:24-33","target":1,"kind":"def","pretty":"nsIconChannel::mLoadInfo","sym":"F_<T_nsIconChannel>_mLoadInfo","context":"nsIconChannel","contextsym":"T_nsIconChannel","peekRange":"46-46"} ``` Source records: ```json {"loc":"00046:2-10","source":1,"syntax":"type,use","pretty":"type nsCOMPtr","sym":"T_nsCOMPtr"} {"loc":"00046:11-22","source":1,"syntax":"type,use","pretty":"type nsILoadInfo","sym":"T_nsILoadInfo","type":"class nsILoadInfo","typesym":"T_nsILoadInfo"} {"loc":"00046:24-33","source":1,"syntax":"def,field","pretty":"field nsIconChannel::mLoadInfo","sym":"F_<T_nsIconChannel>_mLoadInfo","type":"nsCOMPtr<class nsILoadInfo>","typesym":"T_nsCOMPtr"} ``` Structured record for the type directly: ```json {"loc":"00046:24-33","structured":1,"pretty":"nsIconChannel::mLoadInfo","sym":"F_<T_nsIconChannel>_mLoadInfo","kind":"field","parentsym":"T_nsIconChannel"} ``` Structured sub-record for the containing type in the "fields" array: ```json {"offsetBytes":72,"pretty":"nsIconChannel::mLoadInfo","sizeBytes":8,"sym":"F_<T_nsIconChannel>_mLoadInfo","type":"nsCOMPtr<class nsILoadInfo>","typesym":"T_nsCOMPtr"} ``` ## Implementation Options ### Option: Introduce use sub-kinds for target records and support faceting on them? The sole target record we have for the line of interest in the example is: ```json {"loc":"00046:11-22","target":1,"kind":"use","pretty":"nsILoadInfo","sym":"T_nsILoadInfo","context":"nsIconChannel","contextsym":"T_nsIconChannel"} ``` I'm reasonably confident we could annotate that use as happening inside a field definition. We could also indicate when it's used in a local definition. Maybe we could even do a first attempt at bug 1419018's wish of attempting to indicate LHS/RHS usages. ### Option: Structured analysis type refinement via use in templates This is somewhat orthogonal to the above use-classification (which is probably what we should do), but it could make sense for the structured analysis data to have relationships that indicate: - The type nsILoadInfo is used in an nsCOMPtr template expansion which has type T_whatever and you can click to see the uses of this specific type. - This specific type would then again be filterable by the previous options ability to distinguish field uses from local uses and such. - It would also depend on us actually exposing the template's use on that line. - A meta-question here is whether the existing use should be transformed to only be the nsCOMPtr<T=nsILoadInfo> use or if we would emit both. My current thoughts are: - only emitting the template usage would be over-normalization and it's better for us to probably do what we're currently doing which could be thought of as de-normalized, and just make sure we can easily filter out classes of results that people don't want - any rationale around this should probably be aware of our smart pointer classes being implementation details that are usually not interesting on their own. - performance data at the granularity of text search/identifier lookup/symbol lookup/json-eval should be provided in the search results (or in a parallel resulting data structure accessible from the web) and drive these decisions, as I don't think these costs are at all intuitive. Also, in my attempts to address the changes made to how we handle overrides it's clear we potentially need to do a bunch of related look-ups and those costs definitely need to be known as we move forward with addressing those.