ymandel added a comment.

In D64518#1589768 <https://reviews.llvm.org/D64518#1589768>, @ilya-biryukov 
wrote:

> In D64518#1588092 <https://reviews.llvm.org/D64518#1588092>, @ymandel wrote:
>
> > This seems like a good candidate for configuration -- the user could then 
> > choose which mode to run in.  But, I'm also open to just reporting these 
> > conditions as errors.  It's already in a context that returns Expected, so 
> > its no trouble; it's just a matter of choosing what we think is "correct".
>
>
> WRT to returning `Expected` vs `Optional`. Either seems fine and in the 
> spirit of the library, depending on whether we want to produce more detailed 
> errors. However, if we choose `Optional` let's stick to it, as practice shows 
> switching from `Optional` to `Expected` correctly is almost impossible, as 
> that requires a lot of attention to make sure all clients consume the errors 
> (and given that it's an error case, tests often don't catch unconsumed 
> errors).
>  I would personally go with `Optional` here (meaning the client code would 
> have to say something generic like `could not map from macro expansion to 
> source code`). But up to you, not a strong preference.


I think we might be talking about different things here. I meant that the 
*calling* function, `translateEdits`, returns `Expected`, so it would be easy 
to return an error when `makeValidRange` returns `None`.  I agree that 
`makeValidRange` (or whatever we choose to call it) should stick with 
`Optional` for simplicity (with the generic interpretation of `None` being 
"could not map from macro expansion to source code").

> WRT to which cases we choose to handle, I'd start with a minimal number of 
> supported examples (covering full macro expansion, or inside a single 
> argument) and gradually add other cases as we find use-cases. What are your 
> thoughts on that?

I assume you mean which cases `makeValidRange` should handle (successfully)? If 
so, that sounds good.  But, what do you think about how to handle failures of 
`makeValidRange` -- ignore them silently (which is what we're doing now) or 
treat them as errors?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64518/new/

https://reviews.llvm.org/D64518



_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to