Commit Graph

8 Commits

Author SHA1 Message Date
Nilstrieb
41e8d152dc Show number in error message even for one error
Co-authored-by: Adrian <adrian.iosdev@gmail.com>
2023-11-24 19:15:52 +01:00
Matthew Jasper
e324a59eb6 Address review comments
- Add doc comment to new type
- Restore "only supported directly in conditions of `if` and `while` expressions" note
- Rename variant with clearer name
2023-09-13 15:00:31 +00:00
Matthew Jasper
b011a0a13b Reduce double errors for invalid let expressions
Previously some invalid let expressions would result in both a feature
error and a parsing error. Avoid this and ensure that we only emit the
parsing error when this happens.
2023-09-11 16:17:06 +00:00
Matthew Jasper
333388fd3c Move let expression checking to parsing
There was an incomplete version of the check in parsing and a second
version in AST validation. This meant that some, but not all, invalid
uses were allowed inside macros/disabled cfgs. It also means that later
passes have a hard time knowing when the let expression is in a valid
location, sometimes causing ICEs.

- Add a field to ExprKind::Let in AST/HIR to mark whether it's in a
  valid location.
- Suppress later errors and MIR construction for invalid let
  expressions.
2023-09-11 15:51:18 +00:00
Matthew Jasper
7b61f7f002 Don't create drop scopes after item statements
These scopes would not exist in MIR and can cause ICEs with invalid uses
of let expressions.
2023-09-11 15:51:18 +00:00
Ding Xiang Fei
d9ed11872f
lower bare boolean expression with if-construct 2023-08-30 17:24:11 +08:00
Ding Xiang Fei
e5453b4806
lower ExprKind::Use, LogicalOp::Or and UnOp::Not
Co-authored-by: Abdulaziz Ghuloum <aghuloum@gmail.com>
2023-08-30 17:24:10 +08:00
Maybe Waffle
9d3482c403 Better group RFC ui tests together 2023-06-05 16:09:46 +00:00