OmniPascal 0.15.0 – Overloaded and generic methods
This release brings a lot of improvements regarding understanding of language features as well as bugfixes. Read the complete change log:
- Enhancement: Resolving calls to overloaded methods works much better now. In previous releases calls to overloaded methods were resolved to the first method that could be called with the given amount of arguments. Now OmniPascal takes the types of the arguments into account.
- Enhancement: Added support for methods with generic parameters and basic type inference
- Change: Types and methods appear with generic parameters in code completion
- Enhancement: When a code completion item with generic parameters is selected then the first generic parameter is marked and can be changed immediately. You can jump to the next generic parameter using tab
- Enhancement: Go-to-definition works (as good as possible) on method calls even when the amount of arguments doesn’t match the method’s signature
- Change: Go-to-definition performed on a parameter now jumps to the method’s declaration if possible instead of the implementation
- Enhancement: The parser is much more tolerant with FreePascal source files. It no longer crashes on keywords like generic, specialization and constref. Code completion works much better in FPC project.
- Enhancement: Code completion works on variables of a generic constrained type
- Enhancement: All classes implicitly inherit from System.TObject. All interfaces implicitly inherit from System.IInterface. In the past Calls to SomeObject.Free could only be resolved if the object’s class inherits implicitly from TObject.
- Enhancement: Code completion items have more different symbols now based on their kind
- Enhancement: Code completion items are ordered by relevance. In the past they were ordered alphabetically
- Change: Minor changes of symbols shown in the list of document sybols
- Enhancenment: Default namespaces are loaded from DPROJ files
- Enhancement: Values of scoped enums no longer appear in general code completion
- Enhancement: Generated tasks.json defines default tasks
- Bugfix: Automatic regeneration of build scripts didn’t work on Windows when the loaded project file changed
- Bugfix: Parser crashed when attempting to include a file with BOM header
- Bugfix: Go-to-definition of a symbol defined in an included file didn’t work
- Bugfix: Method calls like “read()” or “write()” are no longer displayed as keywords (at least when followed by round brackets)
- Bugfix: Calls to full qualified type members are now resolved properly
- Bugfix: When a pointer to a record type was declared before the record then the record’s members didn’t appear in code completion when triggered for a variable of the pointer type.
- Bugfix: Unit’s created via the lightbulb’s quickfix “Create new unit” were displayed with an error saying the unit name was wrong.
- Bugfix: Automatic interface implementation no longer adds include files to uses
- Bugfix: External methods didn’t appear in code completion
- Bugfix: OmniPascal did become very slow when huge files with a lot of overloaded methods (like System.SysUtils) were opened in VSCode
- Bugfix: Creating warnings for missing method implementations was very slow when a file had a lot of overloaded methods
- Bugfix: Indexed access on arrays returned from methods didn’t work
- Bugfix: Generic type parameters no longer appear in the list of document symbols
- Bugfix: Correct handling of visibility sections in record types
- Bugfix: Removed squiggly lines for unresolvable uses entries coming from an included files. They showed up as ghost erros in areas without matching text.
- Bugfix: Generic type parameters did show up in derived classes’ code completion
- Bugfix: The Result variable has now the correct type inside anonymous functions
- Improved performance for code completion and symbol resolving. Much better performance of multi threaded operations.
OmniPascal: Delphi oder FreePascal in Visual Studio Code - Seite 3 - Delphi-PRAXiSAugust 28, 2017
SorienSeptember 21, 2017
Hi, nice changes, I’m trying to use it in daily but after few hours I can make OmniPascalServer to unresponsive state, i’m just seeing that it use 100% of one core and can’t return any autocomplete/navigation results. Is there any logging mechanism build in that could help you to resolve these problem?
WosiSeptember 21, 2017
bad to hear you’re having such problems.
Do these freezes only happen in a specific file or when you work with a specific class or object? If yes then I would love to see that code.
Here is a Windows only version of the current master where a debug log is enabled: http://omnipascal.com/dbg/Wosi.omnipascal-0.15.0.rar
Please download it and extract it to C:\Users\Sorien.vscode-insiders\extensions. I recommend VSCode insiders for this version (You can get it here: https://code.visualstudio.com/insiders).
A log file will be created under bin/win. This is a debug log without any rotation. It can become quite big within a work day. You should delete it from time to time in case OmniPascal didn’t freeze in the meanwhile.
When OmniPascal freezes then please attach a copy of the log file to a new bug report.
A few words to the debug version:
This is work in progress. There are some bug fixes. In the best case you won’t see freezes anymore. There is an experimental symbol index which is expensive to create an load. If you don’t to use it, you can turn it off in the config with `”omnipascal.symbolIndex”: “off”.
Let’s get rid of that nasty bug! 😉
John WiederhirnOctober 11, 2017
Is there any formal support planned for RemObject’s Oxygene language features and special syntax (another Delphi/TurboPascal-type derivative language)?
WosiOctober 12, 2017
There are currently no plans for Oxygene. As far as I can tell there are many differences regarding syntax between Oxygene and Delphi. So I don’t think there will be support in the future.