If a line is too long after formatting, rustfmt gives up on formatting this line

Here is a &str constant with a very long string literal assigned to it:
const REQUIRED_SYMBOLS: &str = "qwertyuiopasdfghjklzxcvbnmQWERTYUIOPASDFGHJKLZXCVBNM`1234567890-=[]\\;',./~!@#$%^&*()_+{}:\"<>?";

The total length of this line is 129 characters. This line is not formatted at all. For example, I can do this ugliness
const   REQUIRED_SYMBOLS   :   &     str   =  "qwertyuiopasdfghjklzxcvbnmQWERTYUIOPASDFGHJKLZXCVBNM`1234567890-=[]\\;',./~!@#$%^&*()_+{}:\"<>?";

and these spaces will not be removed upon formatting. However, if we remove just two characters from the string, the line above gets formatted just fine (notice how it splits into two lines):
const REQUIRED_SYMBOLS: &str =
    "qwertyuiosdfghjklzxcvbnmQWERTYUIOPASDFGHJKLZXCVBNM`1234567890-=[]\\;',./~!@#$%^&*()_+{}:\"<>?";

The second line's length with indentation is exactly 100 characters which is the default max_width parameter value. It seems like rustfmt gives up on formatting such statements if it exceeds the max_width even after splitting it.
It doesn't have to be a constant, it may be a variable and it may have a longer name. Only string literal's length matters.
This test used default rustfmt.toml config. In my config, max_width is 80. With that config enabled I have to delete more symbols for rustfmt to format this line.

If you have the ability to change to version=Two in your config you'll pull in the update which will apply formatting, but that's gated intentionally which is why you're not seeing it.
This will be applied by default when running cargo fmt with the 2024 edition


When a user toggles JS mode for the input, bindings with the cursor in between them should be present by default (incase input has no value)

Completed in #27070


Add missing warmup_num_steps parameters to DeepSpeed config generation script.

warmup_decay_num_steps and warmup_decay_total_num_steps are valid user arguments but are not added to the config. This commit adds both arguments to the configuration output.

Thanks!


Documentation: migrate STM32G0

Summary
Documentation: migrate STM32G0
Impact
Testing
local build

Since documentation ci pass, let's merge it.


Adapter still useable?

Is this adapter still useable?
Sentry reports several issues:
https://sentry.iobroker.net/organizations/iobroker/issues/?project=30
Generic Source : https://coronavirus-19-api.herokuapp.com/ seems to be offline.

@DrozmotiX
Please let us know wether this adapter is still usable (and sentry errors will be corrected) or it should be archived as no more corona data ios published.
Thanks

https://github.com/DrozmotiX
@DutchmanNL
Please let us know wether this adapter is still usable (and sentry errors will be corrected) or it should be archived as no more corona data ios published.
Thanks

https://github.com/DrozmotiX @DutchmanNL
Please let us know wether this adapter is still usable (and sentry errors will be corrected) or it should be archived as no more corona data ios published.
Thanks

will check this weekend, if the API is dead it will be a deprecated adapter and if it will be a a lot of effort to adopt new structures true we will also deprecate as luckily the information need is not that high anymore.
Will let you know after weekend, holiday period here :)

@DutchmanNL
Dis you have time for a check in the meantime?

adapter works fine for generic data provided by official API of disease were this adapter was designed for so no action needed an all up-to-date.
Several specific local German API for "Bunderslaender" looks like been not available anymore so that specific data may be missing but no development on that possible as API's are closed.
I will close this issue as generic remark, no big issue mention on git which need effort.
For the German parts, I think will make an update to remove it as there is now high need or better said... no data available anymore on the API provided during covid pandemi


Feature request: Allow user to continue or abort between running checks and performing upgrade

Use case
Users may or may not want to proceed with the upgrade depending on the results of the pre-flight checks. They should be afforded the opportunity to view those results and determine if they are ready to proceed with the upgrade or abort and make any additional changes prior to upgrading
Solution/User Experience
After a user runs:
eksupgrade <name> <version> <region>

The process should kick off starting with the pre-flight checks. Once the results have been collected and reported to stdout (see #30), the user should receive a prompt that says something like Proceed with upgrade (Y/n)? Where if the user hits enter or Y or y, the upgrade continues, otherwise the process is aborted
Alternative solutions
Splitting out to separate commands such as:
eksupgrade --pre-flight <name> <version> <region>

eksupgrade <name> <version> <region>

The alternate solution exists with the current version of eksupgrade with a --preflight argument which runs only the pre-flight checks.

As @quixoticmonk mentioned, this exists today.  We can most certainly keep this open to implement the interactive workflow once we cutover to a more robust CLI framework versus argparse.  I'll create an issue to track the new CLI implementation.