[Known Bug] Arduino IDE (2.0, different RCs) - Autocomplete not working for specific targets

Software IDE 2.x
1

Hello,

Over the course of me using Arduino IDE I noticed the autocomplete (or as it is called in the settings "Editor Quick Suggestions") not working for me.

With rc7 and lower, what happens is that the suggestions work for the first 30 seconds or so after I started up the IDE, then nothing.
Current behavior with rc8 which I just tried is that it doesn't work at all. In rare instances for some keywords, for example if I am about to type in "include", a crossed out "include" shows up.

Screenshot_2022-06-28_12-15-48

I am running XUbuntu 22.04 LTS and the download option I am using for the IDE is the 64bit zip file which I am of course unpacking.

Any suggestion as to how I can investigate this is very much appreciated.
If there is any additional info you need please let me know.

2

Update:
I managed to follow along the instructions of this post:

While I could not find the " Search Settings" field in the preferences window that I opened using the aforementioned inputs, I did try to just rename the listed config folders instead, which seems to have worked for now fortunately!

3

It is here:

image

Note that the "Search Settings" text is a placeholder, so as soon as you start typing your search keywords in that field the placeholder text disappears from the field.

I'm glad it is working now. Great work on finding the fix!

1 Like
4

Oooh, I selected "Open Preferences...".
Shame on me. Thank you for pointing it out!

And one more thing. I'm probably missing it so I'm phrasing my question carefully. Where on this sub do I see the recommendation that I should (and actually can) reset configuration by removing (or for a test renaming) specific folders?
Besides the project folder settings I see no other indication anywhere that there is anything stored outside of the IDE's folder, besides your linked post and my suspicion because the IDE seems to keep state of windows and settings across different portable versions.
I feel like I'm missing something.

5

This is not something that is recommended. It is a technique that can be used in certain very rare circumstances for troubleshooting, guided by someone skilled in technical support of this software. It may also be used occasionally by advanced beta testers to simulate the fresh install conditions.

I don't expect that there is any application for such a technique for standard use of the Arduino IDE, and I also have no idea how this technique might have helped in your case (it was only intended to assist with the investigation where I described it in CPU utilization Very High - #13 by ptillisch, without any expectation that it would result in a lasting fix for the problem).

The exception is this folder:

Deleting this folder or a subset of its contents is sometimes recommended as a fix for certain problems. This path is the same for Arduino IDE 2.x as for Arduino IDE 2.x and there is some official documentation of that technique. For example:

If we do find there is some need for users to remove the other folders on their own, we can produce equivalent documentation, but I would not do it without good cause because I generally avoid recommending users to do any deletions unless absolutely necessary, since we can't assume everyone has the level of familiarity in working with file systems that is required to do this in a safe manner.

1 Like
6

Then how about a reset feature then that does this for you, or that for one-time starts naked without the existing config files (perhaps implementing it as a command arg)?
I mean this fixed my issue in 10 seconds, and if not, it would have been valuable information because it would be unrelated to a borked config.

Anyway, I'm happy that it is working again for me, and thank you for your insight and time!

7

Unfortunately the issue resurfaced.
The fix that worked for me last time doesn't work this time.
Current behavior with rc8 is exactly as described in my opening post.

I enabled language-server-logging and uploaded the files as an archive.

languageserverlog.zip (30.5 KB)

8

I noticed that autocomplete works if I set the target board to Arduino Nano.

It seems the suggestions only don't work for the following board targets:

ATtiny3224/1624/824/424 w/Optiboot
ATtiny3226/1626/826/426 w/Optiboot
ATtiny3227/1627/827/427 w/Optiboot

I opened up a ticket on megaTinyCore's repo, here is the link to it:

9

Hi @cookiefan. Great work on investigating the problem!

There is a related issue in the Arduino IDE repository:

That issue is more for the purposes of documenting the limitation rather than to track a task for the developers because unfortunately this seems to be a deficiency in the standard free open source clangd C++ language server that provides the autocomplete and other related capabilities to Arduino IDE.

1 Like
10

Thank you for the link.
Honestly, looking at all of this, I got the feeling that it doesn't look very certain as to what the cause of this is.
Your linked issue talks about generation 1 attinys, but they work flawlessly (at least now).
It seems very odd to me and with the github web search being quite finicky, I couldn't definitely pinpoint where the targets are actually being defined in megaTinyCore, and what the precise information flow of all these components is.
That said, I have to make sense of the inner workings and glue logic of three separate projects at once, so my capabilities are quite limited in grasping this anytime soon.

All in all with the idea that I am getting from this and the creation date of this issue I don't feel very encouraged in hoping that there will be a fix (or at least an automatic workaround) for this anytime soon.

It is a bit of a shame and mess, because I have grown quite fond of the IDE and the entire toolchain and community, but the language server is also noticeably slow for me and it is quite a bother because for me it is such an essential feature.

Anyways, thank you for your input and your time and help!

11

Support was added to clangd last September:

However, that only made it into a production release in March, and that release into the Arduino IDE last month.

It looks like megaAVR 0-series is on the way too!

Yeah, considering how well done GitHub is in almost every other way, it is astonishing how terrible the search is. It seems like developers tend to go way too far with algorithms and fuzziness with searches. You are better off to just clone or download the repository and use a functional text search tool.

First of all, note that there is a bug in the Arduino IDE that causes this to be handled incorrectly, as I mentioned over on the megaTinyCore issue. But I'll explain how it should work.

I'll work backwards through it. platform.txt contains the patterns the compilation commands are generated from. Here is the one for C++ files:

https://github.com/SpenceKonde/megaTinyCore/blob/2.5.11/megaavr/platform.txt#L75

recipe.cpp.o.pattern="{compiler.path}{compiler.cpp.cmd}" {compiler.cpp.flags} -mmcu={build.mcu} {build.optiondefines} {build.versiondefines} {compiler.cpp.extra_flags} {build.extra_flags} "-I{build.core.path}/api/deprecated" {includes} "{source_file}" -o "{object_file}"

The relevant part of the pattern is -mmcu={build.mcu}

{build.mcu} is a reference to a property named build.mcu. It will be replaced by the value of that property.

The build.mcu property is defined in boards.txt.

boards.txt contains the definitions of each of the boards listed under the Tools > Board menu for megaTinyCore. The properties in boards.txt prefixed with the ID of the currently selected board are defined.

The board ID of the "ATtiny3226/3216/1626/1616/1606/826/816/806/426/416/406" board is atxy6, so when that board is selected the build.mcu property is set to the value defined by atxy6.build.mcu:

https://github.com/SpenceKonde/megaTinyCore/blob/2.5.11/megaavr/boards.txt#L469

atxy6.build.mcu=attiny{build.attiny}

You will notice there is a reference to the build.attiny in this property definition. This property is defined according to the selection made from the Tools > Chip custom board option menu. These properties work similarly to how the board-associated properties are defined according to the board ID prefix, except in this case there is a menu ID and an option ID in addition to the board ID. The menu ID in this case is chip and the option ID is 3226:

https://github.com/SpenceKonde/megaTinyCore/blob/2.5.11/megaavr/boards.txt#L541

atxy6.menu.chip.3226=ATtiny3226

https://github.com/SpenceKonde/megaTinyCore/blob/2.5.11/megaavr/boards.txt#L545

atxy6.menu.chip.3226.build.attiny=3226

Put it all together and you get the compiler flag -mmcu=attiny3226

That is an odd takeaway considering you just noted that support for the tinyAVR 0-series and 1-series has been added since the time the issue was created.

Things move slowly, but they do move. If you would like to move them forward faster, feel free to make the necessary improvements to the free open source LLVM/clang/clangd project.

There is currently work in progress on multiple fronts to improve the performance:

1 Like
12

Hello,

Thank you for your very detailed reply and the explanations and references. It is very much appreciated.

That is true, but I hope it makes more sense that I came to that conclusion thinking that support hasn't been added, but it just happened to work for those MCUs because I assumed the nature of the bug was it ignores more recently added targets, thus with the addition of the 2-series it just resolved itself, or rather moved.
I didn't know they were actually flat out completely missing.

13

Hopefully the support for the missing AVRs will come soon.

I was actually surprised at how minimal the changes were to add the tinyAVR 0-series and 1-series, as shown in that commit. This is definitely encouraging to me.

1 Like
14

I had the same initial thought, but was somewhat skeptical and rather assumed that I was missing something.
I'm glad to know that you have the same impression, and this actually encourages me more.

Maybe I'll have a look at it in the next days. Unfortunately I fried my serial adapter, accidentally shorting it as I was trying to debug high power consumption of one of my designs which I assume might be due to parasitic capacitance (I barely heard of this being referenced on the megaTinyCore repo in an issue on pure occasion, I never had that problem and I'm not finding any other resources on how to debug this and how this actually causes higher current usage).
Anyway, my free-time schedule is pretty open now thanks to my misstep.

15

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.