C# 7.0 and 7.1 support in ReSharper – How this affects other ReSharper features
Over the past days, we have been blogging about ReSharper support for C# 7.0 and C# 7.1.
Today, let’s conclude with a final part around how ReSharper understands the new syntax and constructs that C# 7.0 and C# 7.1 bring, and ties them into existing and new inspections, quick-fixes, navigation and refactorings.
In this series:
- Out variables
- Throw expressions
- Expression-bodied “everything”
- Async main
- Default literal
- Pattern matching with generics
- Improving ReSharper
Improving existing ReSharper features
Adding support for new C# language features isn’t just about adding support to the language parser or adding new quick-fixes. Work indeed starts with adding the language features to the PSI (Program Structure Interface) that ReSharper uses internally, but we also have to integrate these language features into existing ReSharper features you know and love.
For example adding
out variable declarations to the PSI lets us integrate them into existing refactorings like Rename. With
throw expressions as well as the
default literal introducing new types of null checks, adding these to the PSI and updating existing code anlysis allow ReSharper to detect potential
NullReferenceException in our existing code and in new C# 7.0 or C# 7.1 code.
Adding expression-bodied properties to our PSI allows the existing Convert to Auto-Property code analysis, quick-fix and refactoring to be updated with functionality that works on block bodies as well as expression bodies:
Existing and new code analysis and code style rules for C# 7.0 and C# 7.1 language features become part of Solution-Wide Analysis and the Inspect This… (Ctrl+Shift+Alt+A) action. What if we want to use the
default literal everywhere in our solution? What if we want to spot opportunities to use pattern matching?
So if we run code analysis on our current solution or project, ReSharper will tell us we have a Redundant Type Specification when we could be using the new
default literal in our code:
We can also run an inspection from the editor, using the Find similar… submenu’s:
The new syntax also lights up in code style settings – e.g. since any class member can now be expression-bodied, we can now configure code styles to use them everywhere, or only for properties and never for event handlers, etc.
In another example, Value/Call Tracking automatically got support for expression-bodied constructors so we can track incoming calls to our