lean4-htt

History

David Thrane Christiansen 456ed44550 feat: add a linter for local vars that clash with their constructors (#4301 ) This came up when watching new Lean users in a class situation. A number of them were confused when they omitted a namespace on a constructor name, and Lean treated the variable as a pattern that matches anything. For example, this program is accepted but may not do what the user thinks: ``` inductive Tree (α : Type) where \| leaf \| branch (left : Tree α) (val : α) (right : Tree α) def depth : Tree α → Nat \| leaf => 0 ``` Adding a `branch` case to `depth` results in a confusing message. With this linter, Lean marks `leaf` with: ``` Local variable 'leaf' resembles constructor 'Tree.leaf' - write '.leaf' (with a dot) or 'Tree.leaf' to use the constructor. note: this linter can be disabled with `set_option linter.constructorNameAsVariable false` ``` Additionally, the error message that occurs when invalid names are applied in patterns now suggests similar names. This means that: ``` def length (list : List α) : Nat := match list with \| nil => 0 \| cons x xs => length xs + 1 ``` now results in the following warning on `nil`: ``` warning: Local variable 'nil' resembles constructor 'List.nil' - write '.nil' (with a dot) or 'List.nil' to use the constructor. note: this linter can be disabled with `set_option linter.constructorNameAsVariable false` ``` and error on `cons`: ``` invalid pattern, constructor or constant marked with '[match_pattern]' expected Suggestion: 'List.cons' is similar ``` The list of suggested constructors is generated before the type of the pattern is known, so it's less accurate, but it truncates the list to ten elements to avoid being overwhelming. This mostly comes up with `mk`.	2024-06-14 13:03:09 +00:00
..
README.md	chore: set up procedure for preparing release notes (#4247 )	2024-05-23 02:46:11 +00:00
varCtorNameLint.md	feat: add a linter for local vars that clash with their constructors (#4301 )	2024-06-14 13:03:09 +00:00

David Thrane Christiansen 456ed44550

feat: add a linter for local vars that clash with their constructors (#4301 )

This came up when watching new Lean users in a class situation. A number
of them were confused when they omitted a namespace on a constructor
name, and Lean treated the variable as a pattern that matches anything.

For example, this program is accepted but may not do what the user
thinks:
```
inductive Tree (α : Type) where
  | leaf
  | branch (left : Tree α) (val : α) (right : Tree α)

def depth : Tree α → Nat
  | leaf => 0
```
Adding a `branch` case to `depth` results in a confusing message.

With this linter, Lean marks `leaf` with:
```
Local variable 'leaf' resembles constructor 'Tree.leaf' - write '.leaf' (with a dot) or 'Tree.leaf' to use the constructor.
note: this linter can be disabled with `set_option linter.constructorNameAsVariable false`
```

Additionally, the error message that occurs when invalid names are
applied in patterns now suggests similar names. This means that:
```
def length (list : List α) : Nat :=
  match list with
  | nil => 0
  | cons x xs => length xs + 1
```
now results in the following warning on `nil`:
```
warning: Local variable 'nil' resembles constructor 'List.nil' - write '.nil' (with a dot) or 'List.nil' to use the constructor.
note: this linter can be disabled with `set_option linter.constructorNameAsVariable false`
```

and error on `cons`:
```
invalid pattern, constructor or constant marked with '[match_pattern]' expected

Suggestion: 'List.cons' is similar
```

The list of suggested constructors is generated before the type of the
pattern is known, so it's less accurate, but it truncates the list to
ten elements to avoid being overwhelming. This mostly comes up with
`mk`.

2024-06-14 13:03:09 +00:00

README.md

chore: set up procedure for preparing release notes (#4247 )

2024-05-23 02:46:11 +00:00

varCtorNameLint.md

feat: add a linter for local vars that clash with their constructors (#4301 )

2024-06-14 13:03:09 +00:00

README.md

Draft release notes

This folder contains drafts of release notes for inclusion in RELEASES.md. During the process to create a release candidate, we look through all the commits that make up the release to prepare the release notes, and in that process we take these drafts into account.

Guidelines:

You should prefer adding release notes to commit messages over adding anything to this folder. A release note should briefly explain the impact of a change from a user's point of view. Please mark these parts out with words such as release notes and/or breaking changes.
It is not necessary to add anything to this folder. It is meant for larger features that span multiple PRs, or for anything that would be helpful when preparing the release notes that might be missed by someone reading through the change log.
If the PR that adds a feature simultaneously adds a draft release note, including the PR number is not required since it can be obtained from the git history for the file.

When release notes are prepared, all the draft release notes are deleted from this folder. For release candidates beyond the first one, you can either update RELEASE.md directly or continue to add drafts.

When a release is finalized, we will copy the completed release notes from RELEASE.md to the master branch.