Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Speedup/cleanup of scope_resolution #219

Open
matter123 opened this issue Jun 1, 2019 · 4 comments
Open

Speedup/cleanup of scope_resolution #219

matter123 opened this issue Jun 1, 2019 · 4 comments
Labels
Contributor Issues that users probably don't care about Hard 🔍 investigating More information is being gathered

Comments

@matter123
Copy link
Collaborator

Per #218 (comment), the patterns made by generateScopeResolutionFinder are slow. Additionally, the pattern is used in many places. If the patterns can be made atomic, it should speed up parsing time for most of the grammar.

Additionally, the difference between the main scope_resolution pattern and the inner generated pattern is not documented. There also appears to be no particular reason why some patterns use the outer pattern, and some use the inner pattern.

The main difference between the outer scope_resolution and the inner scope_resolution is that the inner scope_resolution pattern must match at least one A<B>:: while the outer pattern is allowed to match none.

@matter123 matter123 added 🔍 investigating More information is being gathered Hard Contributor Issues that users probably don't care about labels Jun 1, 2019
@jeff-hykin
Copy link
Owner

jeff-hykin commented Jun 6, 2019

Whenever this is being looked into, one of the things that might be increasing the slowness is that the template pattern (the <>) it is somewhat complicated and I believe it needs backtracking to run correctly (and the scope resolution uses the template pattern).

In terms of how the current scope_resolution works, I believe the outer one matches multiple resolutions thing1::thing2::thing3. But because of the way textmate handles capture groups and highlighting, they cant be tagged all at once. So instead the outer pattern includes an inner pattern that matches only one thing1:: and then it does the tagging.

As to why some patterns need the inner and some need the outer, I think the outer one is used when the pattern is actually used in the match:. I think the inner one is used with includes: since the inner one actually does the tagging.

@matter123
Copy link
Collaborator Author

matter123 commented Jun 6, 2019

the inner pattern starts off with the outer pattern https://github.com/jeff-hykin/cpp-textmate-grammar/blob/14b092b60d7e1d2833b64141fa02bea2913611e5/source/languages/cpp/generate.rb#L766, so it should match multiple times as well.

@jeff-hykin
Copy link
Owner

jeff-hykin commented Jun 6, 2019

Oops.. yeah thats a problem. It must be doing it recursively where only one pattern is doing the tagging on the way down.

@jeff-hykin
Copy link
Owner

// This file is part of Asteria.
// Copyleft 2018 - 2019, LH_Mouse. All wrongs reserved.

#include "cow_string.hpp"

namespace rocket {

template class basic_cow_string<char>;
template class basic_cow_string<wchar_t>;
template class basic_cow_string<char16_t>;
template class basic_cow_string<char32_t>;

template ::std::istream& operator>>(::std::istream& is, cow_string& str);
template ::std::wistream& operator>>(::std::wistream& is, cow_wstring& str);

template ::std::ostream& operator<<(::std::ostream& os, const cow_string& str);
template ::std::wostream& operator<<(::std::wostream& os, const cow_wstring& str);

template ::std::istream& getline(::std::istream& is, cow_string& str, char delim);
template ::std::wistream& getline(::std::wistream& is, cow_wstring& str, wchar_t delim);
template ::std::istream& getline(::std::istream& is, cow_string& str);
template ::std::wistream& getline(::std::wistream& is, cow_wstring& str);

}  // namespace rocket

Screen Shot 2019-06-24 at 7 43 41 PM

This code gets screwed up because of the scope resolution. I looked into it some today and did not have much luck.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Contributor Issues that users probably don't care about Hard 🔍 investigating More information is being gathered
Projects
None yet
Development

No branches or pull requests

2 participants