Is it possible to cast a FxCop.SDK.TypeNode in Microsoft.FxCop.Sdk to an System.Type ?
Not really. There used to be a reflection "bridge" built into FxCop for this, but it was removed in FxCop 1.36. You could potentially roll your own mechanism based on the assembly location and the type name. However, this really shouldn't be necessary in most cases. If you could explain why you want to do this, it might be possible to suggest an alternate approach...
Related
I know some of this, but not all of it. Most notably, I am aware of TypeDescription.Generic.Builder but I have a very specific question about it.
Suppose I want to build Supplier<? extends Frob<X>>.
Suppose further that all I know I have is a TypeDefinition for the parameter, but I don't know what it represents (in the example above it would represent Frob<X>). That is, I don't know whether the TypeDefinition I have is a class, a parameterized type, a generic array type, a type variable, a wildcard, or anything else; I just know it's a TypeDefinition.
Obviously if I wanted to make Supplier<Frob<X>>, I could just do:
TypeDescription.Generic.Builder.parameterizedType(TypeDescription.ForLoadedType.of(Supplier.class),
myTypeDefinition)
.build();
…assuming I haven't made any typos in the snippet above.
How can I make an upper-bounded wildcard TypeDefinition out of an existing TypeDefinition suitable for supplying as the "parameterized" part of a parameterized type build? Is there an obvious recipe I'm overlooking, or is this a gap in the builder's DSL?
(I'm aware of the asWildcardUpperBound() method on TypeDescription.Generic.Builder, but that presumes I have a builder to work with, and in order to "bootstrap" such a builder I would need to give it a TypeDescription at the very least. But I don't have a TypeDescription; I have a TypeDefinition which might be parameterized, and I don't want to use asErasure().)
(I'm sort of looking for a way to do TypeDescription.Generic.Builder.parameterizedType(myTypeDefinition).asWildcardUpperBound().build(), but I can't obviously do that.)
There does seem to be TypeDescription.Generic.OfWildcardType.Latent::boundedAbove but I can't tell if that's supposed to be an "internal use only" class/method or not.
Such an API was indeed missing. I added an API in today's release (1.11.5) to translate an existing generic type description to a builder what allows transformations to arrays or wildcards. The API is TypeDescription.Generic.Builder.of which accepts a loaded or unloaded generic type description.
I'm aware this might be a broad question (there's no specific code for you to look at), but I'm hoping I'd get some insights as to what to do, or how to approach the problem.
To keep things simple, suppose the compiler that I'm writing performs these three steps:
parse (and bind all variables)
typecheck
codegen
Also the language that I'm building the compiler for wants to support late-analysis/late-binding (ie., it has a function that takes a String, which is to be compiled and executed as a piece of source-code during runtime).
Now during parse-phase, I have a piece of context that I need to keep around till run-time for the sole benefit of the aforementioned function (because it needs to parse and typecheck its argument in that context).
So the question, how should I do this? What do other compilers do?
Should I just serialise the context object to disk (codegen for it) and resurrect it during run-time or something?
Thanks
Yes, you'll need to emit the type information (or other context, you weren't very specific) in your object/executable files, so that your eval can read it at runtime. You might look at Java's .class file format for inspiration; Java doesn't have eval as such, but you can dynamically spin new bytecode at runtime that must be linked in a type-safe manner. David Conrad's comment is spot-on: this information can also be used to implement reflection, if your language has such a feature.
That's as much as I can help you without more specifics.
We are finding issues (and reporting them) in EclipseLink's InformixPlatform class--the class responsible for adapting the Informix database to the requirements of the EclipseLink innards.
We have a couple of type conversion issues. For example, Informix supports two opaque literals (t and f--not the characters, but actual literals) as native boolean values. It appears that perhaps EclipseLink is trying to use SMALLINT instead as the database type.
Short of a lot of procedural code inside a SessionCustomizer, I cannot find a good place to correct or improve such global conversion behavior.
Where is the best place to register this global take-a-value-from-the-database-and-convert-it-to-a-Java-object behavior? Other questions seem to indicate that this is impossible, but I find that very hard to believe.
Build your own conversion manager class (extend org.eclipse.persistence.internal.helper.ConversionManager).
and override the method convertObjectToBoolean().
To enable the usage of your own conversion manager instance in eclipselink, use a SessionCustomizer and invoke session.getPlatform().setConversionManager()
However, when looking at the source code of this method it seems that the support of the t and f literals is already implemented (at least in eclipselink 2.3.3). But maybe there's a bug?
It's may be worth debugging this method while your application is running to really see what's going on there.
Is there anything similar to Reflection.Emit.DynamicMethod in Cecil? Thanks.
DynamicMethod
Edit:
What about for the following things?
EmitCall (e.g.
IL.EmitCall(OpCodes.Callvirt, GetBuildKey, null);
IL.Emit(OpCodes.Unbox_Any, dependencyType);
)
LocalBuilder (e.g. LocalBuilder resolving = ilContext.IL.DeclareLocal(typeof(bool));)
System.Reflection.Emit.Label (e.g. Label existingObjectNotNull = buildContext.IL.DefineLabel();) //Do I have to use TextMap?
ILGenerator.BeginCatchBlock (e.g. ilContext.IL.BeginCatchBlock(typeof(Exception)); )
ILGenerator.MarkLabel (e.g. ilContext.IL.MarkLabel(parameterResolveFailed); )
ILGenerator.EndExceptionBlock() (e.g. ilContext.IL.EndExceptionBlock(); )
There's no way to create a DynamicMethod with Cecil, nor does it have an equivalent.
A DynamicMethod is strongly tied to the runtime, while Cecil is completely decoupled. The two of them have a completely separate type system. DynamicMethod are meant to be, well, dynamic, and as such have to use the System.Reflection type system, as it's the one available at runtime. Mono.Cecil has another representation of this type system suitable to static analysis, without having to actually load the assembly at runtime. So if you want to use a DynamicMethod, you have to use it along with its environment.
This question was originally asked, iirc, in the context of runtimes without DynamicMethods or SRE all-together, like the Compact Framework, where Cecil can be used to emit code at runtime.
Of course it's possible, but then you have to pay the price of loading the assembly, which is no small price on CF devices. It means that if you could somehow emulate a DynamicMethod by creating an assembly with only one static method with Cecil, it sounds a terrible idea. The assemblies would not be collectable (DynamicMethods are), making it a giant memory leak.
If you need to emit code at runtime on the Compact Framework, emit as less as possible, and emit as few assemblies as possible.
I'm currently investigating the use of FxCop with one of our existing projects and am getting an odd result.
The output displays a small number of breaches of the 'Override methods on comparable types' rule stating "'Log' should override Equals since it implements IComparable."
There are two issues with this:
I thought that it was only necessary to implement CompareTo when implementing IComparable (MSDN itself confirms this)
The class is not implementing IComparable but IComparable<T> and does impliment CompareTo as strongly typed.
So it FxCop (1.36) throwing a wobbly or is it my understanding thats out of whack here..?
Thanks in advance.
FxCop is a quite paranoidal tool... In this case, I suppose, it is trying to warn you, that you are changing the logic of comparison somehow and you shouldn't forget changing the equality logic if needed. You see, CompareTo method sometimes returns 0, which should be consistent with using Equals.
If this is not really your case, and you are sure you don't need any of the overloading (an example in MSDN shows that you will need to override all other equalty operators as well)... then just supress the warning or disable it.
I would override Equals,
just call base.Equals in your method
and add a comment explaining why the above is all that is needed
That way FxCop is happy, and so is the next programmer that looks at your code. (In a very few cases you can't do the above due to proforance problems, but these are rare these days.