Riverblade

Blog

Welcome to our blog. We hope that these pages provide an insight into us, our products and how we develop them. Please feel free to write to us if you have anything to add to any of the posts here.

Current Entries  Archives 

Visual Studio 2022 Preview 2

Wednesday, July 21, 2021

Visual Studio 2022 Preview 2 was released by Microsoft last week.

One of the changes included in Preview 2 is the addition of the Visual Studio 2022 specific v143 platform toolset (Preview 1 used the v142 platform toolset from Visual Studio 2019). Support for the v143 toolset has already been added to Visual Lint 8.0 and will soon become available within both VisualLintConsole and VisualLintGui in Visual Lint 8.0.3.

As part of that change, 8.0.3 will include a PC-lint Plus indirect file for Visual Studio 2022, and the Configuration Wizard and Options Dialog will both offer Visual Studio 2022 projects as an option:

Furthermore, since Preview 1 was released last month we have been gradually plugging away (no pun intended!) in the Visual Lint development branch, adding support for the VS2022 VSSDK COM interfaces along with new x64 build configurations where needed.

It's worth noting that although named identically, the VS2022 interfaces differ somewhat from their 32 bit predecessors so a lot of boilerplate changes have been required. However as we (fortunately, it turns out) use an in-house Visual Studio interfacing library to wrap the Visual Studio COM interfaces we use those changes have been largely localised to the support library itself - and that's made things a lot easier than it might otherwise have been.

Once that was done we turned our attention to the Visual Studio plugin project itself, by adding x64 build configurations to it and then gradually working through the code fixing the inevitable compilation and linker errors (mostly by conditionally compiling out 32 bit specific code, such as that relying on the add-in interfaces used with Visual Studio versions prior to VS2015).

We finally got a clean build on a dev machine this morning, and then turned our attention to adding a VS2022 VSIX package project, which is necessary to deploy a plugin (or "extension", in Microsoft terminology) to VS2022.

A few tweaks, some headscratching and more tweaks later, and just after lunch today Visual Lint not only successfully loaded under debug in a Visual Studio 2022 experimental instance for the first time but also analysed its first project under that environment:

Of course getting the plugin running under debug is just the first step - there is still much to do before we can release a public build with a VS2022 version of the Visual Studio plugin.

That said, getting to this point is hugely encouraging, so today has definitely been a good day.

Posted by Anna at 16:19 | Get Link

Visual Studio 2022 Preview 1

Monday, June 29, 2021

Ever since news broke in April of Microsoft's plans for Visual Studio 2022 we have been waiting to get our hands on a preview build of the new version.

The first public preview was finally released on 17th June, so naturally we have spent the past few days taking a look to see what we need to do - both to analyse codebases using it and to update our existing Visual Lint and ResOrg plugins to integrate within it.

Installed @VisualStudio 2022 Preview 1 to see what's changed on the VSIX extension front. #cplusplus #programming

The short answer is that VSPackages are now x64 (we knew this already), but it doesn't look like the proposed new out-of-proc extension architecture has landed yet. pic.twitter.com/MHwSoHUqIb

— Anna-Jayne Metcalfe 🌈🍦🏃‍♀️⚡️🦞🙉 (@annajayne) June 21, 2021

From what I can see, Visual Studio 2022 Preview 1 seems to use Visual Studio 2019 project files (the platform toolset is still v142, and _MSC_VER is still 1929). I've no doubt that will change in subsequent preview versions.

However, unlike its predecessor Visual Studio 2019, Visual Studio 2022 is a fully 64 bit development environment (although VS2019 and its predecessors can compile and debug 64 bit projects, the IDEs themselves are firmly 32 bit).

As such it follows that plugins for Visual Studio 2022 must also be compiled as 64 bit. Although the plug-in architecture is not changing in VS2022 (see The Future of Visual Studio Extensions), the move to 64 bit is a very significant change in itself.

For our Visual Studio plugin to run within VS2022, what we have to do is basically:

• Recompile the existing plugins to target the x64 platform, using the new (VS2022 specific) 64 bit Visual Studio COM interfaces and the new (and also VS2022 specific) version of the Visual Studio SDK.

• Add Visual Studio 2022 specific VSIX packages to deploy the x64 version of the plugins.

• Update the installers to recognise VS2022 and install the new x64 version of the plugin.

• Try not to break support for earlier Visual Studio versions in the process (those cannot load 64 bit plugins, so the existing 32 bit versions will still have to be maintained).

The full details of all of the changes involved are somewhat beyond the scope of this blogpost, but suffice it to say we have already started preparing to port the code to VS2022 and expect that to keep us busy over the summer.

(well, it's not as if anyone can really go on holiday right now, is it?)

The screenshots below show VS2022 Preview 1 with an AppWizard generated C++ VSIX extension project loaded and running. Note that I had to make a couple of minor corrections to the generated project and property files to get it to compile and link.

Posted by Anna at 12:49 | Get Link

Visual Lint 8.0.2.338 has been released

Monday, June 28, 2021

Visual Lint 8.0.2.338 has now been released. This a recommended maintenance update for Visual Lint 8.0, and includes the following changes:

• Updated the values of _MSC_VER and _MSC_FULL_VER in the PC-lint Plus compiler indirect file `co-rb-vs2019.lnt to support Visual Studio 2019 v16.10.0.

• Updated the values of _MSC_VER and _MSC_FULL_VER in the PC-lint Plus compiler indirect file co-rb-vs2017.lnt to support Visual Studio 2017 v15.9.36.

• Project (e.g. $(ConfigName) or ${ConfigName}) and environment (e.g. %COMPUTERNAME%) variables can now be used in the values of the "Analysis configuration" [PC-lint/PC-lint Plus], "Warning policy" [PC-lint/PC-lint Plus] and "Generate reports in..." properties of a solution/project specific analysis configuration. [Visual Lint Professional and Enterprise Editions]

• Project (e.g. $(ConfigName) or ${ConfigName}) and environment (e.g. %COMPUTERNAME%) variables can now be used in the values of the "Analysis tool installation folder", "Analysis tool executable", "When solution analysis completes..." and "Post-process PC-lint indirect (project.lnt) files after generation..." properties of a solution/project specific analysis configuration. [Visual Lint Enterprise Edition]

• Fixed a bug in the implementation of the Solution/Project Analysis Configuration Dialog "Analysis tool executable" property. [Visual Lint Enterprise Edition]

• Fixed a bug in the implementation of the Solution/Project Analysis Configuration Dialog "Warning policy" property. [PC-lint/PC-lint Plus] [Visual Lint Professional and Enterprise Editions]

• Modified the Visual Studio plug-in to prevent duplicated entries for projects from appearing in the Analysis Status Display (this could be caused by the IDE sourcing duplicated "ProjectAdded" events, and these are now filtered out).

• The Configuration Wizard "Analysis Tools" page no longer allows multiple analysis tools to be selected.

Download Visual Lint 8.0.2.338

Posted by Anna at 11:35 | Get Link

Visual Lint 8.0.1.337 has been released

Tuesday, April 20, 2021

Visual Lint 8.0.1.337 is a recommended maintenance update for Visual Lint 8.0. The following changes are included:

• If the Visual Studio plugin is selected for installation and the Visual Studio Debug Console (VsDebugConsole.exe) is running, the installer will now ask you to close it before installation can proceed.

• Updated the interface with IncrediBuild to support IncrediBuild 9.5.x. [also in Visual Lint 7.0.12.336]

• IncrediBuild analysis tasks can now be colour coded in the IncrediBuild Build Monitor from within the Visual Studio, Atmel Studio and Eclipse plug-ins. [also in Visual Lint 7.0.12.336]

• Fixed a bug which could cause duplicate IncrediBuild analysis tasks to be queued. [also in Visual Lint 7.0.12.336]

• Updated the prompt displayed if an IncrediBuild installation was not found when IncrediBuild analysis was enabled. [also in Visual Lint 7.0.12.336]

• Updated the values of _MSC_VER and _MSC_FULL_VER in the PC-lint Plus compiler indirect file co-rb-vs2019.lnt to support Visual Studio 2019 v16.4.4.

• Updated the values of _MSC_VER and _MSC_FULL_VER in the PC-lint Plus compiler indirect file co-rb-vs2017.lnt to support Visual Studio 2017 v15.9.35.

• Various corrections and updates to help topics.

Download Visual Lint 8.0.1.337

Posted by Anna at 16:35 | Get Link

Visual Lint 7.0.12.336 has been released

Tuesday, April 20, 2021

Visual Lint 7.0.12.336 is a recommended maintenance update for Visual Lint 7.0. The following changes are included:

• Updated the interface with IncrediBuild to support IncrediBuild 9.5.x.

• IncrediBuild analysis tasks can now be colour coded in the IncrediBuild Build Monitor from within the Visual Studio, Atmel Studio and Eclipse plug-ins.

• Fixed a bug which could cause duplicate IncrediBuild analysis tasks to be queued.

• Updated the prompt displayed if an IncrediBuild installation was not found when IncrediBuild analysis was enabled.

• Various corrections and updates to help topics.

Download Visual Lint 7.0.12.336

Posted by Anna at 16:35 | Get Link

Visual Lint 8.0 has been released

Saturday, March 27, 2021

The first public build of Visual Lint 8.0 has just been uploaded to our website. As of today, Visual Lint 8.0 replaces Visual Lint 7.0 as the current supported Visual Lint version.

As such Visual Lint 8.0 licences (as well as upgrades for Visual Lint 6.x and 7.x^* per user licences) will shortly become are now available in our online store.

^* Licences for Visual Lint 1.x through 5.x can be upgraded manually - please contact us for details.

Customers with active Visual Lint 7.x priority support subscriptions should already have received updated licence keys for the new version.

Visual Lint floating and site licence subscription customers have the option of continuing with Visual Lint 7.0 until their next renewal or updating to Visual Lint 8.0.

In addition, all customers who have purchased per-user or per-server Visual Lint licences since 1st January 2021 are also eligible to receive new Visual Lint 8.0 compatible licence keys.

If any of the above applies and you need a licence key compatible with Visual Lint 8.0 please contact us for details, quoting your order number and licence key.

Among the many changes included in Visual Lint 8.0 is the addition of support for Clang-Tidy - an open source C++ analysis tool from the LLVM Project which is notable for its ability to automatically correct many of the issues it finds.

You can read more about the integration of Clang-Tidy into Visual Lint in the blogpost Clang-Tidying up the house.

The following changes are included in Visual Lint 8.0:

Host Environments:

• Projects whose physical location is defined using system environment variables within Visual Studio, AVR Studio 5.0 or Atmel Studio solutions (.sln, .avrsln or .atsln) files can now be loaded correctly.

• Improved support for Eclipse project/build variables. In particular, variables of the form ${workspace_loc:/<projectname>/<resource_path>} and ${workspace_loc:/${ProjectName}/<resource_path>} should now be resolved correctly, even if the project is physically located outside of the workspace folder and <resource_path> is a linked resource.

• Updated the values of _MSC_VER and _MSC_FULL_VER in the Visual Studio 2017 PC-lint Plus compiler indirect file co-rb-vs2017.lnt to support VS2017 v15.9.34.

• Updated the values of _MSC_VER and _MSC_FULL_VER in the Visual Studio 2019 PC-lint Plus compiler indirect file co-rb-vs2019.lnt to support VS2019 v16.9.2.

Analysis Tools:

• Added support for the Clang-Tidy analysis tool. Clang-Tidy is an open source C++ analysis tool from the LLVM Project which is especially notable for its ability to automatically fix some of the analysis issues it detects.

• Updated the PC-lint Plus message database to reflect changes in PC-lint Plus 1.4.

Installation:

• Added PC-lint Plus library indirect files lib-rb-stl.lnt and lib-rb-boost.lnt.

• The PC-lint Plus library indirect file lib-rb-win32.lnt no longer includes tuning directives for the ATL, WTL and MFC libraries - instead, dedicated indirect files for these libraries (lib-rb-atl.lnt, lib-rb-wtl.lnt and lib-rb-mfc.lnt respectively) are now supplied.
  
  If you analyse ATL, WTL or MFC code your PC-lint Plus analysis configuration will need to be updated accordingly. The implementations of lib-rb-win32.lnt for PC-lint 8.0 and 9.0 are unaffected.

Configuration:

• Added a "Exclude files matching these wildcard masks" option to the Advanced Analysis Options Dialog. This can be used to (for example) automatically exclude generated files such as Qt moc_*.cpp files from analysis. Multiple masks can be specified by delimiting them with semicolons.

• Revised the .vlconfig file format. The changes are backward compatible, so old format files can still be read and will be updated when saved.

• Analysis Configuration files now include the name and major/minor version of the product which wrote them. Note that the full build version is not included, as that could cause unnecessary diffs in the resultant .vlconfig files.

• Added the ability to override the preprocessor symbol and include folder properties of arbitrary project types using the Project Properties Dialog. This allows the analysis configuration of a project to be further customised (e.g. by injecting additional preprocessor symbols) without affecting the build environment. If the properties of the project are overridden in this way, a <projectfilename>.vlproj file will be written alongside the project file to store the overridden properties. [Visual Lint Professional, Enterprise and Build Server Editions]`

• Various changes to the implementation of options.

Analysis:

• The "Auto" value of the Maximum background analysis tasks option now allocates threads at 75% of the CPU logical core count.`

• Manual analysis can now optionally automatically fix some detected issues. To enable this option, select Clang-Tidy as the active analysis tool and check the "Apply suggested fixes" option in the Clang-Tidy Analysis Configuration Dialog. [Visual Lint Enterprise and Build Server Editions]`

User Interface:

• Added the Clang-Tidy Analysis Configuration Dialog, which contains a variety of options for configuring Clang-Tidy analysis. For example, the dialog allows header and line filters to be defined and includes options to define which Clang-Tidy checks are active.

• The Issue Documentation Display can now show documentation for CppCheck and Clang-Tidy issues.

• Replaced the TeeChart charts in the Analysis History and Results Displays with JqPlot (Javascript) equivalents as already used in HTML analysis reports. As part of this change the "Stacked Bar Chart" view has been removed from the Analysis History Display.

• The Project Properties Dialog (and comments within generated project indirect ("project.lnt") files) now explicitly shows any project variables within the system include path unless the "Use VS2012/VS2010 system headers for compatibility with PC-lint 9.00L or earlier" option on the "Analysis Tool" Options page is active.

• The Property List Dialog now filters out blank lines when displaying include folder paths etc.

• The Project Variables Dialog now displays IAR Embedded Workbench format variables (e.g. $PROJ_DIR$) correctly.

• The Analysis Results Display "Raw Analysis Results" view now attempts to normalise newlines for display purposes. This affects the Clang-Tidy analysis tool specifically, as it can generate output with a mixture of line endings.

• The CppCheck Analysis Configuration Dialog "Checks" control is now an MRU combo box.

• The Send Feedback Dialog is now modeless.

• The Active Analysis Tool Dialog is now resizable and its contents sortable. In addition the meaning of the "Status" column has been made clearer.

• The Advanced Analysis Options Dialog is now resizable.

• The Configuration Wizard is now resizable.

• The CppCheck Analysis Configuration Dialog is now resizable.

• The Options Dialog is now resizable.

• Display filters are now host and toolchain independent.

• Moved code editor marker options from the "Displays" Options page to the "Editor" Options page.

• Removed the "Auto-show the Analysis Results Display when analysis results are available" option from the "Displays" Options page.

• Moved the "Check for new blogposts" option from the "Displays" Options page to the "Updates" Options page.

• When a solution/workspace is closed, the displays are now cleared first and (in VisualLintGui only) a "Solution Closed" message written to the Status Bar when the process is complete.

Commands:

• The "Insert Directive" command on the Analysis Results Display context menu can now also be used to suppress Clang-Tidy analysis issues.

• The "Lookup Meaning" command on the Analysis Results Display context menu is now available when analysing with CppCheck or Clang-Tidy.

• Added an "Apply Fixes" command to the Analysis Status Display context menu. This command applies all fixes identified by Clang-Tidy to the selected implementation files.

• Added a "Troubleshooting | View Fixes" command to the Analysis Status Display context menu. This command displays the contents of the Clang-Tidy .fixes file (if any) corresponding to the selected implementation file. These are YAML files associated with the clang-apply-replacements tool and which contain details of the issues Clang-Tidy has identified - and any changes it identified to fix them.

Bug Fixes:

• Fixed a bug in the expansion of project variables in multi-field strings where more than one field expands to the same variable. This manifested in Visual Studio 2019 where the include path "$(VC_IncludePath);$(WindowsSDK_IncludePath)" only expanded the first instance of $(WindowsSdkDir).

• Fixed a bug which could affect the parsing of VisualDSP project files in the 64 bit version of VisualLintConsole.

• Fixed a crash which which could occur while generating a Clang-Tidy command line for a standalone source file which is not part of any project.

• Fixed a bug in the Analysis Results Display charts when rendering summaries of issues with embedded quotes in the issue title.

• Fixed a bug in the Analysis Statistics Display which could cause some issues to be incorrectly displayed with the wrong issue category. The bug was identified while adding support for Clang-Tidy to the display.

• Fixed a bug in the Analysis Status Display "Delete Analysis Results" context menu command which could cause an analysis task to be created for a file which was excluded from background analysis.

• Fixed a bug which could prevent affected source files from being marked as stale when a header file was changed. The bug was identified while adding support for Clang-Tidy.

• Fixed a bug which could cause uncommitted changes in the Property List Dialog to be lost if the "Expand project variables" checkbox was checked.

• Fixed a bug in the x64 build of the Eclipse plugin.

• Fixed a minor bug in the "Command Line" Options page.

• Parsing operations on MSBuild project files can now be aborted part way through. This should make certain operations (e.g. changing configurations immediately after loading a solution) more responsive.

• The Display Filter will no longer automatically attempt to suppress instances of issue 974 (note -- worst case stack usage...) if the active analysis tool is not either PC-lint or PC-lint Plus.

• The Solution/Project Analysis Configuration Dialog now resizes correctly.

• Corrected the tab order of the Solution/Project Analysis Configuration Dialog.

Download Visual Lint 8.0

Posted by Anna at 12:45 | Get Link

Visual Studio crashes when docking windows (TL;DR: it wasn't us)

Monday, February 22, 2021

We've all done it. You prepare a new build, install it, start testing before releasing it and then...it crashes. The immediate thought is always "What have we done...?".

Exactly that happened to us recently when testing a Visual Lint build - all we did was dock a window and then Visual Studio crashed and restarted.

Oops.

So, what had we done? As it turns out, nothing - the crash was actually caused by a Windows 10 update - and happened irrespective of whether any third party extensions are installed. KB4598301 is reportedly the cause, though others (e.g. KB4598299) also seem to cause the same effects.

The following community post has more details of the bug and possible workarounds:

https://developercommunity.visualstudio.com/content/problem/1323017/unexpected-vs-crash-when-docking-or-splitting-wind.html

We have no doubt that Microsoft will fix this very soon (in Visual Studio 2017 and 2019, at least) so for now we're not too worried, but in the meantime - or if you're using an older version of Visual Studio - the workarounds are to uninstall the update, or edit devenv.exe.config.

If you decide to do the latter, check to see if the if the configuration/runtime/AppContextSwitchOverrides element exists. If it does append the following to its value:

    ;Switch.System.Windows.Interop.MouseInput.OptOutOfMoveToChromedWindowFix=true;
     Switch.System.Windows.Interop.MouseInput.DoNotOptOutOfMoveToChromedWindowFix=true

If however the element does not exist (it may not for older versions of Visual Studio), you can just add it:

    <AppContextSwitchOverrides
      value="Switch.System.Windows.Interop.MouseInput.OptOutOfMoveToChromedWindowFix=true;
             Switch.System.Windows.Interop.MouseInput.DoNotOptOutOfMoveToChromedWindowFix=true" />

Once you restart Visual Studio you should then be good to go.

Posted by Anna at 12:07 | Get Link

Visual Lint 7.0.11.332 has been released

Tuesday, February 2, 2021

This is a recommended maintenance update for Visual Lint 7.0. The following changes are included:

• Updated the values of _MSC_VER and _MSC_FULL_VER in the PC-lint Plus compiler indirect file co-rb-vs2017.lnt to reflect those in the latest Visual Studio 2017 update (VS2017 v15.9.31).

• Updated the values of _MSC_VER and _MSC_FULL_VER in the PC-lint Plus compiler indirect file co-rb-vs2019.lnt to reflect those in the latest Visual Studio 2019 update (VS2019 v16.8.4).

• The project variables $(CEVER), $(ARCHFAM) and $(_ARCHFAM_) are now automatically defined when analysing Visual Studio 2008 projects for the WEBMAINT_SDK (ARMV4I) platform.

Download Visual Lint 7.0.11.332

Posted by Anna at 15:15 | Get Link

Visual Lint 7.0.10.329 has been released

Monday, January 4, 2021

This is a recommended maintenance update for Visual Lint 7.0. The following changes are included:

• The ${eclipse_home} and ${software_location} project variables are now defined when parsing S32 Design Studio for ARM projects.

• Any project variables of the form ${VARNAME} which Visual Lint cannot expand will now be converted to the standard OS format (i.e. %VARNAME%) before any properties referencing them are written to a PC-lint or PC-lint Plus project indirect (project.lnt) file. This allows the values of Eclipse project variables to be defined as system environment variables and (for example) injected using the PC-lint/PC-lint Plus -setenv() directive if necessary.

• Fixed a bug in the generation of PC-lint/PC-lint Plus command lines for projects containing per-file preprocessor definitions.

• Fixed a bug in the generation of analysis command lines containing preprocessor definitions whose values contain quotes. The bug affected analysis command lines for PC-lint, PC-lint Plus and CppCheck.

• Fixed a bug which could prevent VisualLintGui code editor views from reflecting changes to files which have been externally modified.

Download Visual Lint 7.0.10.329

Posted by Anna at 10:14 | Get Link

Visual Lint 7.0.9.324 has been released

Wednesday, September 16, 2020

This is a recommended maintenance update for Visual Lint 7.0. The following changes are included:

• When a custom report folder is defined in the Options Dialog "Reports" page, generated reports will now be written into subfolders identifying the solution/workspace, analysis tool and analysed solution/workspace configuration rather than just the solution/workspace name. This allows analysis reports for the same project but using different analysis tools or configurations to co-exist without overwriting each other.

• Fixed a bug in the persistence of the "Generate reports in..." report options in the Options Dialog "Reports" page.

• Updated the PC-lint Plus message database to reflect changes in PC-lint Plus 1.3.5.

Download Visual Lint 7.0.9.324

Posted by Anna at 12:33 | Get Link

Visual Lint 7.0.8.322 has been released

Thursday, July 16, 2020

This is a recommended maintenance update for Visual Lint 7.0. The following changes are included:

• Fixed a crash in the Analysis Results Display if the "Report" button was used when the "All Files" view was selected.

• Fixed a bug which could cause charts to fail to render in analysis reports.

• Fixed a bug in the MSBuild project file parser which could cause some MSBuild property groups to be incorrectly parsed.

• Fixed a bug in the Advanced Analysis Options Dialog which affected VisualLintConsole.

• The PC-lint/PC-lint Plus "Compiler Configuration" Configuration Wizard page no longer shows indirect files which are used as part of the implementation of other PC-lint Plus compiler indirect files.

• Fixed minor display bugs in the PC-lint/PC-lint Plus "Information", "Compiler Configuration", "Analysis Configuration File" and "Warning Policy File" Configuration Wizard pages.

• If the active analysis tool is anything other than PC-lint or PC-lint Plus the nonfunctional "Issues" page in the Category Properties Dialog is now hidden.

Download Visual Lint 7.0.8.322

Posted by Anna at 09:10 | Get Link

Clang-Tidying up the house

Tuesday, May 19, 2020

If there is any single consolation amidst the circumstances we are all having to cope with at the moment it is that many of us have lots of time to fill - not only with unproductive things like binging Netflix (I really should get around to watching Dirk Gently's Holistic Detective Agency...) but also with tasks which might have a more lasting long-term benefit.

Those could be tasks like learning a language (programming or human), joining online yoga classes, writing a book, designing a website, blogging, reading (I can recommend Francis Buontempo's Genetic Algorithms and Machine Learning for Programmers if you fancy learning a little about ML) or generally just getting on with stuff with perhaps fewer distractions than usual.

On the latter note, for the past few months we've been working on the codebase of the next version of Visual Lint in our development branch, and it is coming along quite nicely.

One of the things we have planned to do for some time is to add direct support for the Clang-Tidy analysis tool to Visual Lint. When the UK lockdown started, focusing on this task in particular proved to be a very useful distraction from all the fear and uncertainty we found around us.

Sometimes being in the zone helps in more ways than usual.

The screenshot above should give you an idea of where we are at the moment. Whilst there is still a great deal to do before we can consider this is production-ready the foundation is in place and it is definitely usable. For example, selected issues can already be suppressed from the Analysis Results Display by inserting inline suppression directives ("// NOLINT") using the same context menu command used to suppress (for example) PC-lint, PC-lint Plus and CppCheck analysis issues.

With Microsoft Visual Studio being one of the major development environments we support one of the most important things to address is configuring Clang-Tidy to be tolerant of non-standard Visual C++ projects. The errors shown for some files in the Analysis Status Display in the screenshot above are exactly because of this - a standards compliant C++ compiler is likely to generate at least some errors while compiling most Visual C++ projects.

The only error we saw in the Visual C++ project mentioned above was: clang-diagnostic-error: -- call to non-static member function without an object argument.

The StackOverflow topic Refactor MFC message maps to include fully qualified member function pointers discusses exactly the same issue.

This is mitigated by the fact that recent versions of Clang-Tidy do a pretty good job of handling nonstandard code, so the things that Clang-Tidy warns about seem to be exactly the sort of things you would expect it to and a fair degree of tuning is possible. For example, the clang-diagnostic-error issues in the case above could be disabled entirely if that was what you wanted (as it's a trivial fix you could alternatively choose to correct the code).

Furthermore, with the C++ Core Guidelines checks enabled (e.g. using the --checks=modernize-* switch) Clang-Tidy can tell you exactly what you could do to your C++ code to bring it up to modern standards.

We will obviously be talking more about Clang-Tidy in due course - particularly once we start looking at using it to automatically correct the issues it finds (if you are not aware, this is one of the most compelling features of Clang-Tidy. The good news is that autofixing selected issues should be fairly straightforward using the output of the Clang-Tidy --export-fixes switch.

Lockdowns or eased lockdowns, more interesting times lie ahead.

Posted by Anna at 09:59 | Get Link

Visual Lint 7.0.7.318 has been released

Tuesday, April 21, 2020

This is a recommended maintenance update for Visual Lint 7.0. The following changes are included:

• The Visual C++ built-in preprocessor symbol _MSC_VER is now defined on the generated CppCheck command line when analysing Visual Studio 2019 projects.

• Appropriate defaults (e.g. the compiler indirect file co-rb-vs2019.lnt) are now offered when creating a PC-lint Plus analysis configuration for Visual Studio 2019.

• Updated the values of _MSC_VER and _MSC_FULL_VER in the PC-lint Plus compiler indirect file co-rb-v2017.lnt to reflect those in the latest Visual Studio 2017 update (VS2017 v15.9.21).

• Updated the values of _MSC_VER and _MSC_FULL_VER in the PC-lint Plus compiler indirect file co-rb-vs2019.lnt to reflect those in the latest Visual Studio 2019 update (VS2019 v16.5.1).

• Fixed a bug in the Configuration Wizard "Select Analysis Tool Installation Folder" page.

• Fixed a bug in the implementation of the "Active Analysis Tool" option.

• Fixed a bug in the implementation of the .vlconfig file "Solution specific Analysis Tool" property [Visual Lint Enterprise and Build Server Editions]`.

• Fixed a display bug in the Configuration Wizard "Information" page. Note that this page is PC-lint and PC-lint Plus specific.

• Corrected the title of the "PC-lint" page in the Analysis Configuration Dialog to "PC-lint Plus" when the active analysis tool is PC-lint Plus.

Posted by Anna at 09:41 | Get Link

COVID-19 Lockdown Blues

Wednesday, April 15, 2020

2020 is not turning out to be what we expect as - like much of the world - the UK is locked down right now as a result of the COVID-19 pandemic. As such we have been working from home for the past month and only going out for essentials.

That means no ACCU Conference, no free coffee in the office, no impromptu meetings on the beach or on our astroturfed office roof (yes, it does look like that!), no aerial yoga (cue sad face from Anna) but a whole lot of Zoom, configuring VPNs, being thankful for distributed version control systems, kicking off builds remotely and so on.

As far as Riverblade goes, it's rather fortunate that we have been set up for remote working from the outset, so from one point of view the lockdown hasn't come as a big change - although like everyone else we're really missing friends, family...and just simple experiences like going to a cafe at lunchtime or buying an ice cream at the seafront.

Quite frankly it sucks. But you already know all that - and if it saves lives, it is a tiny price to pay. We can only hope that politicians will take heed of the warnings from scientists, nurses, doctors and people who actually know what they are talking about, and that whatever we each endure proves to be enough to stop this virus in its tracks.

Needless to say our thoughts are with everyone touched by this pandemic - but especially with those who have lost loved ones and with anyone working in health and social care.

Be safe, people.

Posted by Anna at 11:54 | Get Link

Visual Lint 7.0.6.316 has been released

Tuesday, March 3, 2020

This is a recommended maintenance update for Visual Lint 7.0. The following changes are included:

• Fixed a bug in the parsing of Visual Studio MSBuild expressions using the [MSBuild]::GetDirectoryNameOfFileAbove() function which was preventing the system include folder path from being read correctly in Visual Studio 2019 v16.4.4.

• Updated the values of _MSC_VER and _MSC_FULL_VER in the PC-lint Plus compiler indirect file co-rb-vs2019.lnt to support Visual Studio 2019 v16.4.4.

• Modified the PC-lint Plus Visual Studio 2019 compiler indirect file co-rb-vs2019.lnt to suppress an instance of error 4392 (constexpr declaration follows non-constexpr declaration) in the header file $(VCToolsInstallDir_160)\include\intrin0.h.

• Added help documentation for the fields (e.g $(index), $(SourceFile) and $(LineNo)) which can be used in exported analysis results files.

• Updated the helpfile to explicitly reference the PC-lint Plus analysis tool throughout.

• Added a "PC-lint/PC-lint Plus multipass analysis" help topic.

• Updated links within the online help as necessary.

Posted by Anna at 11:05 | Get Link

Visual Lint 7.0.5.314 has been released

Thursday, January 23, 2019

This is a recommended maintenance update for Visual Lint 7.0. The following changes are included:

• If an output report folder is specified on the command line and its path is relative, VisualLintConsole now resolves it before starting analysis. This ensures that the path referenced in any status/progress messages is is unambiguous.

• Fixed a bug in VisualLintConsole in the copying of Javascript baggage files to the (optional) output report folder.

• Fixed a minor display bug in the VisualLintGui "Projects" Display.

Posted by Anna at 12:00 | Get Link

Visual Lint 7.0.4.313 has been released

Tuesday, December 3, 2019

This is a recommended maintenance update for Visual Lint 7.0. The following changes are included:

• Added support for wildcards to the text filters in the Analysis Status, Analysis Statistics, Analysis Results and Stack Usage Displays and Display Filter Dialog.
  
  This allows (for example) files to be easily excluded from analysis by using a wildcard text filter in the Analysis Status Display.

• Added a /writevlconfigfiles switch to VisualLintConsole to allow the user to use VisualLintConsole to incrementally update analysis configuration (.vlconfig) file(s) for the current solution/workspace/project.

• Added the environment variable _RB_CONFIGURATION to the generated PC-lint/PC-lint Plus command line. This includes the name of the configuration, and like _RB_PLATFORM can be used to dynamically select options within an indirect (.lnt) file.

• The "Delete Analysis Results" command now correctly deletes per-project analysis results and report baggage files.

• Improved a prompt which was shown by the Configuration Wizard if it was unable to write any affected files on completion.

• Locked out the program information (+program_info) option on the Command Line Options page if the active analysis tool is PC-lint Plus, as this directive is currently PC-lint 9.0 specific.

• Generated PC-lint Plus command lines now escape the pathname of the stack usage report file if it contains quotes (generated PC-lint 9.0 command lines are unaffected as spaces in the pathname do not cause issues for it).

• Fixed a bug in the parsing of ExcludedFromBuild attributes in Visual C++ 2010-2019 (.vcxproj) project files.

• Fixed a bug which affected projects containing more than one file with the same name.

• Fixed a bug in the parsing of cpplint analysis results of the format: "<filename>&lpar;<lineno>&rpar;: error cpplint: [<ID>] <description> [<category>]".

• Corrected a help topic.

Posted by Anna at 10:23 | Get Link

Visual Lint 7.0.3.311 has been released

Tuesday, September 24, 2019

This is a recommended maintenance update for Visual Lint 7.0. The following changes are included:

• Fixed a bug in the Visual Studio 2017/2019 installation process which can cause an invalid filename to be specified for VSIX logfiles written to the %TEMP% folder.

• The timestamps of any property (.props, .targets or .vsprops) files referenced by a Visual Studio project are now taken into account when determining whether a new PC-lint/PC-lint Plus indirect (.lnt) file needs to be written.

• Added a breadcrumb bar to HTML solution, project and file reports to make navigating to the report for the parent entity (e.g. from file to project) easier.

• Fixed a bug which could cause an invalid -setenv() directive to be generated on the PC-lint Plus analysis command line if a platform name referenced in a project contained one or more spaces.

• Replaced the "invalid key entered" balloon tip in the Registration Key Dialog with an inline text field.

• Added a missing help topic.

Posted by Anna at 12:24 | Get Link

Visual Lint 7.0.2.310 has been released

Wednesday, July 24, 2019

This is a recommended maintenance update for Visual Lint 7.0. The following changes are included:

• Added a +rw(noexcept) directive to the Visual Studio 2015 and 2017 PC-lint 9.0 compiler indirect files co-msc140.lnt and co-rb-vs2017.lnt respectively. This allows code which uses the noexcept keyword to be analysed more cleanly.
  As PC-lint 9.0 does not officially support modern C++ code other analysis errors may still occur when you analyse modern C++ code with PC-lint 9.0. As such we recommend that you update to PC-lint Plus to analyse code for modern C++ compilers such as GCC 4.x/5.x or Visual Studio 2013/15/17/19. Please contact us for details.

• Fixed a bug in the installer which could prevent the Visual Studio plug-in from being installed to Visual Studio 2019.

• Fixed a bug in the VisualLintGui Products Display "Add Existing File" context menu command.

• Fixed a bug in the update check process which could result in incorrect text being displayed for a major update (e.g. to Visual Lint 7.x) [also in Visual Lint 6.5.8.309].

Posted by Anna at 10:41 | Get Link

Visual Lint 7.0.1.308 has been released

Monday, June 10, 2019

This is a recommended maintenance update for Visual Lint 7.0. The following changes are included:

• System include folder and for loop compliance settings can now be read from Visual Studio 2019 project files which use the v142 toolset.

• Device specific includes (e.g. "<ProjectFolder>/RTE/Device/TLE9879QXA40") are now read when loading Keil uVision 5 projects.

• Updated the value of _MSC_FULL_VER in the PC-lint Plus compiler indirect files for Microsoft Visual Studio 6.0, 2008, 2010, 2012, 2013, 2015, 2017 and 2019 to reflect the version of the most recent update of the compiler shipped with each. Also enabled C++ 17 support (-std=c++17) with Visual Studio 2017 (VS2017 update 9.4 is C++ 17 complete) and Visual Studio 2019.

• Removed an erroneous directive from the PC-lint Plus library indirect file rb-win32-pclint10.lnt (an implementation file invoked by lib-rb-win32.lnt).

• Fixed a bug in the Analysis Tool Options Page which could prevent the "Browse for installation folder" button from working correctly.

• Fixed a bug in the Project Properties Dialog which affected the editing of configurations within custom projects.

• Fixed a bug in the VisualLintGui Products Display "Remove File" context menu command.

• The Configuration Wizard "Select Analysis Tool Installation Folder" page no longer indicates that you can buy PC-lint licences from Riverblade as this analysis tool has now been superseded by PC-lint Plus.

• VisualLintGui now displays the correct page title when loading the "Blog" page on the Riverblade website.

• Fixed a typo in the "Product Not Configured" dialog.

Posted by Anna at 10:44 | Get Link

ResOrg 2.0.8.28 has been released

Wednesday, June 5, 2019

This is a maintenance update for ResOrg 2.0. The following changes are included:

• Added support for Visual Studio 2019 to the Visual Studio plug-in (note that the standalone ResOrg application already supported VS2019 projects).

• Various minor updates to the documentation, readme etc.

Download ResOrg 2.0.8.28

Posted by Anna at 10:50 | Get Link

Visual Lint 7.0 has been released

Saturday, March 30, 2019

The first public build of Visual Lint 7.0 has just been uploaded to our website.

As of today, Visual Lint 7.0 replaces Visual Lint 6.5 as the current supported Visual Lint version. Customers with active Visual Lint 6.x priority support, floating and site licence subscriptions should shortly receive updated licence keys for the new version, and upgrades for Visual Lint 5.x and 6.x per user licences will become available in our online store soon. Older editions can be upgraded manually - please contact us for details.

In addition, most customers who have purchased per-user Visual Lint licences since the start of January will shortly receive new Visual Lint 7.x compatible licence keys.

Full details of the changes in this version are as follows:

General:

• Replaced Visual Lint Standard Edition with Visual Lint Personal Edition.
  
  Note: Visual Lint Personal Edition is licenced for use by individual and freelance developers rather than organisations. If your organisation has more than one member of staff, you must use Visual Lint Professional Edition or above.
  
  As such organisations which have purchased Standard Edition licences in the past must upgrade them to Visual Lint 7.x Professional Edition or above if they wish to use Visual Lint 7.x.
  
  See Visual Lint Product Editions for details of the available product editions.

Host Environments:

• Added support for Microsoft Visual Studio 2019 to the Visual Studio plug-in. VisualLintGui and VisualLintConsole have also been updated to support Visual Studio 2019 solution and project files.
  
  Note: Support for the v142 toolset is not yet complete so you may (for example) find that you need to add details of the Visual Studio 2019 system include folders to your PC-lint Plus std.lnt file in order that your analysis tool can locate system include files.

• Removed support for Windows XP, Windows Vista and Windows Server 2003 (although the software should still function on these platforms, we no longer test on them).

Analysis Tools:

• PC-lint Plus is now recognised as a distinct analysis tool from PC-lint 8.0/9.0. As a result it is now straightforward to switch between the two products.

• Added PC-lint Plus specific compiler indirect file co-rb-vs2019.lnt for Visual Studio 2019.

• The environment variable _RB_PLATFORM on the generated PC-lint Plus command line now includes the string name of the platform rather than an enumerated value.

• Added the environment variable _RB_TOOLCHAIN to the generated PC-lint Plus command line. This is used to determine which compiler indirect file to use in Atmel Studio projects where the AVR platform (which can be either 8 bit or 32 bit) is used. In such cases the toolchain (e.g. 'com.Atmel.AVRGCC32') is unambiguous and can be used instead.

• Added a PC-lint Plus indirect file (co-rb-as7.lnt) for Atmel Studio 7.x to the installer. This conditionally invokes compiler indirect files for either ARM (32 bit), AVR (8 bit) or AVR (32 bit) compilers based upon the active platform and toolchain.

• Added additional PC-lint Plus suppression directives to the indirect file lib-rb-win32.lnt supplied within the installer.

Installation:

• The installer will now ask you to close third party development environments (devenv.exe, atmelstudio.exe, eclipse.exe etc.) before installation can continue only if the corresponding plugin is selected for installation.

• Removed the PC-lint 8.0 message database.

Configuration:

• If it has not yet been configured, Visual Lint no longer prompts to run the Configuration Wizard when it is started. Instead, the user is prompted only when they attempt to start manual or background analysis.

Analysis:

• When a Visual Studio solution is loaded, the version reported is now that corresponding to the highest version of platform toolset in the solution. e.g. If a Visual Studio 2019 project contains Visual Studio 2015 and 2017 projects, the solution will be reported as being for Visual Studio 2017 for analysis purposes.

User Interface:

• The elapsed time in the Manual Analysis Dialog is now displayed in minutes and seconds rather than just seconds.

• Increased the size of the "Active Analysis Tool" and "Options" dialogs.

• The Message Lookup View can now switch dynamically between message databases for PC-lint and PC-lint Plus.

• Revised Configuration Wizard page text to differentiate between PC-lint and PC-lint Plus where appropriate.

• "Project" nodes in the VisualLintGui Projects Display now include details of the active configuration and project type in the same way as the root "Solution" node.

• The Analysis Status, Statistics, History and Results Displays now indicate the name of the active analysis tool.

Bug Fixes:

• Fixed a potential crash in the Analysis Results Display.

• Fixed a bug which prevented PC-lint Plus analysis from being run on an IncrediBuild grid.

• Fixed a couple of bugs in the Configuration Wizard which affected PC-lint Plus.

• Fixed a bug in some of the displays which could cause one of the columns to be oversized.

• PC-lint Plus user defined messages (8000-8999) are now correctly categorised as informational.

• Fixed a bug which could cause PC-lint Plus command lines containing the obsolete PC-lint +linebuf or +macrobuf directives to be generated if the analysis tool was set to PC-lint but the analysis tool installation folder was overridden to point to a PC-lint Plus installation folder.

Download Visual Lint 7.0

Posted by Anna at 10:50 | Get Link

New website and chips, please

Tuesday, March 19, 2019

If you are reading this you might have noticed that the Riverblade website has undergone a bit of a redesign.

This is something we've been working on for a little while in the background, and we think it's probably now at least good enough to let loose on the world. We hope that you find the new responsive website to be an improvement on the old one.

Template aside, the design and implementation was done in-house, so it's entirely our own work and therefore any bug/content fixes should be relatively quick (as an aside, we did contract out a redesign a while back, but we never released it because we weren't happy with the designs the external consultancy produced).

Along with the new design, we've also moved most of the content to a new domain - riverblade.co.

We've tried to make all of the redirects automatic, but needless to say if you discover any broken links, typos etc. please do let us know.

(and in case you are wondering: we have indeed been known to celebrate finishing a project with Prosecco, fish and chips).

Posted by Anna at 15:03 | Get Link

Gimpel's New Website

Thursday, October 25, 2018

Gimpel Software (the vendor behind PC-lint and PC-lint Plus) <have recently updated their website, and it is now dedicated entirely to PC-lint Plus. If you are considering upgrading from PC-lint 9.0 to PC-lint Plus, the relevant information is available at PC-lint Plus for PC-lint/FlexeLint users.

The new website also includes an interactive demonstrator for PC-lint Plus, which allows you to try it out on sample C++ 11/14/17 or C89/99/11 code:

At the moment the demonstrator only includes compiler configurations for Visual Studio 2013 and 2015, but please don't let that put you off as it can work with most compilers including those based on GCC.

Also noteworthy is the following statement:

How long will PC-lint/FlexeLint Version 9 be supported?

PC-lint/FlexeLint Version 9 are no longer being maintained. The final update was Version 9.00L, released in 2014. Technical support will be provided for these products through the end of 2018.

That being the case, we intend to remove PC-lint 9.0 from our online store shortly. Gimpel are selling PC-lint Plus licences directly rather than via resellers, so if you need a quote for a PC-lint Plus licence please contact sales@gimpel.com for details or use the links below.

Useful links:

• Static Analysis with PC-lint Plus

• PC-lint Plus for PC-lint/FlexeLint users

• Interactive Demo

• Evaluate PC-lint Plus

• Order PC-lint Plus

• PC-lint Plus Support

• New PC-lint Plus Community Forum

If you have any queries, please let us know.

Posted by Anna at 11:43 | Get Link

LintProject Pro End of Life Notice

Tuesday, October 23, 2018

LintProject Pro is a command line only product which can perform a basic per-file analysis of a C/C++ codebase using PC-lint or CppCheck. In many ways it was the proof of concept for Visual Lint, and although it has served us well, it's getting a bit long in the tooth now.

For example, unlike Visual Lint Build Server Edition (which has inherited its capabilities), LintProject Pro only makes use of a single CPU core when running analysis and doesn't support current analysis tools such as PC-lint Plus.

The interfaces to the two products are however very similar as the command line interface of Visual Lint Build Server is based on that of LintProject Pro. In fact, Visual Lint Build Server Edition can do everything LintProject Pro can - along with much, much more.

As such we think it is now finally time to put LintProject Pro out to pasture, and to make that easier we are offering a migration path from LintProject Pro to Visual Lint Build Server Edition. This involves trading in each existing LintProject Pro licence purchased before 23rd October 2018 for a 25% discount on a corresponding Visual Lint Build Server Edition licence. As such LintProject Pro has now been removed from our online store.

To take advantage of the upgrade, just write to us quoting which LintProject Pro licence (or licences) you wish to trade-in.

We've tried to keep this process clear and simple. The value of the discount offered exceeds that of the LintProject Pro licence, so this is a lower cost route to obtain an equivalent PC-lint Plus compatible product than (for example) refunding any existing LintProject Pro licences and purchasing Visual Lint Build Server Edition licences at full price.

If you have any questions, just ask.

Posted by Anna at 13:29 | Get Link

ACCU Conference 2018

Friday, April 27, 2018

We had an absolute blast at this year's ACCU Conference and if you were there we imagine you did too.

For us the highlight had to be the launch of #include <C++>, a new global, inclusive, and diverse community for developers interested in C++.

This is an initiative that has been brewing for a while, and one we are very happy to be a part of. Above all else #include <C++> is designed to be a safe place for developers irrespective of their background, ethnicity, gender identity or sexuality. The group runs a Discord server which is moderated to ensure that it remains a safe space and which you are welcome to join.

On the technical front, one unexpected highlight of the conference was Benjamin Missel's wonderful short talk on writing a C compiler for a BBC Micro, during which he demonstrated SSHing into a BBC Model B through the serial port!

Most conference sessions were recorded so even if you weren't there you can still watch them.

See you at ACCU 2019!

Posted by Anna at 12:25 | Get Link

ResOrg 2.0.7.27 has been released

Friday, April 27, 2018

ResOrg 2.0.7.27 has just been released. This is a maintenance update for ResOrg 2.0, and is compatible with all ResOrg 2.0 licence keys.

The following changes are included:

• Fixed a bug in the Symbols Display which could cause some "OK" symbols to be incorrectly shown in the "Problem Symbols Only" view.

• Corrected the upper range limit for control symbols from 28671 (0x6FFF) to 57343 (0xDFFF).

• ResOrg binaries are now dual signed with both SHA1 and SHA256.

• Added support for Visual Studio 2017.

• Corrected the File Save Dialog filters used by the ResOrgApp "File | Export" command.

• The ResOrgApp "File | Export", "File | Save", "File | Save As" and "File | Properties" commands (which apply only to symbol file views) are now disabled when the active view is a report.

• Fixed a crash in the Symbol File Properties Dialog.

• Fixed a typo on the Symbol File "Next Values" page.

• Various minor improvements to the installer.

Download ResOrg 2.0.7.27

Posted by Anna at 11:31 | Get Link

ACCU Conference 2016

Wednesday, June 8, 2016

In late April we exhibited at the ACCU Conference (#accuconf), which in many ways is our conference home. The first time we went was all the way back in 2007, and believe it or not we've not missed a single year since then.

The conference is a great event filled with amazing people, and it's a privilege to have been able to be a part of it for the past decade.

We normally attend the sessions as delegates and also run an exhibition stand (which makes for some rather hectic juggling!), but this year was a little different as our founder Anna also presented the closing keynote "Comfort Zone" (which she describes as being about "Puppies, Spiders, User Interface Cheese-Moving and the Neuroscience of Anger"....).

As ever, it was an interesting (and quite exhausting) week...but more than that, it was a week when the people who make ACCU what it is stood up and really showed what a truly amazing group of people they are. I'll talk about that specifically in a follow-up post shortly, but suffice it to say that we came away understanding just how lucky we are to have found this particular organisation...

Of course if you went, you'll know all this already. If you didn't, here's a handful of photos to give you an idea what you missed this time...

If you'd like to see the keynote, there's a video of it on YouTube and the slides are here.

Posted by Anna at 14:02 | Get Link

PC-lint Plus is coming - and with it, full support for C++ 11 and C++ 14

Monday, December 14, 2015

Gimpel have just announced a beta of PC-lint Plus - a new product which will sit alongside PC-lint. To understand the (rather complex, I'm afraid) background and the background to why a beta of PC-lint Plus has been announced rather than one for the long awaited 9.00m patch, please keep reading...

It is no secret that PC-lint 9.0 struggles with some C++ 11/14 code - and especially any code making use of C++ 11 variadic templates. The result is errors - and nasty, hard to work around ones at that.

Under Windows, this is particularly noticeable when analysing projects written for Visual Studio 2013 and 2015, which both use variadic templates in their system headers (Visual Studio 2012 and earlier did not).

A glance at the PC-lint 9.0 C++ 11 support page on the Gimpel website illustrates this rather well, with the following C++ 11 features shown as not yet being supported as of PC-lint 9.00L:

• Allowing move constructors to throw [noexcept] (N3050)
• Variadic templates (N2242)
• Extending variadic template template parameters (N2555)
• Initializer lists (N2672)
• Generalized attributes (N2761)
• Generalized constant expressions (N2235)
• Inheriting constructors(N2540)
• Unicode string literals (N2442)
• Raw string literals (N2442)
• Universal character names in literals (N2170)
• User-defined literals (N2765)
• Inline namespaces (N2535)
• Unrestricted unions (N2544)
• Minimal support for garbage collection and reachability-based leak detection (N2670)
• Extended integral types (N1988)

That's just of course from C++ 11, and with C++ 14 also out and C++ 17 (which like C++ 11 promises major changes to the language) is just around the corner, keeping up has been getting more and more difficult. As Jim Gimpel said to us recently:

Unfortunately, keeping up with the evolving C++ standards which seemed to know no bounds, became more and more difficult as Gimpel Software did have bounds.

It is worth remembering that PC-lint was first introduced in 1985, so presumably the C++ front end in 9.00L is a direct descendent of that in the original product rather than one of the standard C++ front ends (EDG, Clang, GCC etc.) our industry has effectively settled upon since. As a result, every change in the language no doubt requires comparable changes in the PC-lint front end. Given how much C++ has evolved recently (and continues to evolve, looking forward to C++ 17 and beyond), that's potentially a huge ongoing task.

Like many others, for some time we have been asking Gimpel for an estimate of roughly when an update addressing the remaining C++ 11 issues were realistically likely to become available. Although throughout last year we thought that support for variadic templates issue (the missing feature which seemed to be catching most people out) would be resolved with 9.00L in the Autumn sadly it was not to be, and by the start of this year it became obvious to us that we would have to put into place a workaround to allow customers to analyse Visual Studio 2013 and 2015 projects. Hence the system headers compatibility thunk described in the blogpost Visual Studio 2013, PC-lint and C++ 11 Variadic Templates which became available in Visual Lint 4.5.9.239 onwards.

Around the same time, Gimpel also updated us on their future plans, and how they intended to offer complete C++ 11/14 support. Although we couldn't talk about that publicly at the time, now that they have announced the beta we are free to do so.

The bottom line is that rather than continue to try to keep the existing PC-lint front end up to date with changes in the C++ Standard, Gimpel have decided to develop a spin-off product using the industry standard Clang front-end. The existing PC-lint 9.0 and Flexelint 9.0 products will continue to be supported for the foreseeable future.

This is of course a major development, and in consequence is one that couldn't have been released as a PC-lint 9.0 patch anyway. As the Clang source requires a modern C++ compiler to compile it, this makes distributing PC-lint Plus as obfuscated source (as Flexelint currently is) impractical as many compilers for non-x86 platforms would not be able to compile it.

The move to Clang also means that in future PC-lint Plus will be able to keep up with changes in the C++ standard as fast as new versions of Clang can be integrated. So, if (for example) the C++ Module System proposals (N4465/N4466) (which allow imports of compiled units to replace #includes of header files, thus drastically reducing build times) make it into C++ 17, PC-lint will be able to keep up without another major hiatus.

For Windows, both 32 bit (pclp32.exe) and 64 bit (pclp64.exe) binaries will be provided along with full support for C++ 11/14, Visual Studio 2013 and 2015. For Linux, a pre-built x86 binary will be available which should simplify things for developers on that platform (and potentially allow the pricing of the Linux version of PC-lint to become more competitive with the Windows variant). For non-x86 platforms etc., Flexelint will continue to be available in its current form.

The new product supports a considerable number of new messages (far too many to list!). In addition, obsolete options such as +linebuf and +macros have been removed.

As far as our own products are concerned, Visual Lint 5.0.6.254 onwards are aware of PC-lint Plus (we've actually been testing with alpha builds since the summer) and should work with beta versions. Support for 64 bit builds of PC-lint will become available in the New Year, and now that the beta has been announced we will be adding documentation for the new messages to the message database installed with the product as information becomes available.

Overall this is a huge step forward, but we are aware that it may come as a shock to many who were expecting PC-lint 9.00m. As soon as we know the details of Gimpel's PC-lint 9.0 to PC-lint Plus upgrade policy rest assured we will be talking about it. In the meantime, please do join the beta programme and help test it!

Gimpel's beta announcement can be found in their blogpost Upcoming Support for C++14/VS2015.

Posted by Anna at 11:24 | Get Link

ResOrg 2.0.6.25 has been released

Monday, November 9, 2015

This is a maintenance update for ResOrg 2.0. The following changes are included:

• Added support for Visual Studio 2015.

• Added support for Windows 10.

• Added a helpfile.

• Removed support for Windows 2000.

• ResOrgApp now declares itself as system DPI aware to reduce the likelihood of DPI virtualization.

• Icons used within the ResOrg displays now reflect the current system defined icon sizes rather than being hardcoded to 16x16, 32x32 etc.

• Tweaked the layout of the AboutBox.

Download ResOrg 2.0.6.25

Posted by Anna at 10:30 | Get Link

Visual Studio 2013, PC-lint and C++ 11 Variadic Templates

Monday, February 23, 2015

Although we added support for Visual Studio 2013 some time ago, PC-lint has lagged behind somewhat and even now (well over a year after it was released) has difficulty analysing any projects for it which use the Standard Template Library (STL) to any significant extent.

In large part this is due to the fact that PC-lint has to date lacked support for C++ 11 variadic templates (which are heavily used in parts of the Visual Studio 2013 system headers). With PC-lint 9.00L (the current patch level) even a simple #include <map> will trigger an internal error (9.00k was less vocal, but still raised errors you had to suppress).

Although this was not a huge problem when Visual Studio 2013 first came out (most development teams take their time moving to new versions of Visual Studio), it is now sufficiently mature that many teams are moving to it, and that's potentially a big problem if you also use PC-lint. The arrival of the free Visual Studio Community Edition has of course accelerated this trend.

Although we were expecting this to have been fixed by Gimpel around the middle of last year they apparently found that doing so proved to be far trickier than anticipated, with the end result that this limitation has become an increasingly large problem. The latest information we have is that there will be a beta with full support for variadic templates available sometime in March, so at least there is now some light at the end of this particular tunnel.

However, that does probably mean that there won't be a complete "production" fix for at least a couple of months after that. Hence we have been looking at potential workarounds (with one of our customers who is in the process of moving their codebase to Visual Studio 2013 and has run into this issue) to see what we can do in the meantime.

The most promising approach we have identified so far is actually very simple - just substitute the system headers for an earlier version of Visual Studio while analysing Visual Studio 2013 projects by modifying the -i directives for the system headers, while leaving the rest of the analysis configuration unchanged. The major caveat is of course that you need to have an earlier version of Visual Studio co-installed, but in practice that's pretty common.

The second caveat is that you may run into problems if you are using STL functionality (e.g. std::make_unique) which is implemented in the Visual Studio 2013 system headers but absent from earlier versions. Even then, there are workarounds in some cases - it really depends on what you use in your projects. It also goes without saying that the workaround can't handle any code you write in your own projects which uses variadic templates directly.

Given all that however it does seem to work rather well (it even seems to make it practical to analyse Visual Studio 2013 projects with PC-lint 8.0, which is an unexpected bonus!) and as a result we've decided to build this into Visual Lint so that it can take care of it automatically (but optionally, of course) for you when it determines that you are using PC-lint 9.00L or earlier. For now we've limited it to using the system headers from a Visual Studio 2012 or 2010 installation on the same machine, but we can extend that if needed.

This functionality should be out as part of Visual Lint 4.5.9.239 soon, but we are happy to release preliminary builds on a case by case basis if it will help other teams who are running into the same problem. Likewise if you have any questions about the specifics of this approach or are running into this issue (not necessarily just with Visual Studio) just let us know and we will be happy to help.

Update: Visual Lint 4.5.9.239 was released on 6th March 2015.

Posted by Anna at 18:19 | Get Link

How Visual Lint parses projects and makefiles

Thursday, November 6, 2014

Code analysis tools can require a lot of configuration to be useful. Whilst some (e.g. Vera++ or cpplint) need very little configuration to make use of effectively, others such as PC-lint (and even, to a lesser extent, CppCheck) may need to be fed pretty much the same configuration as the compiler itself to be useful. As a result the command lines you need to use with some analysis tools are pretty complex in practice (which is of course a disincentive to using them, and so where Visual Lint comes in. But I digress...).

In fact, more capable code analysis tools may need to be given even more information than the compiler itself to generate meaningful results - for example they may need to be configured with the built-in preprocessor settings of the compiler itself. In a PC-lint analysis configuration, this is part of the job compiler indirect files such as co-msc110.lnt do.

As a result of the above, a product such as Visual Lint which effectively acts as a "front end" to complex (and almost infinitely configurable) code analysis tools like PC-lint needs to care about the details of how your compiler actually sees your code every bit as much as the analysis tool itself does.

What this means in practice is that Visual Lint needs be able to determine the properties of each project it sees and understand how they are affected by the properties of project platforms, configurations and whatever compiler(s) a project uses. When it generates an analysis command line, it may need to reflect those properties so that the analysis tool sees the details of the preprocessor symbols, include folders etc. each file in the project would normally be compiled with - including not only the properties exposed in the corresponding project or makefile, but also built-in symbols etc. normally provided by the corresponding compiler.

That's a lot of data to get right, and inevitably sometimes there will be edge cases where don't quite get it right the first time. It goes without saying that if you find one of those edge cases - please tell us!

So, background waffle over - in this post I'm going to talk about one of the things Visual Lint does - parsing project files to identify (among other things) the preprocessor symbols and include folders for each file in order to be able to reflect this information in the analysis tool configuration.

When analysing with CppCheck, preprocessor and include folder data read in this way can be included on the generated command line as -D and -I directives. Although we could do the same with PC-lint, it is generally better to write the preprocessor and include folder configuration to an indirect ("project.lnt") file which also includes details of which implementation (.c, .cpp, .cxx etc.) files are included in the project -as well as any other project specific options. For example:

A file like this is written for every project configuration we analyse, but the mechanism used to actually read the configuration data from projects varies slightly depending on the project type and structure.

In the case of the Visual Studio 2002, 2003, 2005 and 2008 .vcproj files Visual Lint was originally designed to work with, this is straightforward as the project file contains virtually all of the information needed in a simple to read, declarative form. Hence to parse a .vcproj file we simply load its contents into an XML DOM object and query the properties in a straightforward manner. Built-in preprocessor symbols such as _CPPUNWIND are defined by reading the corresponding properties (EnableExceptions in the case above) or inferred from the active platform etc.

Similarly, for Visual C++ 6.0 and eMbedded Visual C++ 4.0 project files we just parse the compiler command lines in the .dsp or .vcp file directly. This is pretty straightforward as well as although .dsp and .vcp files are really makefiles they have a very predictable structure. Some other development environments (e.g. Green Hills MULTI or CodeVisionAVR) have bespoke project file formats which are generally easy to parse using conventional techniques.

Visual Studio 2010, 2012 and 2013 .vcxproj project files are far more tricky, as the MSBuild XML format they use is effectively a scripting language rather than a declarative format. To load them, we effectively have to execute them (but obviously without running the commands they contain).

As you can imagine this is rather tricky! We basically had to write a complete MSBuild parsing engine^* for this task, which effectively executes the MSBuild script in memory with defined parameters to identifiy its detailed properties.

^* Although there are MSBuild APIs which could conceivably help, there are implemented in managed code - which we can't use in a plug-in environment due to .NET framework versioning restrictions. Instead, our MSBuild parsing engine is written natively in C++.

To work out the parameters to apply to the MSBuild script, we prescan the contents of the .vcxproj file to identify the configurations and platforms available. Once we have those, we can run the script in memory and inspect the properties it generates for the required build configuration. This process is also used with CodeGear C+ and Atmel Studio projects, both of which are MSBuild based.

Eclipse projects (.project and .cproject files) are also XML based and are not too difficult to parse, but whereas it is straightforward to work out how things are defined in a .vcproj file, Eclipse project files are much less clearly defined and more variable (not surprising as they effectively represent serialised Java object data).

To make matters worse, each compiler toolchain can have its own sub-format, so things can change in very subtle ways between based projects for different Eclipse based environments such as Eclipse/CDT, QNX Momentics and CodeWarrior. In addition, Eclipse C/C++ projects come in two flavours - managed builder and makefile.

Of the two, managed builder projects are easy to deal with - for example to determine the built-in settings of the compiler in a managed builder we read the scanner (*.sc) file produced by the IDE when it builds the project, and add that data to the configuration data we have been able to read from the project file.

The scanner (.sc) file is a simple XML file located within the Eclipse workspace .metadata folder. Here's an extract to give you an idea what it looks like:

Unfortunately scanner files are not generated for makefile projects, and the enclosing project files do not give details of the preprocessor symbols and include folders needed to analyse them. So how do we do it?

The answer is similar to the way we load MSBuild projects - by running the makefile without executing the commands within. In this case however the make tools themselves can (fortunately!) lend a hand, as both NMake and GNU Make have an option which runs the makefile and echoes the commands which would be executed without actually running them. For NMake this is /n and GNU Make -n or --just-print.

The /B (NMake) -B (GNU Make) switch can also be used to ensure that all targets are executed regardless of the build status of the project (otherwise we wouldn't be able to read anything if the project build was up to date).

If we run a makefile with these switches and capture the output we can then parse the compiler command lines themselves and extract preprocessor symbols etc. from it. As so many compilers have similar command line switches for things like preprocessor symbols and include folders this is generally a pretty straightforward matter. Many variants of GCC also have command line options which can report details of built-in preprocessor symbols and system include folders, which we can obviously make use of - so the fact that many embedded C/C++ compilers today are based on GCC is very useful indeed.

There's a lot of detail I've not covered here, but I hope you get the general idea. It follows from the above that adding support for new project file types to Visual Lint is generally not difficult - provided we have access to representative project files and (preferably) a test installation of the IDE in question. If there is a project file type you would like us to look at, please tell us.

Posted by Anna at 12:32 | Get Link

Business of Software Conference Europe

Wednesday, July 2, 2014

Last week our founder Anna attended the Business of Software Europe conference in Cambridge, and it was quite something indeed.

Although the Business of Software Conference has been running for several years in the USA, this is the first year an event has been held in Europe (and what better a place than Cambridge?). The conference covered everything from live Python telephony to the psychology of the internet and the organisation and management of sales teams, so it was pretty diverse.

If you are interested in more than just coding, this is an event we can strongly recommend. Photos and videos from the conference should be online soon, so if you are interested please stay tuned.

Posted by Anna at 10:34 | Get Link

Visual Lint and Windows Driver Kit (WDK) projects

Tuesday, April 02, 2013

We have recently been working with Don Burn on PC-lint analysis of Windows Driver Kit (WDK) projects, and he has written an interesting article on the subject titled "Another Look at Lint" in the March-April 2013 issue of the NT Insider.

Within the article you will find the following rather complementary passage:

Finally the ultimate tool for using PC-lint with the WDK is Riverblade's Visual Lint. This is a third party tool providing an integrated package that works inside VS2012. The tool is an add-on to PC-lint which you must still purchase. The capabilities include background analysis of the project, coded display listings that - like Visual Studio - clicking on the error takes you to the line to edit and provides easy lookup of the description of the errors. The latest version of Visual Lint (4.0.2.198) is required for use with the WDK. The tool has a minor bug that if there are two subprojects with the same name, such as filter in the Toaster sample, one needs to be renamed for analysis to work. A fix is in the works.

To use Visual Lint with the WDK choose LintLdx.lnt as the standard lint configuration file for the tool. There is a 30-day free trial of Visual Lint available so if you are considering PC-lint, take a look at what Visual Lint can add to the experience. I expect to be using it for much of my work.

Our thanks to Don Burn for his patience while we worked through the issues raised by the analysis of WDK projects. As a postscript, a fix for the bug he refers to above has already been checked in and should become available in the next public Visual Lint build (most likely 4.0.3.200).

Posted by Anna at 16:29 | Get Link

Visual Studio 2012 theme support

Thursday, August 2, 2012

One of the unexpected (and I would suggest from the comments, unwelcome) changes sprung on developers in the Visual Studio 2012 Beta back in February was the "Metroification" of the development environment.

However, eye candy (and eyesores!) come and go, and within that change is a more fundamental one - direct support for themes within the Visual Studio IDE. The Visual Studio 2012 Beta and RC include two themes - light (i.e. grey) and dark. Whilst the latter has an obvious appeal within the developer community (we all know devs who prefer green text on a black background) the former hasn't exactly been welcomed, to say the least.

Personally, rather than develop custom theme support for each tool individually I wish they'd just add a "dark" theme to Windows instead and respect the theme settings of the operating system. Obviously my view just isn't "cool" enough for the Visual Studio UX team, but I digress...

Although a campaign to retain the existing Visual Studio 2010 theme has been running on the UserVoice site since the beta arrived (see the UserVoice posts Add some color to Visual Studio 11 and Leave VS 2010 theme (and the theme editor extension) as an option) Microsoft have not indicated what - if any - changes will be made to the Visual Studio 2012 themes at RTM.

Our working assumption therefore has to be that the themes in the RTM will be broadly comparable with those in the RC (i.e. light and dark). We will find out whether that assumption is correct later this month, of course.

With that in mind, we have been working on theme support in the development branch for Visual Lint for some time now, and things are now beginning to come together:

As Visual Lint uses standard Win32 controls for most of the UI (which for the most part do not support custom text/background colours), to get this far we have had to write custom painted WTL checkbox, radio button, combobox and header controls in addition to the usual WM_CTLCOLORxxxx voodoo. Other UI elements such as menus, scrollbars, command buttons etc. yet haven't yet been looked at, but hopefully will be in due course (there seems to be some indication in the MSDN blogs that scollbars will be auto-themed by the RTM, but we'll see).

Within the displays themselves, the text and background colours of each item are checked for adequate contrast, and the text colour adjusted (by tweaking the luminance) automatically if need be.

Although the Visual Studio interfaces expose the colours used in the active theme (via IVsUIShell2::GetVSSysColorEx()), they do not seem to provide any way of detecting if the theme has changed (or indeed, finding out which theme is actually running at the time). Our workaround for this is simply to reload the colour scheme whenever the "Tools|Options" command has been executed. We don't really care which theme is running after all - just what colour values it uses, and where.

Indeed, one of the first things we did while working on this was to dump all of the colour values used by the Visual Studio 2012 RC light & dark themes, as well as the default Visual Studio 2010 theme, into spreadsheets so we could use them for testing without firing up a host instance of the IDE (developing add-ins may be fun, but it is also much slower than working on your own executable).

Finally, it is a little known fact that the Visual Studio IDE has had colour scheme support internally for some time, so the scheme we have designed will also work with Visual Studio 2010 if you have the theme editor extension installed:

Needless to say, all of this is proving to be a major task, and it has therefore diverted significant resources from other things we should really have been working on this summer. As a consolation, the theme code we're developing is generic (albeit only on Windows), so can also be used with Eclipse 4.0 (I note that themes are coming to that IDE as well when the time comes.

Another obvious benefit is of course that there's potentially at least one new CodeProject article (want a themed XP button with a custom background colour? We know how to do it now) in all of this once the dust settles and the inevitable bugs have crawled away. It's about time I wrote a new one, anyway.

Once Visual Lint theme support is complete, we'll obviously also take a look at ResOrg. Beyond that, I think a new article is a foregone conclusion, once we've cleaned the code up a bit and built a good enough demo project.

Posted by Anna at 12:45 | Get Link

Introducing VisualLintGui

Friday, April 20, 2012

If you have been following me (@annajayne) on Twitter, you may have noticed me talking about something called "VisualLintGui".

This is actually the second of two projects (the first being VisualLintConsole - the command line version of Visual Lint) we got underway after the release of Visual Lint 3.0.

Now that VisualLintConsole (the command line version of Visual Lint) is out in the wild, we have turned our attention to VisualLintGui. This is, as the name suggests, a standalone Visual Lint application with a graphical user interface - basically a text editor focused on code analysis:

Although it has been fully functional in terms of analysis functions for quite some time, until recently we were not able to devote a great deal of time to the details of its user interface. That has now changed, and since February VisualLintGui has gained many essential capabilities including a syntax colouring editor with analysis issue markers, MDI tabs, Find/Replace and Source/Header flip to name but a handful of the more obvious recent changes.

VisualLintGui is currently capable of analysing projects for Visual Studio, Visual C++, Eclipse, CodeGear C++ and AVR Studio 5.0, but it can obviously potentially analyse a far wider variety of codebases than that.

Indeed, one of the reasons we have been keen to develop it is to provide a way to support embedded IDEs for which developing a Visual Lint plug-in is not a viable proposition. As such we expect to add support for further project and workspace file formats as and when our customers need them.

VisualLintGui currently resides in our Visual Lint development branch, but given the recent pace of development on it we are likely to look at porting it back into Visual Lint 3.5 in the not too distant future.

In the meantime we will have a development build on our stand at the ACCU Conference next week, so if you are going please do come and take a look.

Posted by Anna at 15:23 | Get Link

ResOrg 2.0 has been released

Sunday, January 22, 2012

It's done. After a rather extended incubation period ResOrg 2.0.0.15 (the first public ResOrg 2.0 build) was uploaded earlier this morning, and the ResOrg product pages updated to match.

If you have used ResOrg 1.x before, you will notice that the user interface of ResOrg 2.0 is subtly different from its predecessor - notably in the Visual Studio plug-in (which now of course supports Visual Studio 2008 and 2010...).

In particular, the old (and rather limited) "ResOrg.NET Explorer" toolwindow has been replaced by a much more useful "Symbol Files Display" which is also available in the standalone application.

If you are using Visual Studio 2010, it might interest you to know that ResOrg 2.0 can automatically update Ribbon Designer (.mfcribbon-ms) files when an ID referenced in a ribbon resource is renumbered.

I won't include any screenshots in this post as a couple of good ones were included in the previous post, however if you are reading this post in your RSS reader you can find them in the blogpost ResOrg 2.0 update.

• Try ResOrg 2.0

Posted by Anna at 11:24 | Get Link

Visual Lint and Atmel AVR Studio 5

Friday, September 16, 2011

From our perspective one of the more intriguing embedded environments to appear recently is Atmel's AVR Studio 5.

When I first saw a screenshot of this IDE (it was mentioned in a post in the CodeProject Lounge) it was immediately obvious that this was some sort of Visual Studio derivative.

In fact, although it uses GCC toolchains, the environment is based on the Visual Studio 2010 isolated shell (which incidentally is something we briefly considered using ourselves for a future standalone GUI version of Visual Lint, but decided against because of its complexity and the size of the download).

It obviously occurred to us then that as a Visual Studio derivative, it shouldn't be too difficult to get Visual Lint running within it. The first step was obviously to install the IDE in a VM (XP SP3 - doesn't XP look a bit old these days...?) and experiment with some projects.

AVR Studio 5 codebases uses the Visual Studio 2010 solution file format (albeit rebadged as a .avrsln file) and a new MSBuild based project file format (.avrgccproj), so the first thing we obviously had to do was implement parsers for these files (something that will also benefit LintProject Pro, of course). Once that was done, we turned our attention to getting Visual Lint to load within the IDE itself.

This turned out to be fairly straightforward. Although AVR Studio 5 does not seem to support COM add-in registration in HKEY_LOCAL_MACHINE (which is how the Visual Lint add-in registers in Visual Studio), the corresponding registration in HKEY_CURRENT_USER\Software\Atmel\AVRStudio\5.0\AddIns does work. Although this is problematical from an installation point of view (see my previous post on the Visual Studio 11 Developer Preview) it is not a showstopper by any means.

With manual add-in registration in place, Visual Lint loaded within the IDE. Although a few minor tweaks were needed to work around issues such as AVR reporting itself as "Visual Studio Express Edition, version 1.0" (which caused the version detection code in Visual Lint to default to 16 colour command bitmaps!) those were easily addressed.

As a result, we now have AVR Studio 5 running with a development build of Visual Lint:

Although we still have quite a bit to do (not least the code editor markers and installer) before AVR Studio 5 can become a supported host environment for Visual Lint this is a very promising start. Needless to say, beta testers are welcome.

Posted by Anna at 16:17 | Get Link