Stream: t-compiler/wg-rls-2.0

Topic: rust-analyzer#720 macro_rules


detrumi (Mar 02 2019 at 15:58, on Zulip):

@matklad Did you have some specific error type in mind for error handling (failure::Error for example)? Or I could just start with something simple

matklad (Mar 02 2019 at 16:08, on Zulip):

I think failure::Error will definitely be a bad fit there

matklad (Mar 02 2019 at 16:09, on Zulip):

Starting with simple, but specific error type is a good aproach

matklad (Mar 02 2019 at 16:09, on Zulip):

that is, as long as it is some opaque struct MacroParsingError we can always enchance it :)

detrumi (Mar 02 2019 at 16:10, on Zulip):

Ah, I can't just replace option with result everywhere, because things like expand_rule are allowed to not match, if I understand correctly

matklad (Mar 02 2019 at 16:17, on Zulip):

yeah, thats the part of the problem: currently "there's an error" and "threre's a result, and it is empty" cases are conflated

detrumi (Mar 02 2019 at 16:18, on Zulip):

Right

detrumi (Mar 02 2019 at 16:18, on Zulip):

So error cases should propagate, and then panic or something to start off with, and empty cases are propagated like now

matklad (Mar 02 2019 at 16:31, on Zulip):

yeah

matklad (Mar 02 2019 at 16:31, on Zulip):

Though I think it makes sense to perhaps try a "best-effort" parse as well?

matklad (Mar 02 2019 at 16:32, on Zulip):

Say, the task is parsing macro_rules token tree into a mbe defenition

matklad (Mar 02 2019 at 16:32, on Zulip):

ideally, if there's an error in a single branch, but other branches are correct, the macro should work, if the invocation uses only correct branches

matklad (Mar 02 2019 at 16:33, on Zulip):

So, instead of returning an Result<T, E>, I can imagine returning (T, Vec<E>), where T is a best-effort parse, which ignores erroneous cases

matklad (Mar 02 2019 at 16:33, on Zulip):

but for the start Result<T, E> should be fine as well

detrumi (Mar 02 2019 at 16:34, on Zulip):

Was just checking what rustc does here, it can give errors like "no rules expected the token bar"

detrumi (Mar 02 2019 at 16:36, on Zulip):

But the functionality could be different for IDE's, so maybe checking what rustc does isn't so helpful after all

detrumi (Mar 02 2019 at 16:42, on Zulip):

Yeah, best-effort parsing actually makes a lot more sense, would be nice to do it that way without first refactoring to Results

matklad (Mar 02 2019 at 16:46, on Zulip):

on the one hand, yes, on the other hand, I think refactoring that should not be too difficult

matklad (Mar 02 2019 at 16:47, on Zulip):

Let's tart with changing MacroRules::parse to return an Result<MacroRules, MacroRulesError>?

detrumi (Mar 02 2019 at 19:38, on Zulip):

I've changed most options to results in rust-analyzer#916, though I'm not sure about the error information yet. I was also toying with the idea of storing a Result<SmolStr> in Var.kind, but dropped that idea because it was getting complicated

Edwin Cheng (Apr 03 2019 at 05:08, on Zulip):

Hi, im trying to porting mbe test from intetllij-rust. And i just found that currently our macro expansion code do not preserve white space. As i know rust-analyzer parser is lossless. But im not sure about macro expansion.

matklad (Apr 03 2019 at 05:26, on Zulip):

It would be cool to preserve white space across macro expansion, but not super usedul

Cole Lawrence (Apr 08 2019 at 18:13, on Zulip):

If you wanted to see the expansion of a macro, would we eventually then care about preserving whitespace? I'm thinking about first time macro authors where the macro may produce completely invalid code...

matklad (Apr 08 2019 at 20:22, on Zulip):

eventually maaaybe....

matklad (Apr 08 2019 at 20:22, on Zulip):

though I'd gave for just refomatting the expanded code

Last update: Nov 12 2019 at 15:30UTC