Use our own release profile to insulate from custom release profiles

[RossSmyth]

Ok this should actually fix the issue with rust-lang/miri#3313 in a nice way.

It also allows people to override the profile, since profiles are at the lowest precedence. So if someone wants to build a sysroot with -Cdebug-assertions=true they still can and it will override the profile.

[RossSmyth]

I was not able to run the tests on my computer so lets see how CI feels

[RossSmyth]

ok that is what I saw on my computer so it's not just a Windows moment.

[RalfJung]

We have Windows on CI so I'd hope that on master, tests work for you? If not, please open an issue.

[RossSmyth]

Yeah they work I just was dumb and didn't check

[RalfJung]

Thanks, the general direction looks good!

[RossSmyth]

Was wondering if this could be moved forward at all as I think this is a good change (which is mainly to say I still hit this issue).

The options are

1. Override all keys

I chose this as I think it is the safest option. This allows the sysroot to be built by default exactly how we describe it, with known safe configuration options.

2. Only override the "known problematic" keys. Which is to say, at this point in time that I know of, the panic strategy.

But there may be other weird configurations I do now know of that could break things in the future because all other potentially custom keys would be inherited.

The biggest risk is that when Cargo stabilizes new profile keys, these will automatically be inherited from the release profile. Which means a potential custom release profile. For the almost all of the unstable keys I am aware of this isn't a big deal. But the rustflags key could effect this.

To me, the second option seems to have more risk because it has all the risk of option 1 (potential future weird profiles), as well as more risk of inheriting possible current weird profiles.

[RalfJung]

Option 1 has the extra risk that cargo may change the defaults and we fail to reflect that. I'm not happy about the prospect of having to maintain a copy of https://doc.rust-lang.org/cargo/reference/profiles.html#release. We also don't know why people override these things, and which problems could be caused by overwriting them back. That's why I prefer option 2.

[RossSmyth]

As a person who overwrites them, I do it so that my default release profile system wide is what I want it to be. Primarily because cargo install uses release by default, and I don't use release anywhere else.

I'm not sure what you mean by "overwriting them back" as nothing is being overwritten. Just setting the default values for a custom sysroot build. Since it seems sysroots are sensitive to these settings, as that is why I even have had to do this, having safe defaults that need to be explicitly overridden by the user seems like the best bet. For example Cargo has been kicking around turning thin LTO on by default for release. I'm not sure how that could effect this project and/or miri sysroots, but it might.

wrt maintaining a copy, I don't really see that as a huge maintenance burden as profiles are changed so slowly.

Anyways I'll just change it to option 2 since getting this out the door is more important since currently I have to delete my cargo config file every time miri builds a new sysroot which is annoying.

[RalfJung]

Thanks!