Recent

Author Topic: Another nonsense compiler warning  (Read 450 times)

winni

  • Hero Member
  • *****
  • Posts: 2015
Another nonsense compiler warning
« on: September 20, 2020, 01:34:17 am »
Hi!

Funny stuff.

The compiler tells me:

Code: Text  [Select][+][-]
  1. dialogtest1.pas(117,46) Warning: Symbol "GetModalResultStr" is deprecated: "Use the ModalResultStr array from unit UITypes directly."

Line 117 is this:

Code: Pascal  [Select][+][-]
  1. showMessage ('ModalResult is '+  ModalResultStr[res]);

I am doing exact that what the warning recommends.

Weekend. The compiler is drunken.

Winni

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 6718
  • Debugger - SynEdit - and more
    • wiki
Re: Another nonsense compiler warning
« Reply #1 on: September 20, 2020, 01:42:24 am »
Well, you appear to use Controls.ModalResultStr  (which is a property resolving to GetModalResultStr )

And it tells you to use UITypes.ModalResultStr

jamie

  • Hero Member
  • *****
  • Posts: 3797
Re: Another nonsense compiler warning
« Reply #2 on: September 20, 2020, 01:55:24 am »
When something gets depreciated maybe it should be taken out instead of marking it as depreciated and have it forgotten for eons. This just clutters up the code.

 Would it not be better to simply remove it and add the removal to a database that could be searched optionally when the identifier is not found. Basically, from the error window of the compiler the user could click there to have it look into the database and if it exists then offer the alternative, if there is one.

The only true wisdom is knowing you know nothing

trev

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1075
  • Former Delphi 1-7, 10.2 User
Re: Another nonsense compiler warning
« Reply #3 on: September 20, 2020, 02:47:10 am »
There's a difference between deprecating something and removing it. Removal follows after deprecation.

The reason for deprecation is to allow time for a feature/API to be fully replaced and to warn users of its impending removal BEFORE the feature/API is removed.

Example:

Apple deprecated 32 bit binaries at the Worldwide Developers Conference in June 2017 before removing the ability to run them in October 2019 with the introduction of the new macOS 10.15 Catalina operating system.
o Lazarus v2.1.0 r63871, FPC v3.3.1 r47164, macOS 10.14.6, Xcode 11.3.1
o Lazarus v2.1.0 r64160, FPC v3.3.1 Nov 27 21:16:31, macOS 11.0.1 (aarch64), Xcode 12.2
o Lazarus v2.1.0 r61574, FPC v3.3.1 r42318, FreeBSD 12.1 amd64 (VMware VM)
o Lazarus v2.1.0 r61574, FPC v3.0.4, Ubuntu 20.04 (PD VM)

winni

  • Hero Member
  • *****
  • Posts: 2015
Re: Another nonsense compiler warning
« Reply #4 on: September 20, 2020, 02:49:05 am »
Well, you appear to use Controls.ModalResultStr  (which is a property resolving to GetModalResultStr )

And it tells you to use UITypes.ModalResultStr

Hi!

Nope. No controls in the uses section but UItypes.

Wrong shot in the dark.

Winni

ASBzone

  • Sr. Member
  • ****
  • Posts: 479
  • Automation leads to relaxation...
    • Free Console Utilities for Windows from BrainWaveCC
Re: Another nonsense compiler warning
« Reply #5 on: September 20, 2020, 03:20:52 am »
When something gets depreciated maybe it should be taken out instead of marking it as depreciated and have it forgotten for eons. This just clutters up the code.

 Would it not be better to simply remove it and add the removal to a database that could be searched optionally when the identifier is not found. Basically, from the error window of the compiler the user could click there to have it look into the database and if it exists then offer the alternative, if there is one.

The reason for not removing it immediately is so that a whole lot of code doesn't just break.   This grants people sufficient time to see that there will be a future problem, and code their way out of it at their own schedule, rather than being forced to do so more abruptly.

You couldn't call it "deprecated" if it was "deleted"
-ASB: https://www.BrainWaveCC.com

Lazarus v2.0.11 r64135 / FPC v3.2.1-r47648 (via FpcUpDeluxe) -- Windows 64-bit install w/32-bit cross-compile
Primary System: Windows 10 Pro x64, Version 2009 (Build 19042)
Other Systems: Windows 10 Pro x64, Version 2004 (Build 19041) or greater

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 6718
  • Debugger - SynEdit - and more
    • wiki
Re: Another nonsense compiler warning
« Reply #6 on: September 20, 2020, 03:30:35 am »
Well, you appear to use Controls.ModalResultStr  (which is a property resolving to GetModalResultStr )

And it tells you to use UITypes.ModalResultStr

Hi!

Nope. No controls in the uses section but UItypes.

Wrong shot in the dark.

Well the content for deprecated messages is defined in the source (in this case LCL, where the deprecated identifier is).

So fpc only prints something that is in some source code that declares ModalResultStr.

I could only find those 2 locations, but I looked a trunk (Lazarus), so maybe if you have a diff version, you need to find where the deprecated keyword for ModalResultStr is.

As for ModalResultStr vs GetModalResultStr:
If ModalResultStr is a property with a getter, then using ModalResultStr will show deprecation messages for its getter too. So that explains how ModalResultStr displays "GetModalResultStr is deprecated".
« Last Edit: September 20, 2020, 03:32:24 am by Martin_fr »

winni

  • Hero Member
  • *****
  • Posts: 2015
Re: Another nonsense compiler warning
« Reply #7 on: September 20, 2020, 03:39:59 am »
@Martin_fr

Thank you!

Winni

PascalDragon

  • Hero Member
  • *****
  • Posts: 2433
  • Compiler Developer
Re: Another nonsense compiler warning
« Reply #8 on: September 20, 2020, 09:45:24 am »
When something gets depreciated maybe it should be taken out instead of marking it as depreciated and have it forgotten for eons. This just clutters up the code.

No, backwards compatibility is something that is very important to FPC/Lazarus, so removing something is only done in very few cases.

 

TinyPortal © 2005-2018