Commit graph

92 commits

Author SHA1 Message Date
Peh
1f011fa4a3 style: rename crates to kebab case 2022-05-01 10:48:58 +00:00
Jonas Schievink
872b7b9660 Wrap macros in expr position in MacroExpr node 2022-04-05 17:43:34 +02:00
Lukas Wirth
3b7b223b25 Simplify 2022-03-20 19:13:50 +01:00
Lukas Wirth
68de7b30e0 feat: Tag macro calls as unsafe if they expand to unsafe expressions 2022-03-20 19:07:44 +01:00
Matthias Krüger
451fcd3c79 fix clippy::redundant_closure 2022-03-12 16:50:49 +01:00
bors[bot]
b032993733
Merge #11629
11629: fix: Fix macro-calls expanding to items in if/while conditions r=Veykril a=Veykril

Fixes https://github.com/rust-analyzer/rust-analyzer/issues/11617

Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
2022-03-05 22:34:59 +00:00
Lukas Wirth
bb47c5f56c fix: Fix macro-calls expanding to items in if/while conditions 2022-03-05 21:58:51 +01:00
bors[bot]
8f504dc873
Merge #11598
11598: feat: Parse destructuring assignment r=Veykril a=ChayimFriedman2

Part of #11532.

Lowering is not as easy and may not even be feasible right now as it requires generating identifiers: `(a, b) = (b, a)` is desugared into
```rust
{
    let (<gensym_a>, <gensym_b>) = (b, a);
    a = <gensym_a>;
    b = <gensym_b>;
}
```

rustc uses hygiene to implement that, but we don't support hygiene yet.

However, I think parsing was the main problem as lowering will just affect type inference, and while `{unknown}` is not nice it's much better than a syntax error.

I'm still looking for the best way to do lowering, though.

Fixes #11454.

Co-authored-by: Chayim Refael Friedman <chayimfr@gmail.com>
2022-03-05 11:31:29 +00:00
bors[bot]
908c17bfa6
Merge #11595
11595: fix: lower string literals with actual value instead of default r=lnicola a=tysg

Fixes #11582. Some questions below in the code review section.

Co-authored-by: Tianyi Song <42670338+tysg@users.noreply.github.com>
2022-03-04 20:21:43 +00:00
Lukas Wirth
4a866fc672 Simplify 2022-03-04 20:23:25 +01:00
Lukas Wirth
32bf7af83e Support locals with multiple declaration sites 2022-03-04 19:49:08 +01:00
Tianyi Song
89a19f57f8 Lower string literals with real val, not default 2022-03-04 10:16:35 +08:00
Chayim Refael Friedman
d9f0731bd2 Parse destructuring assignment
The only patterns we should parse are `..` in structs and `_`: the rest are either not supported or already valid expressions.
2022-03-02 01:51:25 +00:00
Chayim Refael Friedman
6bf6f4ff1d Lower let expressions 2022-02-21 08:34:34 +02:00
Jonas Schievink
0706de94bb Report DefDiagnostics from inside item bodies 2022-01-11 14:34:25 +01:00
Lukas Wirth
ceaec9d866 internal: Replace Vec with Box in hir Pat 2021-11-20 16:17:30 +01:00
Lukas Wirth
cc327774b7 internal: Replace Vec with Box in hir Expr 2021-11-20 16:00:45 +01:00
Jonas Schievink
f8acae7895 Support let...else 2021-10-07 17:06:24 +02:00
bors[bot]
94fa49c0a3
Merge #10420
10420: Parse outer attributes on StructPatternEtCetera r=jonas-schievink a=XFFXFF

Try to fix https://github.com/rust-analyzer/rust-analyzer/issues/8610  
Related pr in ungrammer: https://github.com/rust-analyzer/ungrammar/pull/41

Co-authored-by: zhoufan <1247714429@qq.com>
2021-10-06 15:05:40 +00:00
Aramis Razzaghipour
9583dd5725
Replace if let with match where appropriate 2021-10-05 09:00:21 +11:00
zhoufan
0ee6b70b34 Parse outer attributes on StructPatternEtCetera 2021-10-02 09:57:44 +08:00
Lukas Wirth
b6ed91a6de Rename *Owner traits to Has* 2021-09-27 12:54:24 +02:00
Aleksey Kladov
2bf81922f7 internal: more reasonable grammar for blocks
Consider these expples

        { 92 }
  async { 92 }
    'a: { 92 }
   #[a] { 92 }

Previously the tree for them were

  BLOCK_EXPR
    { ... }

  EFFECT_EXPR
    async
    BLOCK_EXPR
      { ... }

  EFFECT_EXPR
    'a:
    BLOCK_EXPR
      { ... }

  BLOCK_EXPR
    #[a]
    { ... }

As you see, it gets progressively worse :) The last two items are
especially odd. The last one even violates the balanced curleys
invariant we have (#10357) The new approach is to say that the stuff in
`{}` is stmt_list, and the block is stmt_list + optional modifiers

  BLOCK_EXPR
    STMT_LIST
      { ... }

  BLOCK_EXPR
    async
    STMT_LIST
      { ... }

  BLOCK_EXPR
    'a:
    STMT_LIST
      { ... }

  BLOCK_EXPR
    #[a]
    STMT_LIST
      { ... }
2021-09-26 19:16:09 +03:00
Aleksey Kladov
56964c9bd3 feat: allow attributes on all expressions
Attrs are syntactically valid on any expression, even if they are not
allowed semantically everywhere yet.
2021-09-25 22:19:27 +03:00
Jonas Schievink
8e736da456 Recover from statement macro expansion errors 2021-09-06 00:16:12 +02:00
Aleksey Kladov
90357a9090 internal: merge hir::BinaryOp and ast::BinOp 2021-08-14 18:10:01 +03:00
Aleksey Kladov
fe4f059450 internal: prepare to merge hir::BinaryOp and ast::BinOp 2021-08-14 17:07:51 +03:00
Jonas Schievink
d568e7686a Support if let match guards 2021-08-13 00:25:14 +02:00
Clemens Wasser
47747cd412 Apply some clippy suggestions 2021-06-21 16:40:21 +02:00
Maan2003
c50b4579ec
clippy::useless_return 2021-06-13 09:35:29 +05:30
Maan2003
c9b4ac5be4
clippy::redudant_borrow 2021-06-13 09:24:16 +05:30
Aleksey Kladov
5c9f31d4c2 internal: move diagnostics to hir
The idea here is to eventually get rid of `dyn Diagnostic` and
`DiagnosticSink` infrastructure altogether, and just have a `enum
hir::Diagnostic` instead.

The problem with `dyn Diagnostic` is that it is defined in the lowest
level of the stack (hir_expand), but is used by the highest level (ide).

As a first step, we free hir_expand and hir_def from `dyn Diagnostic`
and kick the can up to `hir_ty`, as an intermediate state. The plan is
then to move DiagnosticSink similarly to the hir crate, and, as final
third step, remove its usage from the ide.

One currently unsolved problem is testing. You can notice that the test
which checks precise diagnostic ranges, unresolved_import_in_use_tree,
was moved to the ide layer. Logically, only IDE should have the infra to
render a specific range.

At the same time, the range is determined with the data produced in
hir_def and hir crates, so this layering is rather unfortunate. Working
on hir_def shouldn't require compiling `ide` for testing.
2021-05-25 17:49:59 +03:00
Jade
e666589e63 Add support for lengths in array repeats, if they are literals
Now we will get the type of `[0u8; 4]`.
2021-05-12 21:22:46 -07:00
Jade
73023c0299 Support length for ByteStrings
I am not confident that my added byte string parsing is right.
2021-05-12 21:22:46 -07:00
bors[bot]
da80dfc022
Merge #8398
8398: Fix inference with conditionally compiled tails r=flodiebold a=DJMcNab

Fixes #8378

Co-authored-by: Daniel McNab <36049421+DJMcNab@users.noreply.github.com>
2021-05-11 19:01:39 +00:00
Jonas Schievink
20ae41c1a1 Reuse database in LowerCtx 2021-05-06 23:23:50 +02:00
Jonas Schievink
976a3226fe Don't store call-site text offsets in hygiene info 2021-05-06 19:59:54 +02:00
Daniel McNab
ebbcf9f458 Fix inference with conditionally compiled tails
Fixes #8378
2021-05-03 14:13:05 +01:00
cynecx
cf3b4f1e20 hir_ty: Expand macros at type position 2021-04-17 16:24:56 +02:00
Jonas Schievink
ff858376aa Include path in unresolved-macro-call diagnostic 2021-04-16 15:48:03 +02:00
Jonas Schievink
e2c1da36f5 Support macros in pattern position 2021-04-11 01:25:50 +02:00
Jonas Schievink
a25fbdb30a Intern TypeRefs stored in Body
Minor improvement to memory usage (1 MB or so)
2021-04-06 16:07:45 +02:00
Alexandru Macovei
32304d14a1 Use Box'es to reduce the size of hir_def::expr::Pat from 112 to 64 bytes on 64bit 2021-04-06 16:01:31 +03:00
Alexandru Macovei
fb1f544e24 Use Box'es to reduce size of hir_def::expr::Expr from 128 to 72 bytes (on 64bit systems)
Rationale: only a minority of variants used almost half the size.
By keeping large members (especially in Option) behind a box
the memory cost is only payed when the large variants are needed.

This reduces the size Vec<Expr> needs to allocate.
2021-04-06 16:01:31 +03:00
Jonas Schievink
9b13e1bb91 Only remember blocks that have a DefMap 2021-04-04 03:16:26 +02:00
Edwin Cheng
8ce15b02de Fix recursive macro statement expansion 2021-03-26 04:21:15 +08:00
Jonas Schievink
cb530e7c97 Handle #[cfg] on call arguments 2021-03-17 15:10:46 +01:00
bors[bot]
6fcb5d772f
Merge #8048
8048: Fix missing unresolved macro diagnostic in function body r=edwin0cheng a=brandondong

This was an issue I found while working on https://github.com/rust-analyzer/rust-analyzer/pull/7970.

**Reproduction:**
1. Call a non-existent macro in a function body.
```
fn main() {
  foo!();
}
```
2. No diagnostics are raised. An unresolved-macro-call diagnostic is expected.
3. If the macro call is instead outside of the function body, this works as expected.

I believe this worked previously and regressed in https://github.com/rust-analyzer/rust-analyzer/pull/7805.

**Behavior prior to https://github.com/rust-analyzer/rust-analyzer/pull/7805:**
- The unresolved-macro-call diagnostic did not exist. Instead, a macro-error diagnostic would be raised with the text "could not resolve macro [path]".
- This was implemented by adding an error to the error sink (https://github.com/rust-analyzer/rust-analyzer/pull/7805/files#diff-50a326c5ae465bd9b31ee4310186380aa06e4fa1f6b41dbc0aed5bcc656a3cb8L657).
- The error was propagated through 1a82af3527/crates/hir_def/src/body.rs (L123) eventually reaching 1a82af3527/crates/hir_def/src/body/lower.rs (L569).

**Behavior after:**
- Instead of writing to the error sink, an UnresolvedMacro error is now returned (https://github.com/rust-analyzer/rust-analyzer/pull/7805/files#diff-50a326c5ae465bd9b31ee4310186380aa06e4fa1f6b41dbc0aed5bcc656a3cb8R631).
- The parent caller throws away the error as its function signature is `Option<MacroCallId>` (https://github.com/rust-analyzer/rust-analyzer/pull/7805/files#diff-50a326c5ae465bd9b31ee4310186380aa06e4fa1f6b41dbc0aed5bcc656a3cb8R604).
- We instead now reach the warn condition (1a82af3527/crates/hir_def/src/body.rs (L124)) and no diagnostics are created in 1a82af3527/crates/hir_def/src/body/lower.rs (L575).

**Fix:**
- Make sure to propagate the UnresolvedMacro error. Report the error using the new unresolved-macro-call diagnostic.


Co-authored-by: Brandon <brandondong604@hotmail.com>
2021-03-17 07:20:28 +00:00
Brandon
0103f5df8f Fix missing unresolved macro diagnostic in function body 2021-03-16 00:52:58 -07:00
Edwin Cheng
8e07b23b84 Fix macro expansion for statements w/o semicolon 2021-03-16 13:44:50 +08:00