bad message generated searching for units with the same starting name (FPC)

[jamie]

Example

Uses Graphics, Graphics32;


=
 "graphics32 searched but Graphics found"

 what kind of a response is that ?

shouldn't it be
"fatal: Can't fine unit graphics32 used by unit1" for example.

 
Do you now how hard that is to determine what is really going on here? Obviously it should of generated the second message but I've found that with any name in the list that has same starting names but different endings, one valid and the other isn't will give you the first error message.

 Does that really make sense ?

 It's eluding me..

[marcov]

It might be an 8.3 leftover thing.

[PascalDragon]

Do you now how hard that is to determine what is really going on here? Obviously it should of generated the second message but I've found that with any name in the list that has same starting names but different endings, one valid and the other isn't will give you the first error message.

This error occurs if the compiler looks for unit X, finds a compiled unit X, but the found PPU is in fact for a unit Y.

I've just tested that myself: I had a program tunitname using a unit uunitname. I then renamed the created PPU file for uunitname to uunitname2 and changed the used unit in tunitname to uunitname2. The result was this error message.

So you should probably check what might be wrong with your setup. Using the option to output tried units (-vt) might help.

[jamie]

I figured u would push it off on the user.

 Its a bug and it exist in every version I have.

Np. I'll file bug report although I know it will get squashed.

[PascalDragon]

Np. I'll file bug report although I know it will get squashed.

We need a way to reproduce it. If we can't it will be resolved with "can't reproduce".

[jamie]

Np. I'll file bug report although I know it will get squashed.

We need a way to reproduce it. If we can't it will be resolved with "can't reproduce".

Unbelievable
 

[marcov]

We need a way to reproduce it. If we can't it will be resolved with "can't reproduce".

Unbelievable
 

What is your  alternative?

[jamie]

I don't know what to tell you?

I made what I thought as a very clear explanation of the confusing message but what I get is answers like no one believes me, even after they admit to performing some test that shows something is strange, but to say there must be something wrong on my end.. ?


A bare bones console uses SysUtils, SysUtils32 in the uses list will do the same thing..

This does not happen with all units. For example If I try to do this with a FORMS unit doing like for example FORMS32 , it then just reports not finding forms32 ..

 I don't have any of those source files or compiled units on my PC's so why the strange message?

 
To me, it looks like an issue with HASH table searches where at some point the end results landed elsewhere and a cryptic message was put there instead.. Because not all Tag names force this to happen.

 WIth a GUI project I can even do it with Controls unit, Controls32 will report finding Controls instead ..

 This isn't a deal breaker, just a cosmetic issue..

 It almost looks like a debug message for a DEV that never got removed.

[Thaddy]

Jamie, simply provide working or failing complete code.
You know the drill..

Otherwise either shutup or close. And listen to Marco.

This is impossible to test because of lack of information. You do that all the time.

[BrunoK]

LAZ trunk / FPC 3.0.4

Compile message :
Fatal: Unit Graphics32 searched but Graphics found

[jamie]

It may not mean anything but thus far I can only produce this with 8 letter long names.

For example
  Systutils is 8 long and any added letters or numbers to that name that does not exist will produce the message.

 This is why I suggested a symbol table lookup (hash) could be at fault.

EDIT:

 Ok, I've got some more details.. you do not need to include a 8 character count unit name that does exist in the USES list and then include one with extra letters for this to happen.
 
 Apparently this is at the file search level.

 For example..

 I include "FileUtils" in the list that does not exist without even including the one that does exist, that would be "FileUtil"

 If I try this with shorter file names of existing units and add something to it to make it a non existing unit, it property reports the error.
 
  I haven't tested unit names larger than 8 characters that exist.

[denis.totoliciu]

For example, in the following error message:
`Fatal: Unit FileUtils searched but FileUtil found` as reported by the compiler, the problems would be the following:

1. There is a missing comma that should have been put after "searched". This is quite important when reading the error message because it helps the mind observe the separation of the two distinct subproblems at a glance: 1) that the unit `FileUtils` has been searched; 2) that *another* similarly named unit, `FileUtil` has actually been found;
2. jamie suggested a few examples of error messages on IRC which from a syntactical point of view make it for the eyes to more easily flow on the text and better intuit what the message is about from its first few words:
"Searching for xxxxx, but found xxxx. Did you mean Xxxxx?"
"Failed to find xxxxx, did you mean XXXXX?"

The punctuation marks and taxis make a big difference in textual communication and it seems that this remains available on how the compiler communicates with the programmer.

It might be annoying what is mentioned here, but it is of good intention for a better understanding of the error message and to make it easier to read.

[jamie]

But a point I made earlier is this is only happening with 8 letter long unit names.

shorter names like Forms, and if you search for Formss, will report not being able to find it without inserting the "Forms" found.

 So either way, there is something wrong with this, its not consistent with all variations of unit length names.

[Bart]

Yes, it seems that if fpc cannot find "unit_with_long_name" it will start searching for a unitname that matches the first 8 characters.

Code: Pascal  [Select][+][-]

1. uses
2.   nonexistingunit;
3.  
4. begin
5. end.

Code: [Select]

C:\Users\Bart\LazarusProjecten\ConsoleProjecten>fpc -vut test.pas
...
(PROGRAM)  Registering new unit NONEXISTINGUNIT
(PROGRAM)  Load from PROGRAM (implementation) unit NONEXISTINGUNIT
(NONEXISTINGUNIT) Loading unit NONEXISTINGUNIT
Unitsearch: nonexistingunit.ppu
Unitsearch: nonexistingunit.pp
Unitsearch: nonexistingunit.pas
Unitsearch: C:\devel\fpc\3.2.0\units\i386-win32\httpd22\nonexistingunit.ppu
Unitsearch: C:\devel\fpc\3.2.0\units\i386-win32\httpd22\nonexistingunit.pp
...
Unitsearch: C:\devel\fpc\3.2.0\bin\i386-win32\nonexistingunit.pp
Unitsearch: C:\devel\fpc\3.2.0\bin\i386-win32\nonexistingunit.pas
Unitsearch: nonexist.ppu
Unitsearch: nonexist.pp
Unitsearch: nonexist.pas
Unitsearch: C:\devel\fpc\3.2.0\units\i386-win32\httpd22\nonexist.ppu
Unitsearch: C:\devel\fpc\3.2.0\units\i386-win32\httpd22\nonexist.pp
Unitsearch: C:\devel\fpc\3.2.0\units\i386-win32\httpd22\nonexist.pas
Unitsearch: C:\devel\fpc\3.2.0\units\i386-win32\rtl\nonexist.ppu
...
Unitsearch: C:\devel\fpc\3.2.0\bin\i386-win32\nonexist.pas
Unitsearch: nonexistingunit.pp
Unitsearch: nonexistingunit.pas
Unitsearch: C:\devel\fpc\3.2.0\units\i386-win32\httpd22\nonexistingunit.pp
Unitsearch: C:\devel\fpc\3.2.0\units\i386-win32\httpd22\nonexistingunit.pas
Unitsearch: C:\devel\fpc\3.2.0\units\i386-win32\rtl\nonexistingunit.pp
Unitsearch: C:\devel\fpc\3.2.0\units\i386-win32\rtl\nonexistingunit.pas
...
Unitsearch: C:\devel\fpc\3.2.0\bin\i386-win32\nonexistingunit.pas
Unitsearch: nonexist.pp
Unitsearch: nonexist.pas
Unitsearch: C:\devel\fpc\3.2.0\units\i386-win32\httpd22\nonexist.pp
Unitsearch: C:\devel\fpc\3.2.0\units\i386-win32\httpd22\nonexist.pas
Unitsearch: C:\devel\fpc\3.2.0\units\i386-win32\rtl\nonexist.pp
Unitsearch: C:\devel\fpc\3.2.0\units\i386-win32\rtl\nonexist.pas
...
Unitsearch: C:\devel\fpc\3.2.0\bin\i386-win32\nonexist.pas
test.pas(2,3) Fatal: Can't find unit nonexistingunit used by Program
Fatal: Compilation aborted

And then if you create a nonexist.pp unit (and don't change the main program):

Code: [Select]

C:\Users\Bart\LazarusProjecten\ConsoleProjecten>fpc test.pas
Free Pascal Compiler version 3.2.0 [2020/06/04] for i386
Copyright (c) 1993-2020 by Florian Klaempfl and others
Target OS: Win32 for i386
Compiling test.pas
Compiling nonexist.pp
nonexist.pp(1,14) Error: Illegal unit name: nonexist (expecting NONEXISTINGUNIT)
nonexist.pp(3,1) Fatal: There were 1 errors compiling module, stopping
Fatal: Compilation aborted
Bart

[TRon]

I have read this thread multiple times now and I can't seem to find any flaw 

as stated (https://www.freepascal.org/docs-html/user/usersu7.html)

Also, unit names that are longer than 8 characters will first be looked for with their full length. If the unit is not found with this name, the name will be truncated to 8 characters, and the compiler will look again in the same directories, but with the truncated name.

So, unless the unit (with the long name) actually exists (still unclear for me from this thread) and the compiler produces such an error, I can't seem to determine what's is actually wrong....

The case as presented by user Bart seems to make sense as the unit should have the correct/corresponding unit header ? (but also there things are not clear enough).

shorter names like Forms, and if you search for Formss, will report not being able to find it without inserting the "Forms" found.

And also there things seems explained ambiguous. Forms is a standard (existing) unit, so it can be found while formss is not ?

Please feel free to enlighten me on something that would most certainly be something I (clearly) missed in all of this...