package lint
import "github.com/zmap/zlint/v3/integration/lints/lint"
Index ¶
- type File
- func NewFile(name, src string) *File
- func Parse(path string) (*ast.File, *File, error)
- func (f *File) LineOf(pos token.Pos) int
- type Lint
- type Result
- func NewResult(message string) *Result
- func RunLint(tree *ast.File, file *File, lint Lint) *Result
- func RunLintForFile(path string, lint Lint) (*Result, error)
- func RunLints(path string, lints []Lint) ([]*Result, error)
- func (r *Result) AddCodeCitation(start, end token.Pos, file *File) *Result
- func (r *Result) SetCitations(citations ...string) *Result
- func (r *Result) String() string
Types ¶
type File ¶
func NewFile ¶
func Parse ¶
func (*File) LineOf ¶
LineOf computes which line a particular position within a file lands on.
This is not the greatest song in the world. No, this is just a tribute. Couldn't remember the greatest song in the world. No, this is just a tribute!
The word "remember" begins at position 81 within this text, therefor LineOf(81) should return line 3.
type Lint ¶
type Lint interface { Lint(tree *ast.File, file *File) *Result CheckApplies(tree *ast.File, file *File) bool }
type Result ¶
type Result struct {
// contains filtered or unexported fields
}
A Result encodes any unmet expectation laid out by your lint. It consists of a single message, a list of code citations, and a list of lint citations.
The message should be succinct and descriptive of the core issue. This message can only be set in the constructor, NewResult. For example...
"Go style guides suggest not using bare returns in complex functions"
Code citations are the locations within the file that did not meet your expectations. Please see AddCodeCitations for information on how to add these to the Result type. Adding a code citation will result in the file, line number and raw source code appearing in the lint result. For example...
File ../../lints/cabf_br/lint_cab_dv_conflicts_with_locality.go, line 28 func (l *certPolicyConflictsWithLocality) Initialize() error { return nil }
The lint citations are additional information to help the contributor understand why their code failed this lint and, if possible, some hints or resources on how to correct the issue. Every citation will be listed on its own line.
func NewResult ¶
func RunLint ¶
func RunLintForFile ¶
func RunLints ¶
func (*Result) AddCodeCitation ¶
AddCodeCitation takes the starting and ending position of a block of code within a file. Upon calling the String method, every code citation will be printed alongside the result. This code citation lists the file and line of the code in question as well as the raw block of source code.
For example:
File ../../lints/cabf_br/lint_cab_dv_conflicts_with_locality.go, line 28 func (l *certPolicyConflictsWithLocality) Initialize() error { return nil }
func (*Result) SetCitations ¶
SetCitations sets a list of citations that users can reference in order to understand the error that they received. Upon calling the String method each citation will be listed on their on own line.
For example:
For more information, please see the following citations. https://github.com/zmap/zlint/issues/371 https://golang.org/doc/effective_go.html#init
The above links a GitHub issue that discuss the lint in question as well as a link to Golang's magic `init` method (because the lint in question is asking the contributor to implement `init` at a particular spot in the file).
func (*Result) String ¶
Source Files ¶
- Version
- v3.6.6 (latest)
- Published
- Apr 19, 2025
- Platform
- linux/amd64
- Imports
- 7 packages
- Last checked
- 1 week ago –
Tools for package owners.