rust/tests/ui-fulldeps/plugin/lint-plugin-forbid-cmdline.rs

// aux-build:lint-plugin-test.rs
// ignore-stage1
// compile-flags: -F test-lint

#![feature(plugin)]
#![plugin(lint_plugin_test)]
//~^ WARN use of deprecated attribute `plugin`
fn lintme() { } //~ ERROR item is named 'lintme'

#[allow(test_lint)] //~ ERROR allow(test_lint) incompatible
                    //~| ERROR allow(test_lint) incompatible

pub fn main() {
    lintme();
}
Moved issue tests to subdirs and normalised names. 2019-03-11 19:49:17 -05:00			`// aux-build:lint-plugin-test.rs`
Test lint plugins 2014-06-18 15:46:48 -05:00			`// ignore-stage1`
			`// compile-flags: -F test-lint`

Replace #[phase] with #[plugin] / #[macro_use] / #[no_link] 2014-12-31 22:43:46 -06:00			`#![feature(plugin)]`
Use a crate attribute to load plugins #[plugin] #[no_link] extern crate bleh; becomes a crate attribute #![plugin(bleh)] The feature gate is still required. It's almost never correct to link a plugin into the resulting library / executable, because it will bring all of libsyntax and librustc with it. However if you really want this behavior, you can get it with a separate `extern crate` item in addition to the `plugin` attribute. Fixes #21043. Fixes #20769. [breaking-change] 2015-02-06 15:56:38 -06:00			`#![plugin(lint_plugin_test)]`
--bless ui-fulldeps tests 2019-10-03 02:33:28 -05:00			//~^ WARN use of deprecated attribute `plugin`
Test lint plugins 2014-06-18 15:46:48 -05:00			`fn lintme() { } //~ ERROR item is named 'lintme'`

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 17:14:38 -06:00			`#[allow(test_lint)] //~ ERROR allow(test_lint) incompatible`
			`//~\| ERROR allow(test_lint) incompatible`
Merge `builtins` into `EarlyLintPassObjects`. This avoids calling `early_lint_node` twice. Note: one `early_lint_node` call had `!pre_expansion` for the second argument and the other had `false`. The new single call just has `!pre_expansion`. This results in a reduction of duplicate error messages in some `ui-fulldeps` tests. The order of some `ui-fulldeps` output also changes, but that doesn't matter. 2022-11-30 20:22:08 -06:00
Test lint plugins 2014-06-18 15:46:48 -05:00			`pub fn main() {`
			`lintme();`
			`}`