-
Notifications
You must be signed in to change notification settings - Fork 199
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
On createBuildConfiguration, reset project's ScannerInfoProvider #817
On createBuildConfiguration, reset project's ScannerInfoProvider #817
Conversation
1d81b34
to
8415b07
Compare
Hi @jonahgraham ,
Cheers John |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The failing tests Code Cleanliness Checks / Test Results (pull_request)
are known to fail (since recently) see #816
The Code Cleanliness Checks / build (pull_request)
failure is because you reintroduced a deleted project.
@@ -0,0 +1,22 @@ | |||
<?xml version="1.0" encoding="UTF-8"?> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You have accidentally restored/recreated a project that has been removed from CDT very recently.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OMG, silly of me.
Removed now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Aside from the small process issues, this is good to go.
@@ -0,0 +1,121 @@ | |||
package org.eclipse.cdt.core.build; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please add copyright block
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
8415b07
to
90dc5ff
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jonahgraham , thanks for your review.
@@ -0,0 +1,121 @@ | |||
package org.eclipse.cdt.core.build; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
@@ -0,0 +1,22 @@ | |||
<?xml version="1.0" encoding="UTF-8"?> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OMG, silly of me.
Removed now.
Hi @jonahgraham , I pushed an update, but have 3 failing checks now. They say "This job failed". Don't know what I've done or maybe the CI just glitched. Is there a way to rerun? |
When the project's active IBuildConfiguration has the default name and the chosen ICBuildConfigurationProvider.getCBuildConfiguration does not support the IBuildConfiguration.DEFAULT_CONFIG_NAME and returns null, this can cause the project's ScannerInfoProvider to become "stuck" (https://bugs.eclipse.org/bugs/show_bug.cgi?id=413357) on the wrong setting (eg LanguageSettingsScannerInfoProvider instead of ICBuildConfiguration) until Eclipse is restarted or the project is closed and reopened. When this happens, the indexer does not function. This problem may arise if an ISV contributes a ICBuildConfigurationProvider which has very specific naming conventions for it's build configurations. The solution uses the API (resetCachedScannerInfoProvider(project)), introduced by 413357, to reset the project's ScannerInfoProvider when a new ICBuildConfiguration is created.
90dc5ff
to
c69a5e0
Compare
Hi @jonahgraham , |
It was an error on Github - never seen it before but it said:
As a committer you can press rerun, not sure if contributors can do that. Anyway you figured out the workaround was to just push an update.
Indeed. |
When the project's active IBuildConfiguration has the default name and the chosen ICBuildConfigurationProvider.getCBuildConfiguration does not support the IBuildConfiguration.DEFAULT_CONFIG_NAME and returns null, this can cause the project's ScannerInfoProvider to become "stuck" (https://bugs.eclipse.org/bugs/show_bug.cgi?id=413357) on the wrong setting (eg LanguageSettingsScannerInfoProvider instead of ICBuildConfiguration) until Eclipse is restarted or the project is closed and reopened. When this happens, the indexer does not function. This problem may arise if an ISV contributes a ICBuildConfigurationProvider which has very specific naming conventions for it's build configurations. The solution uses the API (resetCachedScannerInfoProvider(project)), introduced by 413357, to reset the project's ScannerInfoProvider when a new ICBuildConfiguration is created. (cherry picked from commit 0f36d5d)
💚 All backports created successfully
Questions ?Please refer to the Backport tool documentation and see the Github Action logs for details |
…ovider (#817) (#854) When the project's active IBuildConfiguration has the default name and the chosen ICBuildConfigurationProvider.getCBuildConfiguration does not support the IBuildConfiguration.DEFAULT_CONFIG_NAME and returns null, this can cause the project's ScannerInfoProvider to become "stuck" (https://bugs.eclipse.org/bugs/show_bug.cgi?id=413357) on the wrong setting (eg LanguageSettingsScannerInfoProvider instead of ICBuildConfiguration) until Eclipse is restarted or the project is closed and reopened. When this happens, the indexer does not function. This problem may arise if an ISV contributes a ICBuildConfigurationProvider which has very specific naming conventions for it's build configurations. The solution uses the API (resetCachedScannerInfoProvider(project)), introduced by 413357, to reset the project's ScannerInfoProvider when a new ICBuildConfiguration is created. (cherry picked from commit 0f36d5d) Co-authored-by: betamax <[email protected]>
When the project's active IBuildConfiguration has the default name and the chosen ICBuildConfigurationProvider.getCBuildConfiguration does not support the IBuildConfiguration.DEFAULT_CONFIG_NAME and returns null, this can cause the project's ScannerInfoProvider to become "stuck" (https://bugs.eclipse.org/bugs/show_bug.cgi?id=413357) on the wrong setting (eg LanguageSettingsScannerInfoProvider instead of ICBuildConfiguration) until Eclipse is restarted or the project is closed and reopened. When this happens, the indexer does not function.
This problem may arise if an ISV contributes a
ICBuildConfigurationProvider which has very specific naming conventions for it's build configurations.
The solution uses the API (resetCachedScannerInfoProvider(project)), introduced by 413357, to reset the project's ScannerInfoProvider when a new ICBuildConfiguration is created.