Crash when using $M or $m (date and time) macros on a file that has never been saved

[rednoise0]

Issue type

Crash or freeze

Bug description

When using my own template where I altered the footer style to include either date ($M) or time ($m) variables, Musescrore 4.0.2 crashes immediately when creating a new score based on that template. This happens on three different computers, one running Windows 11, two on Windows 10, fully updated.

No crash when editing the footer for a document, only when that document is used as a template and a new score is created from it.

I tried a couple other variables and it didn't crash. It suspect it's only the date and time variables.

Sample template attached below. Logs folder attached below

CrashTestTemplate.zip
logs.zip

Steps to reproduce

1. Edit a template by going to Format | Style |Header, Footer
2. add $M or $m to any of the Footer Text boxes (I haven't tried it with the Header fields.)
3. Save and close the template.
4. Go to File | New | My Templates and chose the template you edited.
5. When you click Done, Musescore crashes hard and tries to send a crash report to Microsoft.

Screenshots/Screen recordings

No response

MuseScore Version

version (64-bit): 4.0.2-230651553, revision: github-musescore-musescore-dbe7c6d

Regression

Yes, this used to work in Musescore 3.x and now is broken

Operating system

Windows 10 Pro Version 10.0.19045 Build 19045

Additional context

(attached in Description above, but here they are again.)

logs.zip
CrashTestTemplate.zip

[Jojo-Schmitz]

Stems from https://musescore.org/en/node/347698

[oktophonie]

A not dissimilar issue: #15313

[mike-spa]

This crash is not related to templates: it happens any time you use the $M macro on a file that has never been saved. To see this, create a new file from "Choose instruments", go to Style -> Heder/Footer, use the $M macro somewhere, see crash. The crash is due to the fact that, because the file isn't yet saved to a path, the "last modified" info isn't really available.

[Jojo-Schmitz]

Looking at the code that shouldn't happen though, a not-yet saved score is "dirty" (i.e. has changes that are nor yet saved), so the current date gets used:

            case 'm':
                if (score()->dirty()) {
                    d += Time::currentTime().toString(DateFormat::ISODate);
                } else {
                    d += masterScore()->fileInfo()->lastModified().time().toString(DateFormat::ISODate);
                }
                break;
            case 'M':
                if (score()->dirty()) {
                    d += Date::currentDate().toString(DateFormat::ISODate);
                } else {
                    d += masterScore()->fileInfo()->lastModified().date().toString(DateFormat::ISODate);
                }
                break;

So I suspect that for some reason the score isn't marked dirty?

[mike-spa]

Good point. However, score()->dirty() actually just checks if the undo stack is empty, which it clearly is when the score has just been created

[Jojo-Schmitz]

Well, that did work in Mu3 though
Actually creating a new score does mark it dirty in Mu4, as seen by the asterisk (Mu3 did not, but did mark it dirty as soon as a $M got added to header/footer and didn't crash on templates using it, it just leaves the corresponding field empty).

I suspect it to be a fallout of the QString to mu::String changes