Just installed Postsharp 2.1 from the nuget package and then installed Phil Haack's NullGuard package.
As I add the [EnsureNonNullAspect] aspect at either the class or method level I immediately get the following compiler warnings:
Warning 1 Missing optimization information on method'
NullGuard.PostSharp.EnsureNonNullAspect.OnEntry(
PostSharp.Aspects.MethodExecutionArgs)'.
This information is computed automatically by PostSharp.
Make sure that assembly NullGuard.PostSharp is processed by PostSharp
Warning 2 Missing optimization information on method
'NullGuard.PostSharp.EnsureNonNullAspect.OnExit(
PostSharp.Aspects.MethodExecutionArgs)'.
This information is computed automatically by PostSharp.
Make sure that assembly NullGuard.PostSharp is processed by PostSharp
It could be that this is nothing to worry about, but:
a) I don't like compiler warnings that I can't find the answer to anywhere on Google.
b) it could be something to worry about.
Any help would be most appreciated.
Cheers!
Tod.
It's because you're using the free version of PostSharp, which doesn't include the aspect optimization feature. See the comparison of features on PostSharp.net.
https://github.com/Haacked/NullGuard/issues/3
A bit late but I might have found a solution. I added the following tag in the project files that were raising the warnings:
<PropertyGroup>
<UsePostSharp>true</UsePostSharp>
</PropertyGroup>
This solved the issue to me.
This is because the library included in that NuGet package has not been processed by PostSharp.
Related
I starting to look into porting my application from Gtkmm 3.24 to Gtkmm 4.x (not sure which version yet). For now, I am only trying to understand what exactly is deprecated and how much work is needed for planning. One way to ease porting is to look into all deprecated usages in the Gtkmm 3.24 version and update them to the newer flavor before porting. I have found several macros that can help with that:
GTKMM_DISABLE_DEPRECATED
GDKMM_DISABLE_DEPRECATED
GLIBMM_DISABLE_DEPRECATED
GIOMM_DISABLE_DEPRECATED
When I #define these, the compiler throws error when meeting deprecated stuff because they have been disabled. This is nice, once the code is leveled up, to make sure the code stays free of deprecated usages.
In my case, however, the code is still full of deprecations and the compiler stops compilation on the first deprecation it meets. This does not help me much in understanding where the deprecations lie and how much work is needed. I could go about and solve every error, one by one, until there is no more (this is ultimately what I will do) but I can't know ahead how much time this will take.
What I would really like are macros that throw warnings when meeting deprecation, but let the compiler go on about building. This way I could get a list of everything that is deprecated in my codebase and plan work appropriately. I have browsed the Gtkmm documentation and codebase but found nothing.
Do such macros exist and if so, what are they?
The solution was to use
GTKMM_DISABLE_DEPRECATED
GDKMM_DISABLE_DEPRECATED
GLIBMM_DISABLE_DEPRECATED
GIOMM_DISABLE_DEPRECATED
like I did but to use the -k flag with make. From man make:
-k, --keep-going
Continue as much as possible after an error. While the target
that failed, and those that depend on it, cannot be remade, the
other dependencies of these targets can be processed all the same.
Source: Inkscape GTK+ 3 migration wiki page.
I'm trying to import an SPM package in Xcode11. I can fetch the library and see it in the project as Swift Package Dependencies but when trying to import, Xcode doesn't find it.
I read that the problem could be custom configurations and not the standard e.g. Debug.
Does anyone know how to solve this without renaming the configuration names?
The best advice at the moment is this post on the Swift forums where Ankit says:
This is a known issue that Apple folks are tracking internally. Currently, Swift packages default to the "Release" configuration when anything other than Debug and Release is used. In theory, adding $(BUILD_DIR)/Release to SWIFT_INCLUDE_PATHS build setting for the custom configurations should work around this issue but it can lead to some weird errors in case something unexpected gets picked from that directory.
Semantic issue: 'mutable' cannot be applied to references
The above is only the latest in a series of errors I've received attempting to get the fuego-iphone project to compile. I'm not certain, but it could be related to the way I compiled boost. The project's README recommends using these instructions for compiling boost into a framework, but I had already done so with the more recent instructions here. Could this CLANG error be related to a boost version somehow?
I admit relative ignorance when it comes to C++.
If anyone has any brilliant suggestions for using the fuego library in general with xcode, I have tried quite a few different things, and am pretty much at wit's end. Thanks!
EDIT: Apologies for any ambiguity here, but I'm not asking about mutable references, so much as showing the latest symptom of this issue. The fuego mailing list has a relevant question about using boost 1.48, and checking now, it's clear that I've compiled 1.49, so I'll recompile an earlier version of boost and see if that fixes it somehow.
The mutable modifier means that a field can be changed from within a const method. But for reference fields, that doesn't make any sense, because references can never be changed in C++.
Recompiling a C++ iPhone app with Xcode 4 I get this nasty linker error:
ld: bad codegen, pointer diff in __static_initialization_and_destruction_0(int, int)
to global weak symbol vmml::Vector2<float>::ZERO for architecture armv6
Anyone know what it means? How to make it go away would be nice too of course :)
The app compiled & linked without error in Xcode 3.
Edit: the solution is to set Symbols Hidden By Default to Yes in all the build settings of all targets in the project. Still none the wiser what the actual problem was.
The solution is to set Symbols Hidden By Default to Yes in all the build settings of all targets in the project. Still none the wiser what the actual problem was.
I had the same problem and also ended up adjusting the visibility settings. However, I was nervous just fiddling with symbol visibility and not understanding the problem, so I did a little more investigation.
If, like me, you're using Pete Goodliffe's script/package to build boost as a framework, the script sets default visibility to hidden (== yes). The visibility options change how symbols are marked by the compiler (default, hidden, internal). That information is used by the linker when making shared object elfs (shared libraries). It shouldn't apply here, so I suspect that this is a linker bug. Inside the boost library you have a weak symbol marked as hidden, and then in your project/another library, the same symbol marked as default. The linker is confused?
As for XCode 3 vs. 4, perhaps the default in 3 was to hide symbols?
In any case, changing default visibility to hidden should really have no effect with only static libs involved, so I feel a lot safer taking this route.
I've posted a few more details in a blog entry for those interested.
I ran into this problem while trying to include the boost libraries one of my projects. After finding this post, setting Symbols Hidden By Default to Yes also solved this issue for me. And I also had to make the same setting in each of the dependent projects to completely get rid of the error.
Just FYI - This only happened on my targets that were using the clang++ stack. GCC and LLVM+GCC targets do not seem to be affected.
Basically any symbols in a library you link to & your own code, need to use the same visibility level, i.e. if all the symbols in a library you include are hidden you need make sure the include files referencing the symbols in your project don't try and set it to visible. the safest way to do this is to have a constant level of default visibility across your project, for me it only became a problem with optimisations on.
Perhaps you are using a library that has hidden symbol information. If a symbol has not been exported from your library, and you attempt to use it externally, it results in a similar linker error. The correct solution would seem to be to find a way to make that symbol "visible" to the outside world via GCC macro definitions and/or modify the library itself to make sure that that particular symbol is truly "hidden" from the outside world --i.e. it isn't something that is ever used or exposed in a header file.
However, proceed with caution: according to Apple documentation, you should not hide some symbol information for a number of reasons; this one listed below seems to be the most alarming of the bunch:
If your symbol uses runtime type identification (RTTI) information, exceptions, or dynamic casts for an object that is defined in another library, your symbol must be visible if it expects to handle requests initiated by the other library. For example, if you define a catch handler for a type in the C++ standard library, and you want to catch exceptions of that type thrown by the C++ standard library, you must make sure that your typeinfo object is visible.
Source: http://developer.apple.com/library/mac/#documentation/DeveloperTools/Conceptual/CppRuntimeEnv/Articles/SymbolVisibility.html
Thus, if you want to catch an exception from the library you're linking against, hiding symbol information appears to be a bad choice. The correct solution would be to unhide the symbols of whatever library you're linking to. This can either be done by omitting the following GCC compiler flags:
-fvisibility=hidden --fvisibility-inlines-hidden
(the default visibility should be sufficient), or there are also compiler pragmas that allow you to do this. See: http://gcc.gnu.org/wiki/Visibility
are asserts removed in the resulting JavaScript of a GWT programm.
Regards,
Stefan
The GWT compiler removes them by default.
However there is a way to tell the compiler to keep them.
See here and here for more details.