interface to filter out reports #203
Labels
abstract interpretation
Improvements to abstract interpretation
Comments
aviatesk
added
the
abstract interpretation
aviatesk
added a commit
that referenced
this issue
May 27, 2021
This PR set-ups `ignored_patterns` interface to ignore certain patterns
of reports, which can be configured by users extensively.
`ignored_patterns` is supposed to be an iterator of predicate function
and if any of given `ignored_patterns` matches a report in question,
the report will just be ignored (and nor cached).
The predicate function will be called _before_ a report is actually
constructed for the possible cut-off of the computational cost to
construct the report. Thus its signature is: `(T::Type{<:InferenceErrorReport}, interp::JETInterpreter, sv::InferenceState, spec_args::Tuple)`, where:
- `T` specifies the kind of report
- `interp` gives the context of whole analysis
- `sv::InferenceState` gives the local context of analysis
- and `spec_args` will be report-specific arguments
To inject predicate checks, now each report is constructed via `@report!`
macro, which first checks if the report matches any of `ignored_patterns`,
and if not, constructs the report and pushes it to `JETInterpreter` as
the previous `report!` function did.
This PR also defines `DEFAULT_IGNORED_PATTERNS`, namely `ignored_patterns`
applied by default. Currently it consists of `ignore_corecompiler_undefglobal`,
which ignores undefined global names in `Core.Compiler`, and it should
have some positive effects, like reduce false positive error reports
involved with `Base.return_types` and its family in general, improve
analysis performance for JET's self-profiling, etc.
The support of user-predicate functions specified via .JET configuration
file is somewhat tricky, but currently this PR uses RuntimeGeneratedFunctions.jl
and it seems to work. I'm not sure if `@nospecialize` notations works
correctly in `RuntimeGeneratedFunction`s, so some insights or benchmarks
on it will be very welcomed.
aviatesk
added a commit
that referenced
this issue
May 27, 2021
This PR set-ups `ignored_patterns` interface to ignore certain patterns
of reports, which can be configured by users extensively.
`ignored_patterns` is supposed to be an iterator of predicate function
and if any of given `ignored_patterns` matches a report in question,
the report will just be ignored (and nor cached).
The predicate function will be called _before_ a report is actually
constructed for the possible cut-off of the computational cost to
construct the report. Thus its signature is:
`(T::Type{<:InferenceErrorReport}, interp::JETInterpreter,
sv::InferenceState, spec_args::Tuple)`, where:
- `T` specifies the kind of report
- `interp` gives the context of whole analysis
- `sv::InferenceState` gives the local context of analysis
- and `spec_args` will be report-specific arguments
To inject predicate checks, now each report is constructed via
`@report!`
macro, which first checks if the report matches any of
`ignored_patterns`,
and if not, constructs the report and pushes it to `JETInterpreter` as
the previous `report!` function did.
This PR also defines `DEFAULT_IGNORED_PATTERNS`, namely
`ignored_patterns`
applied by default. Currently it consists of
`ignore_corecompiler_undefglobal`,
which ignores undefined global names in `Core.Compiler`, and it should
have some positive effects, like reduce false positive error reports
involved with `Base.return_types` and its family in general, improve
analysis performance for JET's self-profiling, etc.
The support of user-predicate functions specified via .JET configuration
file is somewhat tricky, but currently this PR uses
RuntimeGeneratedFunctions.jl
and it seems to work. I'm not sure if `@nospecialize` notations works
correctly in `RuntimeGeneratedFunction`s, so some insights or benchmarks
on it will be very welcomed.
aviatesk
added a commit
that referenced
this issue
May 27, 2021
This PR set-ups `ignored_patterns` interface to ignore certain patterns
of reports, which can be configured by users extensively.
`ignored_patterns` is supposed to be an iterator of predicate function
and if any of given `ignored_patterns` matches a report in question,
the report will just be ignored (and nor cached).
The predicate function will be called _before_ a report is actually
constructed for the possible cut-off of the computational cost to
construct the report. Thus its signature is:
`(T::Type{<:InferenceErrorReport}, interp::JETInterpreter,
sv::InferenceState, spec_args::Tuple)`, where:
- `T` specifies the kind of report
- `interp` gives the context of whole analysis
- `sv::InferenceState` gives the local context of analysis
- and `spec_args` will be report-specific arguments
To inject predicate checks, now each report is constructed via
`@report!`
macro, which first checks if the report matches any of
`ignored_patterns`,
and if not, constructs the report and pushes it to `JETInterpreter` as
the previous `report!` function did.
This PR also defines `DEFAULT_IGNORED_PATTERNS`, namely
`ignored_patterns`
applied by default. Currently it consists of
`ignore_corecompiler_undefglobal`,
which ignores undefined global names in `Core.Compiler`, and it should
have some positive effects, like reduce false positive error reports
involved with `Base.return_types` and its family in general, improve
analysis performance for JET's self-profiling, etc.
The support of user-predicate functions specified via .JET configuration
file is somewhat tricky, but currently this PR uses
RuntimeGeneratedFunctions.jl
and it seems to work. I'm not sure if `@nospecialize` notations works
correctly in `RuntimeGeneratedFunction`s, so some insights or benchmarks
on it will be very welcomed.
aviatesk
added a commit
that referenced
this issue
May 27, 2021
This PR set-ups `ignored_patterns` interface to ignore certain patterns
of reports, which can be configured by users extensively.
`ignored_patterns` is supposed to be an iterator of predicate function
and if any of given `ignored_patterns` matches a report in question,
the report will just be ignored (and nor cached).
The predicate function will be called _before_ a report is actually
constructed for the possible cut-off of the computational cost to
construct the report. Thus its signature is:
`(T::Type{<:InferenceErrorReport}, interp::JETInterpreter,
sv::InferenceState, spec_args::Tuple)`, where:
- `T` specifies the kind of report
- `interp` gives the context of whole analysis
- `sv::InferenceState` gives the local context of analysis
- and `spec_args` will be report-specific arguments
To inject predicate checks, now each report is constructed via
`@report!`
macro, which first checks if the report matches any of
`ignored_patterns`,
and if not, constructs the report and pushes it to `JETInterpreter` as
the previous `report!` function did.
This PR also defines `DEFAULT_IGNORED_PATTERNS`, namely
`ignored_patterns`
applied by default. Currently it consists of
`ignore_corecompiler_undefglobal`,
which ignores undefined global names in `Core.Compiler`, and it should
have some positive effects, like reduce false positive error reports
involved with `Base.return_types` and its family in general, improve
analysis performance for JET's self-profiling, etc.
The support of user-predicate functions specified via .JET configuration
file is somewhat tricky, but currently this PR uses
RuntimeGeneratedFunctions.jl
and it seems to work. I'm not sure if `@nospecialize` notations works
correctly in `RuntimeGeneratedFunction`s, so some insights or benchmarks
on it will be very welcomed.
aviatesk
added a commit
that referenced
this issue
May 28, 2021
This PR set-ups `ignored_patterns` interface to ignore certain patterns
of reports, which can be configured by users extensively.
`ignored_patterns` is supposed to be an iterator of predicate function
and if any of given `ignored_patterns` matches a report in question,
the report will just be ignored (and nor cached).
The predicate function will be called _before_ a report is actually
constructed for the possible cut-off of the computational cost to
construct the report. Thus its signature is:
`(T::Type{<:InferenceErrorReport}, interp::JETInterpreter,
sv::InferenceState, spec_args::Tuple)`, where:
- `T` specifies the kind of report
- `interp` gives the context of whole analysis
- `sv::InferenceState` gives the local context of analysis
- and `spec_args` will be report-specific arguments
To inject predicate checks, now each report is constructed via
`@report!`
macro, which first checks if the report matches any of
`ignored_patterns`,
and if not, constructs the report and pushes it to `JETInterpreter` as
the previous `report!` function did.
This PR also defines `DEFAULT_IGNORED_PATTERNS`, namely
`ignored_patterns`
applied by default. Currently it consists of
`ignore_corecompiler_undefglobal`,
which ignores undefined global names in `Core.Compiler`, and it should
have some positive effects, like reduce false positive error reports
involved with `Base.return_types` and its family in general, improve
analysis performance for JET's self-profiling, etc.
The support of user-predicate functions specified via .JET configuration
file is somewhat tricky, but currently this PR uses
RuntimeGeneratedFunctions.jl
and it seems to work. I'm not sure if `@nospecialize` notations works
correctly in `RuntimeGeneratedFunction`s, so some insights or benchmarks
on it will be very welcomed.
aviatesk
added a commit
that referenced
this issue
May 29, 2021
This PR set-ups `ignored_patterns` interface to ignore certain patterns
of reports, which can be configured by users extensively.
`ignored_patterns` is supposed to be an iterator of predicate function
and if any of given `ignored_patterns` matches a report in question,
the report will just be ignored (and nor cached).
The predicate function will be called _before_ a report is actually
constructed for the possible cut-off of the computational cost to
construct the report. Thus its signature is:
`(T::Type{<:InferenceErrorReport}, interp::JETInterpreter, sv::InferenceState, spec_args::Tuple)`, where:
- `T` specifies the kind of report
- `interp` gives the context of whole analysis
- `sv::InferenceState` gives the local context of analysis
- and `spec_args` will be report-specific arguments
To inject predicate checks, now each report is constructed via
`@report!`
macro, which first checks if the report matches any of
`ignored_patterns`,
and if not, constructs the report and pushes it to `JETInterpreter` as
the previous `report!` function did.
This PR also defines `DEFAULT_IGNORED_PATTERNS`, namely
`ignored_patterns`
applied by default. Currently it consists of `ignore_corecompiler_undefglobal`,
which ignores undefined global names in `Core.Compiler`, and it should
have some positive effects, like reduce false positive error reports
involved with `Base.return_types` and its family in general, improve
analysis performance for JET's self-profiling, etc.
The support of user-predicate functions specified via .JET configuration
file is somewhat tricky, but currently this PR uses RuntimeGeneratedFunctions.jl
and it seems to work. I'm not sure if `@nospecialize` notations works
correctly in `RuntimeGeneratedFunction`s, so some insights or benchmarks
on it will be very welcomed.
aviatesk
added a commit
that referenced
this issue
May 29, 2021
This PR set-ups `ignored_patterns` interface to ignore certain patterns
of reports, which can be configured by users extensively.
`ignored_patterns` is supposed to be an iterator of predicate function
and if any of given `ignored_patterns` matches a report in question,
the report will just be ignored (and nor cached).
The predicate function will be called _before_ a report is actually
constructed for the possible cut-off of the computational cost to
construct the report. Thus its signature is:
`(T::Type{<:InferenceErrorReport}, interp::JETInterpreter, sv::InferenceState, spec_args::Tuple)`, where:
- `T` specifies the kind of report
- `interp` gives the context of whole analysis
- `sv::InferenceState` gives the local context of analysis
- and `spec_args` will be report-specific arguments
To inject predicate checks, now each report is constructed via
`@report!`
macro, which first checks if the report matches any of
`ignored_patterns`,
and if not, constructs the report and pushes it to `JETInterpreter` as
the previous `report!` function did.
This PR also defines `DEFAULT_IGNORED_PATTERNS`, namely
`ignored_patterns`
applied by default. Currently it consists of `ignore_corecompiler_undefglobal`,
which ignores undefined global names in `Core.Compiler`, and it should
have some positive effects, like reduce false positive error reports
involved with `Base.return_types` and its family in general, improve
analysis performance for JET's self-profiling, etc.
The support of user-predicate functions specified via .JET configuration
file is somewhat tricky, but currently this PR uses RuntimeGeneratedFunctions.jl
and it seems to work. I'm not sure if `@nospecialize` notations works
correctly in `RuntimeGeneratedFunction`s, so some insights or benchmarks
on it will be very welcomed.
aviatesk
added a commit
that referenced
this issue
May 29, 2021
This PR set-ups `ignored_patterns` interface to ignore certain patterns
of reports, which can be configured by users extensively.
`ignored_patterns` is supposed to be an iterator of predicate function
and if any of given `ignored_patterns` matches a report in question,
the report will just be ignored (and nor cached).
The predicate function will be called _before_ a report is actually
constructed for the possible cut-off of the computational cost to
construct the report. Thus its signature is:
`(T::Type{<:InferenceErrorReport}, interp::JETInterpreter, sv::InferenceState, spec_args::Tuple)`, where:
- `T` specifies the kind of report
- `interp` gives the context of whole analysis
- `sv::InferenceState` gives the local context of analysis
- and `spec_args` will be report-specific arguments
To inject predicate checks, now each report is constructed via `@report!`
macro, which first checks if the report matches any of `ignored_patterns`,
and if not, constructs the report and pushes it to `JETInterpreter` as
the previous `report!` function did.
This PR also defines `DEFAULT_IGNORED_PATTERNS`, namely `ignored_patterns`
applied by default. Currently it consists of `ignore_corecompiler_undefglobal`,
which ignores undefined global names in `Core.Compiler`, and it should
have some positive effects, like reduce false positive error reports
involved with `Base.return_types` and its family in general, improve
analysis performance for JET's self-profiling, etc.
The support of user-predicate functions specified via .JET configuration
file is somewhat tricky, but currently this PR uses RuntimeGeneratedFunctions.jl
and it seems to work. I'm not sure if `@nospecialize` notations works
correctly in `RuntimeGeneratedFunction`s, so some insights or benchmarks
on it will be very welcomed.
aviatesk
added a commit
that referenced
this issue
Jun 1, 2021
This PR set-ups `ignored_patterns` interface to ignore certain patterns
of reports, which can be configured by users extensively.
`ignored_patterns` is supposed to be an iterator of predicate function
and if any of given `ignored_patterns` matches a report in question,
the report will just be ignored (and nor cached).
The predicate function will be called _before_ a report is actually
constructed for the possible cut-off of the computational cost to
construct the report. Thus its signature is:
`(T::Type{<:InferenceErrorReport}, interp::JETInterpreter, sv::InferenceState, spec_args::Tuple)`, where:
- `T` specifies the kind of report
- `interp` gives the context of whole analysis
- `sv::InferenceState` gives the local context of analysis
- and `spec_args` will be report-specific arguments
To inject predicate checks, now each report is constructed via `@report!`
macro, which first checks if the report matches any of `ignored_patterns`,
and if not, constructs the report and pushes it to `JETInterpreter` as
the previous `report!` function did.
This PR also defines `DEFAULT_IGNORED_PATTERNS`, namely `ignored_patterns`
applied by default. Currently it consists of `ignore_corecompiler_undefglobal`,
which ignores undefined global names in `Core.Compiler`, and it should
have some positive effects, like reduce false positive error reports
involved with `Base.return_types` and its family in general, improve
analysis performance for JET's self-profiling, etc.
The support of user-predicate functions specified via .JET configuration
file is somewhat tricky, but currently this PR uses RuntimeGeneratedFunctions.jl
and it seems to work. I'm not sure if `@nospecialize` notations works
correctly in `RuntimeGeneratedFunction`s, so some insights or benchmarks
on it will be very welcomed.
aviatesk
added a commit
that referenced
this issue
Jun 1, 2021
This is an alternative for #204, and will supersedes it. This PR setups `report_pass::ReportPass` interface, which controls overall `JETInterpreter`'s error report analysis and can be extensively configured by trait overloads; now users can implement their own report pass and set up new report logic, ignore existing reports, etc. By default, JET offers `BasicPass<:ReportPass` and `SoundPass<:ReportPass`, but the latter is still in very WIP. Also, the configuration support via TOML file would be really hard given this PR. I think we will move to Julia file based configuration support. This interface also suggests the possibility of pluggable analysis requested #169, by allowing users to subtype `JETInterpreter`. The changes are kinda really big, and so maybe I will focus on coding in this PR and leave documentation and examples to another PR.
aviatesk
added a commit
that referenced
this issue
Jun 1, 2021
This is an alternative for #204, and will supersedes it. This PR setups `report_pass::ReportPass` interface, which controls overall `JETInterpreter`'s error report analysis and can be extensively configured by trait overloads; now users can implement their own report pass and set up new report logic, ignore existing reports, etc. By default, JET offers `BasicPass<:ReportPass` and `SoundPass<:ReportPass`, but the latter is still in very WIP. Also, the configuration support via TOML file would be really hard given this PR. I think we will move to Julia file based configuration support. This interface also suggests the possibility of pluggable analysis requested #169, by allowing users to subtype `JETInterpreter`. The changes are kinda really big, and so maybe I will focus on coding in this PR and leave documentation and examples to another PR.
aviatesk
added a commit
that referenced
this issue
Jun 2, 2021
This is an alternative for #204, and will supersedes it. This PR setups `report_pass::ReportPass` interface, which controls overall `JETInterpreter`'s error report analysis and can be extensively configured by trait overloads; now users can implement their own report pass and set up new report logic, ignore existing reports, etc. By default, JET offers `BasicPass<:ReportPass` and `SoundPass<:ReportPass`, but the latter is still in very WIP. Also, the configuration support via TOML file would be really hard given this PR. I think we will move to Julia file based configuration support. This interface also suggests the possibility of pluggable analysis requested #169, by allowing users to subtype `JETInterpreter`. The changes are kinda really big, and so maybe I will focus on coding in this PR and leave documentation and examples to another PR.
aviatesk
added a commit
that referenced
this issue
Jun 3, 2021
This is an alternative for #204, and will supersedes it. This PR setups `report_pass::ReportPass` interface, which controls overall `JETInterpreter`'s error report analysis and can be extensively configured by trait overloads; now users can implement their own report pass and set up new report logic, ignore existing reports, etc. By default, JET offers `BasicPass<:ReportPass` and `SoundPass<:ReportPass`, but the latter is still in very WIP. Also, the configuration support via TOML file would be really hard given this PR. I think we will move to Julia file based configuration support. This interface also suggests the possibility of pluggable analysis requested #169, by allowing users to subtype `JETInterpreter`. The changes are kinda really big, and so maybe I will focus on coding in this PR and leave documentation and examples to another PR.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Given the accuracy of current abstract interpretation, JET can end up with lots of false positive errors, especially when analyzing code with heavy dependencies.
It also can slow down analysis to great extent, since updating and caching lots of reports can be really time-consuming.
So for the meanwhile, we need an interface to filter out reports during the abstract interpretation process.
Then we can e.g. collect error points reported from a specific module, which can cut off (maybe useless from user's point of view) reports and improve analysis performance, etc.
The text was updated successfully, but these errors were encountered: