| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
5142: analysis-stats: allow parallel type inference r=matklad a=jonas-schievink
This is mostly just for testing/fun, but it looks like type inference can be sped up massively with little to no effort (since it runs after the serial phases are already done).
Without `--parallel`:
```
Item Collection: 16.43597698s, 683mb allocated 720mb resident
Inference: 25.429774879s, 1720mb allocated 1781mb resident
Total: 41.865866352s, 1720mb allocated 1781mb resident
```
With `--parallel`:
```
Item Collection: 16.380369815s, 683mb allocated 735mb resident
Parallel Inference: 7.449166445s, 1721mb allocated 1812mb resident
Inference: 143.437157ms, 1721mb allocated 1812mb resident
Total: 23.973303611s, 1721mb allocated 1812mb resident
```
Co-authored-by: Jonas Schievink <[email protected]>
|
| | |
|
|/ |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
5101: Add expect -- a light-weight alternative to insta r=matklad a=matklad
This PR implements a small snapshot-testing library. Snapshot updating is done by setting an env var, or by using editor feature (which runs a test with env-var set).
Here's workflow for updating a failing test:
![expect](https://user-images.githubusercontent.com/1711539/85926956-28afa080-b8a3-11ea-9260-c6d0d8914d0b.gif)
Here's workflow for adding a new test:
![expect-fresh](https://user-images.githubusercontent.com/1711539/85926961-306f4500-b8a3-11ea-9369-f2373e327a3f.gif)
Note that colorized diffs are not implemented in this PR, but should be easy to add (we already use them in test_utils).
Main differences from insta (which is essential for rust-analyzer development, thanks @mitsuhiko!):
* self-updating tests, no need for a separate tool
* fewer features (only inline snapshots, no redactions)
* fewer deps (no yaml, no persistence)
* tighter integration with editor
* first-class snapshot object, which can be used to write test functions (as opposed to testing macros)
* trivial to tweak for rust-analyzer needs, by virtue of being a workspace member.
I think eventually we should converge to a single snapshot testing library, but I am not sure that `expect` is exactly right, so I suggest rolling with both insta and expect for some time (if folks agree that expect might be better in the first place!).
# Editor Integration Implementation
The thing I am most excited about is the ability to update a specific snapshot from the editor. I want this to be available to other snapshot-testing libraries (cc @mitsuhiko, @aaronabramov), so I want to document how this works.
The ideal UI here would be a code action (:bulb:). Unfortunately, it seems like it is impossible to implement without some kind of persistence (if you save test failures into some kind of a database, like insta does, than you can read the database from the editor plugin). Note that it is possible to highlight error by outputing error message in rustc's format. Unfortunately, one can't use the same trick to implement a quick fix.
For this reason, expect makes use of another rust-analyzer feature -- ability to run a single test at the cursor position. This does need some expect-specific code in rust-analyzer unfortunately. Specifically, if rust-analyzer notices that the cursor is on `expect!` macro, it adds a special flag to runnable's JSON. However, given #5017 it is possible to approximate this well-enough without rust-analyzer integration. Specifically, an extension can register a special runner which checks (using regexes) if rust-anlyzer runnable covers text with specific macro invocation and do special magic in that case.
closes #3835
Co-authored-by: Aleksey Kladov <[email protected]>
|
| | |
|
| | |
|
| | |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
5120: Add a simple SSR subcommand to the rust-analyzer command line binary r=davidlattimore a=davidlattimore
Is adding the dependency on ra_ide_db OK? It's needed for the call to `db.local_roots()`
Co-authored-by: David Lattimore <[email protected]>
|
| | | |
|
|/ / |
|
| | |
|
| | |
|
| | |
|
|\ \
| |/
|/|
| |
| |
| |
| |
| | |
5090: Bump deps r=matklad a=lnicola
Co-authored-by: Laurențiu Nicola <[email protected]>
|
| | |
|
| | |
|
|\ \
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
4982: Bump chalk r=matklad a=lnicola
This passes the tests, but fails in a weird way on `analysis-stats`:
```
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', /home/me/.cargo/registry/src/github.com-1ecc6299db9ec823/chalk-solve-0.14.0/src/clauses/builtin_traits/fn_family.rs:96:20
stack backtrace:
0: backtrace::backtrace::libunwind::trace
at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.46/src/backtrace/libunwind.rs:86
1: backtrace::backtrace::trace_unsynchronized
at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.46/src/backtrace/mod.rs:66
2: std::sys_common::backtrace::_print_fmt
at src/libstd/sys_common/backtrace.rs:78
3: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
at src/libstd/sys_common/backtrace.rs:59
4: core::fmt::write
at src/libcore/fmt/mod.rs:1076
5: std::io::Write::write_fmt
at src/libstd/io/mod.rs:1537
6: std::sys_common::backtrace::_print
at src/libstd/sys_common/backtrace.rs:62
7: std::sys_common::backtrace::print
at src/libstd/sys_common/backtrace.rs:49
8: std::panicking::default_hook::{{closure}}
at src/libstd/panicking.rs:198
9: std::panicking::default_hook
at src/libstd/panicking.rs:218
10: std::panicking::rust_panic_with_hook
at src/libstd/panicking.rs:477
11: rust_begin_unwind
at src/libstd/panicking.rs:385
12: core::panicking::panic_fmt
at src/libcore/panicking.rs:86
13: core::panicking::panic
at src/libcore/panicking.rs:51
14: chalk_solve::clauses::builtin_traits::fn_family::add_fn_trait_program_clauses
15: chalk_solve::clauses::builder::ClauseBuilder<I>::push_binders
16: chalk_solve::clauses::program_clauses_that_could_match
17: chalk_solve::clauses::program_clauses_for_goal
18: chalk_solve::recursive::Solver<I>::solve_new_subgoal
19: <chalk_solve::recursive::Solver<I> as chalk_solve::recursive::solve::SolveDatabase<I>>::solve_goal
20: chalk_solve::recursive::Solver<I>::solve_root_goal
21: chalk_solve::solve::Solver<I>::solve_limited
22: ra_hir_ty::traits::trait_solve_query
23: salsa::runtime::Runtime<DB>::execute_query_implementation
24: salsa::derived::slot::Slot<DB,Q,MP>::read_upgrade
25: salsa::derived::slot::Slot<DB,Q,MP>::read
26: <salsa::derived::DerivedStorage<DB,Q,MP> as salsa::plumbing::QueryStorageOps<DB,Q>>::try_fetch
27: salsa::QueryTable<DB,Q>::get
28: <T as ra_hir_ty::db::HirDatabase>::trait_solve
29: ra_hir_ty::infer::InferenceContext::resolve_ty_as_possible
30: ra_hir_ty::infer::expr::<impl ra_hir_ty::infer::InferenceContext>::infer_expr_inner
31: ra_hir_ty::infer::expr::<impl ra_hir_ty::infer::InferenceContext>::infer_expr_coerce
32: ra_hir_ty::infer::expr::<impl ra_hir_ty::infer::InferenceContext>::check_call_arguments
33: ra_hir_ty::infer::expr::<impl ra_hir_ty::infer::InferenceContext>::infer_method_call
34: ra_hir_ty::infer::expr::<impl ra_hir_ty::infer::InferenceContext>::infer_expr_inner
35: ra_hir_ty::infer::expr::<impl ra_hir_ty::infer::InferenceContext>::infer_expr
36: ra_hir_ty::infer::expr::<impl ra_hir_ty::infer::InferenceContext>::infer_method_call
37: ra_hir_ty::infer::expr::<impl ra_hir_ty::infer::InferenceContext>::infer_expr_inner
38: ra_hir_ty::infer::expr::<impl ra_hir_ty::infer::InferenceContext>::infer_expr_coerce
39: ra_hir_ty::infer::expr::<impl ra_hir_ty::infer::InferenceContext>::infer_expr_inner
40: ra_hir_ty::infer::expr::<impl ra_hir_ty::infer::InferenceContext>::infer_expr_inner
41: ra_hir_ty::infer::expr::<impl ra_hir_ty::infer::InferenceContext>::infer_expr_coerce
42: ra_hir_ty::infer::expr::<impl ra_hir_ty::infer::InferenceContext>::infer_expr_inner
43: ra_hir_ty::infer::expr::<impl ra_hir_ty::infer::InferenceContext>::infer_expr_coerce
44: ra_hir_ty::infer::infer_query
45: salsa::runtime::Runtime<DB>::execute_query_implementation
46: salsa::derived::slot::Slot<DB,Q,MP>::read_upgrade
47: salsa::derived::slot::Slot<DB,Q,MP>::read
48: <salsa::derived::DerivedStorage<DB,Q,MP> as salsa::plumbing::QueryStorageOps<DB,Q>>::try_fetch
49: ra_hir_ty::db::infer_wait
50: rust_analyzer::cli::analysis_stats::analysis_stats
51: rust_analyzer::main
52: std::rt::lang_start::{{closure}}
53: std::rt::lang_start_internal::{{closure}}
at src/libstd/rt.rs:52
54: std::panicking::try::do_call
at src/libstd/panicking.rs:297
55: std::panicking::try
at src/libstd/panicking.rs:274
56: std::panic::catch_unwind
at src/libstd/panic.rs:394
57: std::rt::lang_start_internal
at src/libstd/rt.rs:51
58: main
59: __libc_start_main
60: _start
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
```
It's as if we're returning `None` for a well-known trait that `chalk` asks about. That seems to happen for `Deref`, `CoerceUnsized` and `Try`.
r? @flodiebold
Co-authored-by: Laurențiu Nicola <[email protected]>
|
| | |
|
|/ |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Part of #3186
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
It's a good idea to distinguish between absolute and relative paths at
the type level, to avoid accidental dependency on the cwd, which
really shouldn't matter for rust-analyzer service
|
| |
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
4843: Don't guess macro expansion crate r=matklad a=matklad
bors r+
🤖
Co-authored-by: Aleksey Kladov <[email protected]>
|
| | |
|
| |
| |
| |
| |
| | |
It iterates in insertion order, which makes the ordering more
predictable.
|
|/ |
|
| |
|
| |
|
|
|
|
| |
https://github.com/rust-analyzer/rust-analyzer/issues/4224#issuecomment-639328191
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
4678: Unsquish parameter types in tooltips for macro-generated functions r=aloucks a=aloucks
Note the missing whitespace between `:` and the parameter type.
Before:
![image](https://user-images.githubusercontent.com/221559/83364680-faf13d80-a370-11ea-96b7-a041969a4954.png)
After:
![image](https://user-images.githubusercontent.com/221559/83364685-03e20f00-a371-11ea-9668-4e6ebcb81947.png)
Co-authored-by: Aaron Loucks <[email protected]>
|
| | |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
4580: Fix invoking cargo without consulting CARGO env var or standard installation paths r=matklad a=Veetaha
Followup for #4329
The pr essentially fixes [this bug](https://youtu.be/EzQ7YIIo1rY?t=2189)
cc @lefticus
Co-authored-by: veetaha <[email protected]>
|
| | |
| | |
| | |
| | |
| | |
| | | |
As per matklad, we now pass the responsibility for finding the binary to the frontend.
Also, added caching for finding the binary path to reduce
the amount of filesystem interactions.
|
| | | |
|
| |/ |
|