How to best enable VS code linting?

[eee]

I am using lambda_http and lambda_runtime, and several other AWS Rust SDK libraries that are in developer preview. The compilation time is quite long for a small amount of code and so I was wondering am I doing something wrong with VS Code extensions or is it expected that certain compilation errors just won't be caught by the linting?

I am using rust-analyzer v0.3.1472. Would love to know if there's a special setup to use for more experimental features or better configuration.

One example is mismatched branches. The solution here is to return a concrete type, rather than an impl (because the generic type Response<T> must have the same T in both branches) but the IDE had no idea any error existed and the compilation error was pretty confusing too:

error[E0308]: `match` arms have incompatible types
  --> app/src/main.rs:24:20
   |
22 | /   match evt {
23 | |     "Red" => parse_width(event).await,
   | |                                  ---------------------------- this is found to be of type `Result<impl IntoResponse, Box<(dyn StdError + Send + Sync + 'static)>>`
24 | |     "Blue" => parse_length(event),
   | |                    ^^^^^^^^^^^^^^^^^^^^^^^^^ expected opaque type, found a different opaque type
25 | |     _ => Err(Error::from("Unknown color"))
26 | |   }
   | |___- `match` arms have incompatible types
...
30 |   async fn parse_width(event: Request) -> Result<impl IntoResponse, Error> {
   |                                                      ----------------- the expected opaque type
...
60 |   fn parse_length(event: Request) -> Result<impl IntoResponse, Error> {
   |                                                   ----------------- the found opaque type
   |
   = note: expected enum `Result<impl IntoResponse, _>` (opaque type at <app/src/main.rs:30:52>)
              found enum `Result<impl IntoResponse, _>` (opaque type at <app/src/main.rs:60:49>)

Another example is inferring return types, which is also resolved by removing the redundant Ok and mapping the Err correctly. Again, just surprised IDE linting couldn't discover this, and notice also nothing is red-lined about this being async with no async operations taking place:

It's taking me hours to debug this code because each build ~5 - 10 minutes so thought I must be doing something wrong!

[kpreid]

Type and match errors should be caught by rust-analyzer, but the way it does that (mostly) is by running cargo check, which will be somewhat faster than a build but still not instant. You can look at the rust-analyzer widget in the VS Code status bar to see if it is busy checking.

I would suggest focusing on fixing the very long compile time.