os-rust/tests/ui/lint/lint-forbid-attr.rs

#![forbid(deprecated)]

#[allow(deprecated)]
//~^ ERROR allow(deprecated) incompatible
//~| ERROR allow(deprecated) incompatible
fn main() {
}
Fix up some tests for feature staging 2015-01-16 10:25:13 -08:00			`#![forbid(deprecated)]`
Test lint plugins 2014-06-18 13:46:48 -07:00
Update E0453 to new error format Fixes #35929. Part of #35233. r? @jonathandturner 2016-08-25 19:09:48 +05:30			`#[allow(deprecated)]`
Use true previous lint level when detecting overriden forbids Previously, cap-lints was ignored when checking the previous forbid level, which meant that it was a hard error to do so. This is different from the normal behavior of lints, which are silenced by cap-lints; if the forbid would not take effect regardless, there is not much point in complaining about the fact that we are reducing its level. It might be considered a bug that even `--cap-lints deny` would suffice to silence the error on overriding forbid, depending on if one cares about failing the build or precisely forbid being set. But setting cap-lints to deny is quite odd and not really done in practice, so we don't try to handle it specially. This also unifies the code paths for nested and same-level scopes. However, the special case for CLI lint flags is left in place (introduced by #70918) to fix the regression noted in #70819. That means that CLI flags do not lint on forbid being overridden by a non-forbid level. It is unclear whether this is a bug or a desirable feature, but it is certainly inconsistent. CLI flags are a sufficiently different "type" of place though that this is deemed out of scope for this commit. 2020-11-07 18:14:38 -05:00			`//~^ ERROR allow(deprecated) incompatible`
			`//~\| ERROR allow(deprecated) incompatible`
Test lint plugins 2014-06-18 13:46:48 -07:00			`fn main() {`
			`}`