Eclipse CDT: Problems with extension point CIndexer - eclipse-cdt

Problem 1: I can't find org.eclipse.cdt.core.index.IIndexer
From the API:
API Information: Plug-ins that want to extend this extension point must implement org.eclipse.cdt.core.index.IIndexer interface.
Is the API Information incorrect/deprecated? Which interface should be implemented if not IIndexer?
Problem 2: I can install my own Indexer in CDT version 6.8 (eclipse 2019-06) but not in version 6.5 (eclipse 2018-09), though I don't see the difference in the plugin code.
More Details:
My Indexer class:
#SuppressWarnings("restriction")
public class MyIndexer extends PDOMFastIndexer {
public static final String ID = "de.blub.MyIndexer";
#Override
public String getID() {
return ID;
}
#Override
public IPDOMIndexerTask createTask(ITranslationUnit[] added, ITranslationUnit[] changed,
ITranslationUnit[] removed) {
if (...) {
return new MyIndexerTask(added, changed, removed, this, true);
} else {
return super.createTask(added, changed, removed);
}
}
The plugin.xml
<extension
id="org.eclipse.cdt.core.fastIndexer"
name="My Indexer"
point="org.eclipse.cdt.core.CIndexer">
<run
class="de.blub.MyIndexer">
</run>
The MANIFEST.MF File lists org.eclipse.cdt.core in the Require-Bundle section without bundle-version. Of course the cdt plugin has different versions:
In Eclipse 2019-06:
Eclipse CDT C/C++ Development Tools Core 6.8.1.201907021957 org.eclipse.cdt.core
In Eclipse 2018-09:
Eclipse CDT C/C++ Development Tools Core 6.5.0.201811180605 org.eclipse.cdt.core
This code is from org.eclipse.cdt.internal.core.pdom.PDOMManager:
private IPDOMIndexer newIndexer(String indexerId, Properties props) throws CoreException {
IPDOMIndexer indexer = null;
// Look up in extension point
IExtension indexerExt = Platform.getExtensionRegistry().getExtension(CCorePlugin.INDEXER_UNIQ_ID, indexerId);
if (indexerExt != null) {
IConfigurationElement[] elements = indexerExt.getConfigurationElements();
for (IConfigurationElement element : elements) {
if ("run".equals(element.getName())) { //$NON-NLS-1$
try {
indexer = (IPDOMIndexer) element.createExecutableExtension("class"); //$NON-NLS-1$
indexer.setProperties(props);
} catch (CoreException e) {
CCorePlugin.log(e);
}
break;
}
}
}
// Unknown index, default to the null one
if (indexer == null)
indexer = new PDOMNullIndexer();
return indexer;
}
The code is the same for both cdt versions. indexer becomes a PDOMFastIndexer in eclipse 2018-09, but a MyIndexer in 2019-06.
One difference I could see is that in RegistryObjectManager
private Object basicGetObject(int id, byte type) {
Object result = cache.get(id);
if (result != null)
return result;
...
}
An id is used to get the correct ConfigurationElement (result) from a cache object, which I don't really understand how it is built up. However, the returned ConfigurationElement contains a field propertiesAnsValues which is incorrect in the one case (org.eclipse.cdt.internal.core.pdom.indexer.PDOMFastIndexer instead of de.blub.MyIndexer).
How can I fix that to have my own indexer in eclipse 2018-09, too?
Please also note my Problem 1. Because if the API description is correct, it means I'm trying to install my indexer the wrong way and need to do something to 'see' the IIndexer interface.

According to the schema definition, the class you need to derive from is IPDOMIndexer (which you're already doing). You can also tell this from the PDOMManager code you quoted, which casts the result of createExecutableExtension() to IPDOMIndexer.
(The comment saying to use org.eclipse.cdt.core.index.IIndexer is indeed out of date. Based on a brief look, that interface hasn't existed since at least 2005. Patches to update the extension point documentation are welcome.)
As for your second problem, I believe it's because you're using id="org.eclipse.cdt.core.fastIndexer" for your extension, which is already in use by one of CDT's built-in indexers. The id needs to identify your extension uniquely (so you can make it something like myproject.MyIndexer.)

Related

Moq Verify Not Working as Expected After Upgrading to .NET Core 3.1

So as the title implies, this worked for us in .NET Core 2.2 and Moq Version 4.10.1. After upgrading to .NET Core 3.1 and Moq Version 4.14.5, the verify method is failing saying the method specified hasn't been called (no changes to the underlying code). I rolled back Moq to version 4.10.1 just to see if it was due to a change within the new version of Moq. I still get the same error.
Trying to verify that a log message has been written to the ILogger.
Weird thing is, if I debug the unit test and look at the mocked object with a variable watch, it shows that the method has indeed been invoked.
Relevant code:
public class AuditFilter, IResultFilter
{
...
public void OnResultExecuted( ResultExecutedContext context )
{
if( !IsContextValid( context ) )
{ return; }
...
}
public override bool IsContextValid( FilterContext context )
{
if( context == null )
{
Logger.Error( "Error writing to the audit log", new ArgumentNullException( nameof( context ) ) );
return false;
}
if( context.HttpContext == null )
{
Logger.LogError( "Error writing to the audit log", new ArgumentNullException( nameof( context.HttpContext ) ) );
return false;
}
return true;
}
public ILogger Logger { get; set; }
...
}
public class AuditTests : BaseTests
{
...
private Mock<ILogger> _mockLog;
private AuditFilter _filter;
[SetUp]
public void Setup()
{
_mockLog = new Mock<Microsoft.Extensions.Logging.ILogger>();
_mockLog.SetupAllProperties;
_filter = new AuditFilter();
}
[Test]
public void Service_Filters_Audit_IsContextValid_Context_Null()
{
var expected = false;
_filter.Logger = _mockLog.Object;
var actual = _filter.IsContextValid( null );
_mockLog.Verify( logger => logger.Log( LogLevel.Error,
It.IsAny<EventId>(),
It.IsAny<object>(),
It.IsAny<ArgumentNullException>(),
It.IsAny<Func<object, Exception, string>>() ),
Times.Once );
Assert.AreEqual( expected, actual );
}
...
}
Note: The method ILogger.LogError is a Microsoft extension method for ILogger that calls ILogger.Log method.
Below is the exception that is thrown.
Note: An integer implicitly casts to Microsoft.Extensions.Logging.EventId, the second input parameter type for the ILogger.Log method.
These signatures appear to match to me; so I'm not sure why it's saying it wasn't invoked.
To reiterate, this code worked prior to upgrading to .NET Core 3.1 and still works in our pre-forked code.
Also, before someone suggests that the method needs to be setup: it worked before the upgrade without it, and I already tried it and it didn't work.
I believe the problem will be this part of the verify expression
It.IsAny<Func<object, Exception, string>>()
Under the covers it's not a Func<object, Exception, string> and the mock IsAny matcher doesn't match because of this difference. If you modify it to
(Func<object, Exception, string>) It.IsAny<object>()
it should match. Below is what I've settled on as the starting point for verify expressions as it works for at least .NET Core 2.* onwards:
loggerMock.Verify(x => x.Log(
It.IsAny<LogLevel>(),
It.IsAny<EventId>(),
It.IsAny<IReadOnlyList<KeyValuePair<string, object>>>(),
It.IsAny<Exception>(),
(Func<object, Exception, string>) It.IsAny<object>()),
Times.Exactly(expectedNumberOfInvocations));
You can use It.IsAny<object>() for the third parameter but I find this is more convenient when interrogating the properties.
I've been doing a fair bit of log invocation verification at work recently for black box processes so now I mostly use Moq.Contrib.ExpressionBuilders.Logging to build fluent, readable verify expressions. Disclaimer: I am the author.
Like I had added in the comments, this is a known issue with Moq and .NET Core right from the Preview version of .NET Core 3.0. Please take a look at the github issue to understand why this broke with the update.
In a nutshell, from the issue linked, the failure here is caused due to fact that the type being passed to Logger.Log method is now changed to FormattedLogValues. Though there is a generic type matcher It.IsAnyType introduced in Moq 4.13.0, that would not address the issue.
The reason for this, as one of the authors of Moq states here
The important bit (for now) is that It.IsAnyType is not used in a nested position in the It.IsAny<> type argument.
As a workaround we should replace
It.IsAny<Func<object, Exception, string>>()
with
(Func<object, Exception, string>)It.IsAny<object>()
The rationale provided for this, is to improve the performance of the type matcher as the former would result in the decomposition of all the type parameters underneath the hood to see if there is a type matcher included in the first place.

VS 2017 Designer: Method not found

I have a windows form that contains a user control (each defined in separate assemblies). Both the form and the user control call an extension method on BindingList<>. The extension method is defined in a 3rd assembly. Everything compiles & runs fine.
However, if I try to open the form in Visual Studio 2017 designer, I get an error:
To prevent possible data loss before loading the designer, the following errors must be resolved:
Method not found: 'System.ComponentModel.BindingList1 KamaTrenda.Utilities.Lists.ListUtilities.AddReset(System.ComponentModel.BindingList1,
System.Collections.Generic.IEnumerable`1)'.
Call stack:
at System.ComponentModel.ReflectPropertyDescriptor.SetValue(Object
component, Object value) at
Microsoft.VisualStudio.Shell.Design.VsTargetFrameworkPropertyDescriptor.SetValue(Object
component, Object value) at
System.ComponentModel.Design.Serialization.CodeDomSerializerBase.DeserializePropertyAssignStatement(IDesignerSerializationManager
manager, CodeAssignStatement statement,
CodePropertyReferenceExpression propertyReferenceEx, Boolean
reportError) at
System.ComponentModel.Design.Serialization.CodeDomSerializerBase.DeserializeAssignStatement(IDesignerSerializationManager
manager, CodeAssignStatement statement) at
System.ComponentModel.Design.Serialization.CodeDomSerializerBase.DeserializeStatement(IDesignerSerializationManager
manager, CodeStatement statement)
Commenting out the content of the setter of this property allows for opening the form in the designer:
public IList<IPosition> PositionsToDisplay
{
get { return myPositionsToDisplay.Select(x => x.Position).ToList(); }
set { myPositionsToDisplay.AddReset(value.Select(x => new PositionAdapter(x))); }
}
myPositionsToDisplay:
private readonly BindingList<PositionAdapter> myPositionsToDisplay = new SortableBindingList<PositionAdapter>();
And AddReset:
public static class ListUtilities
{
public static BindingList<T> AddReset<T>(this BindingList<T> list, IEnumerable<T> toAdd)
{
list.RaiseListChangedEvents = false;
foreach (T item in toAdd)
list.Add(item);
list.RaiseListChangedEvents = true;
list.ResetBindings();
return list; // for chaining
}
}
I have tried adding
[Browsable(false), DesignerSerializationVisibility(DesignerSerializationVisibility.Hidden)]
to the definition of PositionsToDisplay, and it made no difference.
I tried rebuilding, manually deleting the contents obj & bin directories for all 3 projects, as well as the contents of AppData\Local\Microsoft\VisualStudio\15.0_6d397e1a\ProjectAssemblies, closing all open documents in VS 2017, closing the solution, and restarting Visual Studio, and it made no difference.
The .resx file of neither the form, nor the control, refer to the property.
The Designer.cs for the form had some code that seemed to be causing the issue:
this.control.PositionsToDisplay = ((System.Collections.Generic.IList<IPosition>)(resources.GetObject("control.PositionsToDisplay")));
Deleting this (presumably after adding DesignerSerializationVisibility.Hidden, so that it does not get re-generated) seemed to solve the issue.

Sitecore IsPageEditor and IsExperienceEditor

We are currently writing a module for Sitecore and have ran into a problem.
We have a pipeline in which we do the following check:
if (Sitecore.Context.PageMode.IsExperienceEditor)
{
return;
}
The problem is that one of our clients are running and older version of Sitecore (8.0 update 5) where the property IsExperienceEditor does not exist yet. See Sitecore release notes for next update where it is introduced.
To quickly fix the error we used the older deprecated property which is this:
if (Sitecore.Context.PageMode.IsPageEditor)
{
return;
}
Now the question is, is there any way in which we can test for the Sitecore version so we can have backwards compatibility in the module?
You can use the code which is executed in Sitecore in background of both properties mentioned by you:
if (Sitecore.Context.Site.DisplayMode == Sitecore.Sites.DisplayMode.Edit)
{
return;
}
I know that using Sitecore.Context.PageMode.IsExperienceEditor (or Sitecore.Context.PageMode.IsPageEditor) is more elegant, but in a situation when you need to support both old and new Sitecore versions, that's sounds like a good option.
The deprecated property of IsPageEditor is still present specifically for the purpose of backward compatibility. IsExperienceEditor is just a renamed property that does the same thing that IsPageEditor does.
However you can check for the existence of a property like this:
public static bool HasProperty(this object obj, string propertyName)
{
return obj.GetType().GetProperty(propertyName) != null;
}
Another option is to make two different versions of the module, if the implementation becomes significantly different for the different versions of Sitecore.

Access violation using a C++ function from a DLL

I have a game engine written in C++ which I'm porting to Windows (from Mac). It uses C++11 and OpenGL, and for all intents and purposes, it runs!
I'm using a DLL for my game engine which is linked implicitly to the game .exe at runtime. The problem is, when I try to use a utility class from the DLL, FileSystem, to find a resource file (a texture, but I don't think it's important), I get this error:
First-chance exception at 0x00007FF9CF988830 (PocoFoundation64.dll) in TestEquinox.exe: 0xC0000005: Access violation reading location 0x000000136A4FF000.
The problem comes when I call this method of my FileSystem class from the DLL (it's designed to take a filename/partial path and it looks in various places to find the full path):
Poco::Path FileSystem::Get(const std::string &filename) {
std::vector<Poco::Path> paths = {
filename,
ResourceFolder() / filename //<<<<< ERROR HERE
};
for (const Poco::Path &path : paths) {
try {
if (Poco::File(path).exists()) {
return path;
}
} catch (...) { }
}
Logger("FileSystem", std::cerr) << "Could not find file '" << filename << "'!";
return {};
}
Visual Studio shows the error as being at the call of ResourceFolder(), another method from the same class, also in the DLL. This appears so:
Poco::Path FileSystem::ResourceFolder() {
Poco::Path userData;
//--SNIP-- (other OS's #ifdef'd here)
// GAME->StartupPath is a std::string containing the exe's parent folder
userData = (Poco::Path(GAME->StartupPath).parent() / "Resources").makeDirectory();
//--SNIP-- (and here)
try {
if (!Poco::File(userData).exists()) {
Poco::File(userData).createDirectories();
}
} catch (...) {}
return userData;
}
From the looks of it, it's to do with Poco's data types not being instantiated properly? I've built it from source with all the same compiler settings (64-bit, multi-byte character set, VS2013), so I don't see how it could be a name mangling/data layout issue.
One more thing to note - I copied the entire FileSystem class from the DLL to a class local to my game project, called FileSystem2. Calling FileSystem2::Get with the same parameters worked correctly and without crashing, despite being the same code.
Hoping someone can point me in the right direction?!
Usually errors like this stem from using incompatible runtime libraries that your module uses. Please check the following for all of your modules in the Visual Studio properties:
Project Properties -> C/C++ -> Code Generation -> Runtime Library.
The runtime setting (Multithread DLL, Multithread Debug DLL, etc.) must match up with all the modules you're compiling. If they do not match, choose one runtime, and rebuild all of your modules using that runtime.

Can I programmatically collapse/expand all preprocessor blocks of a certain name in Visual Studio 2012?

My current project has a lot of debug preprocessor blocks scattered throughout the code. These are intentionally named differently to the system _DEBUG and NDEBUG macros, so I have a lot of this:
// Some code here
#ifdef PROJNAME_DEBUG
//unit tests, assumption testing, etc.
#endif
// code continues
These blocks sometimes get rather large, and their presence can sometimes inhibit code readability. In Visual Studio 2012 I can easily collapse these, but it would be nice to automatically have all of them collapsed, allowing me to expand them if I want to see what's in there. However, as I also have a bunch of header guards I don't want to collapse all preprocessor blocks, only the #ifdef PROJNAME_DEBUG ones.
Can I do this?
This is the most easiest scenario you can achive it, I think.
You should create an Add-In first in C#. (in VS 2013 they become deprecated :( )
In the OnConnection method you should add your command:
public void OnConnection( object application, ext_ConnectMode connectMode, object addInInst, ref Array custom )
{
_applicationObject = (DTE2)application;
if (connectMode == ext_ConnectMode.ext_cm_AfterStartup || connectMode == ext_ConnectMode.ext_cm_Startup)
{
Commands2 commands = (Commands2)_applicationObject.Commands;
try
{
//Add a command to the Commands collection:
Command command = commands.AddNamedCommand2(_addInInstance, "MyAddinMenuBar", "MyAddinMenuBar", "Executes the command for MyAddinMenuBar", true, 59, ref contextGUIDS, (int)vsCommandStatus.vsCommandStatusSupported + (int)vsCommandStatus.vsCommandStatusEnabled, (int)vsCommandStyle.vsCommandStylePictAndText, vsCommandControlType.vsCommandControlTypeButton);
}
catch (System.ArgumentException)
{
//If we are here, bla, bla... (Auto generated)
}
}
}
Note: you can find how parameters are act at the reference of AddNamedCommand2
The template created version would be also fine, but naturaly it worth to name your command properly.
After that you need to add your logic to Exec method:
public void Exec( string commandName, vsCommandExecOption executeOption, ref object varIn, ref object varOut, ref bool handled )
{
handled = false;
if (executeOption == vsCommandExecOption.vsCommandExecOptionDoDefault)
{
if (commandName == "MyAddinMenuBar.Connect.MyAddinMenuBar")
{
List<string> args = (varIn as string).Split(' ').ToList();
TextSelection ts;
ts = (TextSelection)_applicationObject.ActiveDocument.Selection;
EditPoint ep = (ts.ActivePoint).CreateEditPoint();
ep.StartOfDocument();
do
{
string actualLine = ep.GetLines(ep.Line, ep.Line + 1);
if (args.TrueForAll(filter => actualLine.Contains(filter)))
{
_applicationObject.ExecuteCommand("Edit.GoTo", ep.Line.ToString());
_applicationObject.ExecuteCommand("Edit.ToggleOutliningExpansion");
}
ep.LineDown();
} while (!ep.AtEndOfDocument);
handled = true;
return;
}
}
}
Note: Name you given to the command is checked in exec.
Than you can build.
Deployment of Add-In can happen through an [ProjectName].AddIn file in ..\Documents\Visaul Studio 20[XY]\AddIns\. (Created by the template, you should copy if you move the Add-In elsewhere)
You should place your Add-In assembly where the Assembly element of the mentioned file you set to point. To change version you should modify the text in Version element.
After you deployed and started Studio, you should activate the Add-In in the manager in Toolsmenu.
You need to expand all collapsable section in your code file (CTRL+M+L with C# IDE settigs).
This is required because I found only a way to invert the state of collapsion. If you find better command, you can change it.
Next you should activate Command Window to use the the created command.
Now only you need to type your commands name, like this:
MyAddinMenuBar.Connect.MyAddinMenuBar #ifdef PROJNAME_DEBUG
Hopefully magic will happen.
This solution is independent of language of code you edit so pretty multifunctional.