Josh Triplett

Reviewed in today's @rust-lang/libs-api meeting. Looks reasonable to us, approved.

It seems completely fine to `#[deny]` inside a `#[forbid]`, and I don't think we need a warning for that. (The lint should remain in the forbidden state, and should still...

@workingjubilee Agreed that we should have a test for allow-inside-deny-inside-forbid, as well as a test for warn-inside-deny-inside-forbid, both of which should be an error. (The test should check the case...

We discussed this again in today's @rust-lang/lang meeting. Concrete proposal to get consensus on: - Allow `deny` within `forbid`, silently *without* any warning, but keep the state `forbid`. Rationale: `forbid`...

@Nilstrieb Could you please remove the warning, and silently allow `deny` within `forbid` (but ensure that the state remains `forbid` so that `allow`-inside-`deny`-inside-`forbid` is still a hard error)?

You don't have to *use* the context parameter.

We discussed this in today's @rust-lang/lang meeting. We're happy to start an FCP to approve this: @rfcbot merge Please note that this change doesn't necessarily make it ABI-compatible (e.g. casting...

I'm not sure we should have this level of complexity in the standard library, to combine the classification and the to/from parts operation combined into one with an enum like...

Also, if you'd be interested in discussing this further, please feel free to either come by the Cargo office hours or the Cargo meeting.

It shouldn't be "on startup"; it should, ideally, switch the live running application when changing the system theme, which most other applications do.