Panic while trying compiler lint plug-in

eonil · October 3, 2019, 2:20am

This is re-posting from https://users.rust-lang.org/t/panic-while-trying-compiler-lint-plug-in/33191

I got a panic while trying lint plugin.

thread 'rustc' panicked at 'cannot access a scoped thread local variable without calling `set` first', /Users/vsts/.cargo/registry/src/github.com-1ecc6299db9ec823/scoped-tls-1.0.0/src/lib.rs:168:9
stack backtrace:

   0:        0x107359725 - <unknown>
   1:        0x10738ff90 - <unknown>
   2:        0x10734ce4b - <unknown>
   3:        0x10735da6a - <unknown>
   4:        0x10735d775 - <unknown>
   5:        0x1049035f2 - <unknown>
   6:        0x10735e2a2 - <unknown>
   7:        0x10bc6dfa5 - std::panicking::begin_panic::hca84fcd70497f4cf
   8:        0x10bb30e44 - scoped_tls::ScopedKey<T>::with::h05001199e9954d8d
   9:        0x10bb340bd - core::ptr::real_drop_in_place::hdac883c03465eb85
  10:        0x10af93395 - <impl2::Pass as rustc::lint::EarlyLintPass>::check_item::h7abd58079d101600
                               at impl2/src/lib.rs:34
  11:        0x105adbfa0 - <unknown>
  12:        0x104a27f5c - <unknown>
  13:        0x104973e2c - <unknown>
  14:        0x104a25e92 - <unknown>
  15:        0x104a233c8 - <unknown>
  16:        0x104a07202 - <unknown>
  17:        0x1049a36ae - <unknown>
  18:        0x1049db3ce - <unknown>
  19:        0x1049adbbb - <unknown>
  20:        0x1049a217c - <unknown>
  21:        0x1049a0d24 - <unknown>
  22:        0x104a2e30c - <unknown>
  23:        0x1048d7c84 - <unknown>
  24:        0x1049073b4 - <unknown>
  25:        0x1048f6ae2 - <unknown>
  26:        0x104920eb5 - <unknown>
  27:        0x104933ae9 - <unknown>
  28:        0x10736d44f - <unknown>
  29:        0x1048c9dc7 - <unknown>
  30:        0x10733f67e - <unknown>
  31:        0x10736c25e - <unknown>
  32:     0x7fff634ed2eb - <unknown>
  33:     0x7fff634f0249 - <unknown>


error: internal compiler error: unexpected panic

note: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports

note: rustc 1.40.0-nightly (702b45e40 2019-10-01) running on x86_64-apple-darwin

note: compiler flags: -C debuginfo=2 -C incremental --crate-type lib

note: some of the compiler flags provided by cargo are hidden

query stack during panic:
end of query stack
error: could not compile `lint1`.

To learn more, run the command again with --verbose.

It seems I am doing something wrong here.

My lint code is this.

#![feature(plugin_registrar)]
#![feature(box_syntax, rustc_private)]

//#![feature(macro_vis_matcher)]
//#![feature(macro_at_most_once_rep)]

extern crate syntax;

// Load rustc as a plugin to get macros
#[macro_use]
extern crate rustc;
extern crate rustc_plugin;

use rustc::lint::{EarlyContext, LintContext, LintPass, EarlyLintPass,
                  EarlyLintPassObject, LintArray};
use rustc_plugin::Registry;
use syntax::ast;

declare_lint!(TEST_LINT, Warn, "Warn about items named 'lintme'");

struct Pass;

impl LintPass for Pass {
    fn name(&self) -> &'static str {
        return "Lint1";
    }
    fn get_lints(&self) -> LintArray {
        lint_array!(TEST_LINT)
    }
}

impl EarlyLintPass for Pass {
    fn check_item(&mut self, cx: &EarlyContext, it: &ast::Item) {
        if it.ident.as_str() == "lintme" {
            cx.span_lint(TEST_LINT, it.span, "item is named 'lintme'");
        }
    }
}

#[plugin_registrar]
pub fn plugin_registrar(reg: &mut Registry) {
    reg.register_early_lint_pass(box Pass as EarlyLintPassObject);
}

Full source code is also on Github: https://github.com/eonil/rust-howto-examples/tree/5f7bf4532aef49e85c56bd86553eee319b544bc2/lint1

Default host: x86_64-apple-darwin
rustup home:  /Users/Dev/.rustup

installed toolchains
--------------------

stable-x86_64-apple-darwin
nightly-2019-08-13-x86_64-apple-darwin
nightly-2019-09-25-x86_64-apple-darwin
nightly-2019-09-26-x86_64-apple-darwin
nightly-x86_64-apple-darwin (default)

active toolchain
----------------

nightly-x86_64-apple-darwin (default)
rustc 1.40.0-nightly (702b45e40 2019-10-01)

How can I make it work? I am writing lint plug just to get fully resolved type information. AFAIK, lint stage is the simplest place to get them.

Centril · October 3, 2019, 2:59am

Please don't add new uses of the lint plug-in mechanism. We want to remove it.

eonil · October 3, 2019, 3:43am

@Centril That's sad. That was the best place for me to start accessing code semantic informations.

What should I use to get correct and fully resolved type informations? For example, I like to list all modules, structs enums and their fields and cases with fully qualified type paths.

samsieber · October 3, 2019, 4:50am

I have to second the sentiment. I too have a custom lint plugin. I am however writing it like the clippy wrapper that lets you avoid needing to annotate your code to trigger the lint plugin, with the understanding that it'll be forever on nightly. My use case is the same: analyzing fully resolved type information.

What's the future plans for clippy / rustc integration / communication?

Centril · October 3, 2019, 5:41am

github.com/rust-lang/rust

Alternatives to rustc_plugin::registry for (Servo’s) custom lints?

opened 09:04AM - 22 Jul 19 UTC

SimonSapin

A-lint A-plugin T-lang T-compiler C-feature-request

Continuing from https://github.com/rust-lang/rust/pull/62727#issuecomment-513508…389: > > Servo’s memory safety unfortunately still depends on a custom lint that checks that GC pointers on the stack are properly rooted: https://github.com/servo/servo/tree/cef98d2e5179/components/script_plugins > > I would love to find another solution, this plugin is regularly giving us headaches. But until we do, if the plugin API is removed Servo will be unable to upgrade and will be stuck on an old Rust Nightly. > > So there has been no movement since last time we discussed this. That's unfortunate. At some point however, I think it stops being reasonable for rustc to indefinitely maintain the plugin interface solely for the benefit of servo. What would it take to get rid of your reliance on this? It would take building an alternative. This thread is to discuss what alternative mechanisms already exist or could be added. # Requirements * ~Having custom attributes in source code (e.g. on `struct` definitions), ignored without warning by rustc.~ ~Currently we rely on `rustc_plugin::registry::Registry::register_attribute`.~ ~My reading of https://github.com/rust-lang/rust/issues/44690 is that the `rustfmt::` and `clippy::` attribute namespaces are hard-coded for now, and that the RFC-proposed mechanism for registering more such namespaces / tools is not implemented yet.~ **Edit:** This is now taken care of by `#![register_tool]`: https://github.com/rust-lang/rust/issues/66079 * The ability to write custom “lints”: arbitrary code that analyses a given crate and can reject it based on: - Access to everything in a crate: type definitions, expressions and sub-expressions - Access to span information, to report the location of an error when there is one - Access to full type information. For example in `let x = foo.bar();` the lint wants to find out whether the struct definition for the concrete type of `x` has one of the previously mentioned custom attributes, even if `bar` is a trait method that returns an associated type. * The lint only runs for selected crates. Or at least it has access to the crate name (and can exit early based on its own allow-list.) * Running the lint after (or during) a normal `cargo build -p script` (where `script` is the crate being linted) does not require recompiling dependencies, nor duplicating much of Cargo’s logic. As far as I understand, resolving types requires metadata for dependency crates. It’s fine if the lint runs separately from rustc, but reverse-engineering Cargo to find out which of multiple `libfoo*.rlib` with different hashes in their name is the correct one would be fragile. * Using Rust Nightly through rustup. Many years ago Servo had custom builds of rustc. It was a pain. # Nice to have * Access to rustc’s mechanism for emitting nicely-formatted diagnostics (not just access to line and column numbers) * Running the lint after *either* `cargo build` or `cargo check` does not require recompiling/rechecking dependencies. https://github.com/rust-lang/cargo/issues/3501 may be relevant. - The lint being *part of* normal compilation / checking is ideal. * Reducing reliance on rustc-internal APIs that change often would be nice, to help reduce the frequency of PRs like this: https://github.com/servo/servo/pull/23822. (We’re averaging at 20 days between Nightly upgrades in the last year, mostly because of this.) I do realize this is in contradiction with many of the other points. - Would it be crazy for RLS to have a non-interactive mode where it dumps everything it knows about a crate into a giant JSON file? ---- @jdm, @Manishearth, @nox: anything to add?

eonil · October 3, 2019, 6:12am

Okay. I'll try rustc_interface.

system · January 1, 2020, 6:12am

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.

Topic		Replies	Views
Cannot access a scoped thread local variable without calling `set` first	1	604	March 25, 2019
Using a ParseSess in a #[test] compiler	1	511	August 29, 2020
[Pre-RFC] always_panic feature and lint rule language design	16	1193	July 9, 2019
Rust 1.33.0 pre-release testing announcements	11	2579	May 29, 2019
Let's hunt this ICE down together! compiler	2	993	March 25, 2019

Panic while trying compiler lint plug-in

Related topics