Recent

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

winni

  • Hero Member
  • *****
  • Posts: 3197
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: 9791
  • 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: 6090
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: 2020
  • 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.

winni

  • Hero Member
  • *****
  • Posts: 3197
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

  • Hero Member
  • *****
  • Posts: 678
  • Automation leads to relaxation...
    • Free Console Utilities for Windows (and a few for Linux) 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.2.7-ada7a90186 / FPC v3.2.3-706-gaadb53e72c
(Windows 64-bit install w/Win32 and Linux/Arm cross-compiles via FpcUpDeluxe on both instances)

My Systems: Windows 10/11 Pro x64 (Current)

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9791
  • 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: 3197
Re: Another nonsense compiler warning
« Reply #7 on: September 20, 2020, 03:39:59 am »
@Martin_fr

Thank you!

Winni

PascalDragon

  • Hero Member
  • *****
  • Posts: 5446
  • 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