Community
Participate
Working Groups
+++ This bug was initially created as a clone of Bug #401961 +++ This bug is for tracking a backport of the LSP provider for pathEntryContainers, and any potential additional low-impact changes in order to make the regression described in bug 401961 disappear.
Added the provider to cdt_8_1 branch. Please, test.
Hi Andrew, I finally got to testing this (using Hudson cdt-maint #416 of May 3. Over all, it looks very promising ! But there's currently a few rough edges: 1. No auto-enable: ------------------ The "Contributed PathEntry Containers" provider is not configured into my project by default. That way, we're still suffering from the regression. I think that the PathEntry provider needs to be added to the project by default just like the "CDT Managed Build Settings Entries" provider, when contributed pathEntries are detected. 2. Incorrect Decorator: ----------------------- When I manually enable the provider on the providers page, settings are properly passed to the indexer; but in the Project Explorer, each and every file now gets a "key" decorator which usually indicates the respective file having some "overrides" of the indexer settings. This is confusing, and it is also pretty slow (took very long until the decorator got visible). 3. (probably unrelated): Cannot store language mappings on project level ------------------------------------------------------------------------ In my case, the default language mappings on Workspace level are for each content type pointing to the "Wind River C" language. I'd like to override those to the "GNU GCC" language for one specific project. But looking at the data that is persisted, it looks like this data is not persisted with the project. IMO the content type --> language mapping is a property of the project, and it must be possible to persist that setting with the project in my CM system. Of these 3 issues, #2 is IMO the most severe one since it is very visible and confusing. The other issues I can probably work around (will need to check). Many thanks for your continued support here ! It's very important for us. Thanks, Martin
Oops, please disregard #3 -- I had just missed the setting in the .cproject file. So, #2 looks important and #1 I can probably work around (though I'd prefer #1 to be done in a backward compatible way by the CDT).
(In reply to comment #2) > Over all, it looks very promising ! > But there's currently a few rough edges: > > 1. No auto-enable: > ------------------ > The "Contributed PathEntry Containers" provider is not configured into > my project by default. That way, we're still suffering from the regression. > I think that the PathEntry provider needs to be added to the project by > default just like the "CDT Managed Build Settings Entries" provider, when > contributed pathEntries are detected. It can be added to the list but by default LSP will be disabled (same as for other legacy projects). The code needs to be different than on master though. If you are up to working on a patch I can instruct what needs to be done. > 2. Incorrect Decorator: > ----------------------- > When I manually enable the provider on the providers page, settings are > properly passed to the indexer; but in the Project Explorer, each and > every file now gets a "key" decorator which usually indicates the respective > file having some "overrides" of the indexer settings. This is confusing, > and it is also pretty slow (took very long until the decorator got visible). This does sound like severe issue. Let me take a look what is going on. Do you have the same issue on master branch?
(In reply to comment #4) > (In reply to comment #2) > > 2. Incorrect Decorator: > > ----------------------- > > When I manually enable the provider on the providers page, settings are > > properly passed to the indexer; but in the Project Explorer, each and > > every file now gets a "key" decorator which usually indicates the respective > > file having some "overrides" of the indexer settings. This is confusing, > > and it is also pretty slow (took very long until the decorator got visible). > This does sound like severe issue. Let me take a look what is going on. Do you > have the same issue on master branch? Well, I do not observe this in my sample project. I will need an example of a project where it happens.
Hi Andrew, Regarding #1 : > It can be added to the list but by default LSP will be disabled (same as for > other legacy projects). Well this gets us back to where we started from: Yes LSP's are initially disabled for legacy projects, and that fact is stored in the local Workspace Preferences; but then the <LanguageSettingsProvider> slot is written into the .cproject file, and when I now checkin that project for some other user in my team (or I import that project into a different workspace), I have LSP's enabled. This breaks backward compatibility. Because the code enables LSP support at a time I don't want to, the LSP support must transparently produce the same results as the legacy support would have produced. We had concluded on bug 398056 that our strategy to resolve that problem would be fixing the LSP's (and not making sure that legacy mode remains enabled). > The code needs to be different than on master though. If you are up to > working on a patch I can instruct what needs to be done. Unfortunately I can't work on a patch immediately (and my incentive to do so is limited since I have a workaround). Still I feel that breaking backward compatibility in a SR2 release is a no-go, since SR1 worked OK for us (it didn't enable the LSP's at a time when the user didn't want to). > This does sound like severe issue. Let me take a look what is going on. Do > you have the same issue on master branch? I didn't get to testing on master yet but will try as soon as I can. I'll upload a sample project as soon as I can (need to clean it from customer's IP first). Thanks, Martin
Regarding #2, the same issue is in master.
If it is pure decorator issue it is possible to disable it in Label Decorator Preferences as workaround. I'd rather fix the root cause though.
This bug was assigned and targeted at a now released milestone. As that milestone has now passed, the milestone field has been cleared. If this bug has been fixed, please set the milestone to the version it was fixed in and marked the bug as resolved.
