Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "CDT/summitfall2008/Indexing Session"
m (New page: == Indexing break-out session == === C++0x === The standard not due until around 2010. For practical purposes, nearer the end of this year. GCC plans to support this 2009. Some awareness...) |
m (→C++0x) |
||
| Line 9: | Line 9: | ||
Which parser to extend? Performance/characteristics of the implementations needs to be understood. | Which parser to extend? Performance/characteristics of the implementations needs to be understood. | ||
| − | Action: No work for CDT 2009. Get an understanding of the standard. Start a wiki page and track the impacts of each language feature | + | Action: No commitment for any work for CDT 2009. Get an understanding of the standard. Start a wiki page and track the impacts of each language feature |
==== Language Variants ==== | ==== Language Variants ==== | ||
| Line 16: | Line 16: | ||
Language configurations vs Language variants - it makes more sense to have a language be configurable rather than a distinct language for each set of options. On the UI side we should consider language (C,C++,UPC) mappings, that indirect to specific languages (C89,C99,C90,C++0x,UPC). For example, the user marks files as C or C++, but can reconfigure which specific dialect is used for these. The language would instantiate a parser. | Language configurations vs Language variants - it makes more sense to have a language be configurable rather than a distinct language for each set of options. On the UI side we should consider language (C,C++,UPC) mappings, that indirect to specific languages (C89,C99,C90,C++0x,UPC). For example, the user marks files as C or C++, but can reconfigure which specific dialect is used for these. The language would instantiate a parser. | ||
| + | |||
| + | Some discussion of wanting to sync build and parser settings. Concern over the complexity. | ||
| + | |||
| + | === Indexing features === | ||
| + | |||
| + | * we could double-buffer indexes - make current index read-only. Start a new index with new settings. Swap when done. | ||
| + | * Resume of indexing between eclipse stop and start, and cancelled. | ||
| + | |||
| + | === Search-path-less Include resolution === | ||
| + | |||
| + | A bunch of heuristics to guess include paths from project content. Two metrics of closeness for ambiguity resolution. Structure for hashing for include lookup for large search paths, lazily constructed. | ||
Revision as of 10:38, 24 September 2008
Contents
Indexing break-out session
C++0x
The standard not due until around 2010. For practical purposes, nearer the end of this year. GCC plans to support this 2009. Some awareness of features in the team.
- Name resolution
- Index, AST modelling them
Which parser to extend? Performance/characteristics of the implementations needs to be understood.
Action: No commitment for any work for CDT 2009. Get an understanding of the standard. Start a wiki page and track the impacts of each language feature
Language Variants
Two ways of doing language variants - DOM Parser and extension objects, LPG Grammar hierarchies.
Language configurations vs Language variants - it makes more sense to have a language be configurable rather than a distinct language for each set of options. On the UI side we should consider language (C,C++,UPC) mappings, that indirect to specific languages (C89,C99,C90,C++0x,UPC). For example, the user marks files as C or C++, but can reconfigure which specific dialect is used for these. The language would instantiate a parser.
Some discussion of wanting to sync build and parser settings. Concern over the complexity.
Indexing features
* we could double-buffer indexes - make current index read-only. Start a new index with new settings. Swap when done. * Resume of indexing between eclipse stop and start, and cancelled.
Search-path-less Include resolution
A bunch of heuristics to guess include paths from project content. Two metrics of closeness for ambiguity resolution. Structure for hashing for include lookup for large search paths, lazily constructed.