I'm trying to setup Xdebug and while doing that I'm trying to ensure that all PHP-versions and setup of that is exactly right.
I've matched the PHP-version on the server (7.4), by installing and linking the right PHP-version using Brew (I'm on a Mac).
So in a terminal, if I write php --version I get: version: 7.4.14:
I've set the CLI-interpreter in PhpStorm to point to that same PHP-executable:
But in spite of this, I can only set PHP version 7.3 to be the highest language level:
Solution attempts:
All these things have been found in random cracks and articles. None of them worked.
Invalidated Cached and restarted PhpStorm ( File >> Invalidate Cache and restart ).
Uncheck 'Synchronize IDE Settings with composer.json' in Settings >> Languages & Frameworks >> PHP >> Composer. I had to first insert a path to remove it. But it didn't do anything anyway.
Tried to see if there was any upgrades to the "PHP Latest"-plugin, but I couldn't see any pending updates (v. 0.4).
Overarching question
How do I get the latest version in the PHP Language Level field (to also get better code hints)?
My version was this: 2018.2.3 - Build #PS-182.4323.68 built September 13, 2018
You need to upgrade your IDE. Latest stable version is 2020.3.1.
Partial PHP 7.4 support is present since PhpStorm 2019.2 version.
Proper PHP 7.4 support was added in PhpStorm 2019.3.
Initial/partial PHP 8 support was added in PhpStorm 2020.2.
Current 2020.3 version has more complete PHP 8 support.
Related
Can PhpStorm v10.0.4 (2015) be installed on same machine as v2019.3 or will they interfere with each other?
Yes, you can install and run them in parallel: no issues here.
Each major IDE version stores global (IDE wide) settings in separate folder which is version specific. It's quite common to have latest stable version (e.g. 2019.3) and EAP build of next major version (e.g. 2020.1 EAP) next to each other: working in stable version and be able to test something (preview new feature etc) in EAP build.
Project settings though are stored together with the project itself (in .idea subfolder; although you can workaround that if needed) and may case some issues (loss of some settings) if you plan to often open the same project in different IDE versions (especially when using such old IDE version as v10; simply because some settings can now be stored differently than 4 years ago).
I have TeamCity 2019.1.5 with most recent Visual Studio Tool 2017 installed:
I have a project which uses C# 7.1 features, and it compiles locally just fine in VS 2017, and I made sure it has <LangVersion>latest</LangVersion> in CSPROJ file. But when I run it from TeamCity (agent is on the same server) with the following build step:
it fails with the following error in the logs:
[Csc] Services\MappingService.cs(1942, 40): error CS8107: Feature 'default literal' is not available in C# 7.0. Please use language version 7.1 or greater.
If I start VS2017 command prompt on the server and go to the project's folder and run msbuild tt.csproj /target:Rebuild it works fine: compiles and I do not get any errors. Needless to say, if I remove C# 7.1-specific code, everything works in the current configuration.
I installed Visual Studio Tool 2019 and with MSBuild 16 it works without any problems as well. But I prefer to use 2017 tools so both server and dev environments are the same. What can cause this issue?
I had this problem and fixed it by fixing the solution configuration in the build step configuration. It needs to be set to either "Debug" or "Release". Mine was set to a parameter, which resolved to something other than one of those values.
I am trying to install SonarLint for Eclipse Ganymede (3.4.2) - and our project is very old, so we're using JDK 1.5 here. So is it possible to run SonarLint for JDK 5?
First of all, JDK 5 is so old, I can't really be certain of anything...
But here are some key factors that are important to understand:
Java code is analyzed by the Java analyzer (known today as "SonarJava"). SonarLint is a plugin in Eclipse (and other IDEs) that executes the SonarJava, and uses the results from it to annotate the code you are editing.
The JDK version that the SonarJava itself requires to run, is not the same thing as the JDK version of the source code it is able to analyze (= the subject of the analysis). For example, SonarJava may not run at all on JDK 7, but able to analyze code that is written in JDK 6.
If you use SonarLint in standalone mode, it uses its embedded version of the SonarJava, you cannot use another version. If you use SonarLint in connected mode, it uses SonarJava installed in the SonarQube to which you are connected. Here you have some freedom of choice in the version of the SonarJava, but not unlimited, because SonarLint may not be compatible with all versions of SonarJava, for example recent versions require a certain minimum version.
As per the product news, the current version of SonarLint requires Java 8 and more recent Eclipse than Juno. But you may be able to find an older version of SonarLint that can run in an older Eclipse, and support a version of SonarJava that is able to run on your JDK, and analyze code written for your target JDK version.
Based on the above points, you can dig into the older releases of SonarLint and find something suitable. These links should be useful in your search:
Product news of SonarLint for Eclipse. These also include links to the detailed release notes, which usually contain information about the version of embedded SonarJava
Releases of SonarLint for Eclipse
Homepage of SonarJava
I am curious as to why the following syntax is rejected by my PhpStorm editor:
PhpStorm version: 2016.1.2
Nullable parameters/return types (?User from your example) is a PHP 7.1 feature.
PHP Language Level must be set to 7.1 in PhpStorm settings for this project (although right now it does not produce an error if language is set below 7.1 -- see WI-32136 ticket).
Support for nullable types was added in PhpStorm 2016.2.2 (which is newer than your 2016.1.x)
Conclusion: upgrade your PhpStorm to the latest version (which is 2017.2.1 at this moment). At very least you need to have PhpStorm 2016.2.2 for this particular syntax to be supported 9not showing an error).
My site works on mono 2.10 and I'm nearly done on a brand new server upgrading to mono 3.2.x.
It works using XSP4, the ServiceStack Razor views render correctly. (And it fixes a lot of artefacts in 2.10)
When I set the site to use nginx + Fast CGI (4) however I get a HttpCompileException, caused by:
The predefined type `System.Collections.Generic.IReadOnlyList' is defined multiple times. Using definition from `mscorlib.dll'
Remember this works fine with xsp4 so I think it needs some setting to tie it to one .Net instance, maybe it's confused between .net 4.0 and .net 4.5? Any suggestions on how I can force it to use only one of these?
Note: I installed from git using latest (3.2.7), as the 3.2.5 release would crash. I'm using a clean Amazon EC2 Ubuntu 12.04 64bit. It didn't have mono on it before, and when I tried 3.2.5 it was another now deleted instance.
This is largely the same error as: RazorEngine on Mono - TemplateCompilationException thrown
But I had no other version installed. The build process added others which have since been deleted to no effect. All instances of mscorlib are here:
/usr/lib/mono/2.0/mscorlib.dll
/usr/lib/mono/4.5/mscorlib.dll
/usr/lib/mono/4.0/mscorlib.dll
I found out what the problem is and was able to solve it.
The culprit are these files:
https://github.com/mono/xsp/tree/master/src/Mono.WebServer.FastCgi/Compatibility
For some reason, they added these compaibility classes that are compiled to a NET 4.0 target (which does not have the IReadOnlyList class), but when we run the fastcgi-mono-server4, it runs under the 4.5 runtime, which do have a IReadOnlyList class and therefore generates the Razor HttpCompile error.
The solution was adding these 2 parameters -d:NET_4_5 -sdk:4.5 to the Makefile.in of the FastCGI source project:
#NET_4_0_TRUE# $(DMCS) -d:NET_2_0 -d:NET_4_0 -d:NET_4_5 -sdk:4.5 $(MCSFLAGS) $(references4) /out:$# \
Then I recompiled and reinstalled with ./configure, make, make install and the Razor compile error was gone for good.
If you don't want to go through all this trouble, I'd recommend sticking to the latest released version of the xsp project, which didn't have these Compatibility classes.