Change:
The error message for the following has changed so that that JSON spans include file names into the standard library: With JSON output, previously this had a span that looked like this: Pay attention to the "filename" field, it now includes a span that references instead of . There are other differences, such as missing rendering. The new output is: This is a problem because the path doesn't exist, so there is nothing to point to. Additionally, tools may be expecting the previous behavior of a value in the "filename". Note that this seems particular to using a const expression in the example above (a literal such as doesn't have the same effect). This seems to have started with (cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
pre-triage: prioritized as given that this is unlikely to break important stuff badly. should we assign to you?.
Let's not assign it to me, but let's cc and :)
This is , maybe we should prioritize it? I hope not, it was always a hack that we've been wanting to get rid for years () and even used to be even more useless (e.g. i.e. crate name, that's why it was with an ). We shouldn't treat this as a regression unless we have some evidence of misuse in the wild.
path doesn't exist Hmm, I'm pretty sure that I've seen paths like this before , but probably in debuginfo rather than in spans. It still seems to be better than no paths at all because some tools have an option to remap paths like this to a different directory with actual sources, or can be symlinked to the actual source directory in the worst case.
Just a quick perusal of projects: Sublime: RLS: Rust-analyzer: I imagine there are others. I wouldn't call it "misuse". It is how stable rustc behaves, and tools have to deal with it. The immediate issue for me, is that I need to find the invocation site. It was previously easy to skip over the entries. Now, I guess I'll need to check if paths exist? I'm not sure, I haven't thought about it too much. Nor do I understand under which scenarios this happens. If someone could explain in clear terms what the change is, that would be helpful. I can probably update the documentation if this really is a permanent change. It was also useful for emitting the message "this error originates in a macro outside of the current crate", but now I don't see a way to detect that? Regardless, this is a breaking change. I'm not so sensitive about them, I can adapt, but it will likely have some impact on other projects, too.
hmm I wonder if we should bump the priority to then. Thoughts?.
(I want to push back on the notion of "breaking change" here, as it is typically associated with "you broke some stability guarantees", which isn't the case here AFAIK, and it would be pretty dangerous if we would have given such guarantees. That said, it would be nice to make more robust improvements here, but I agree with re. "better than nothing".) For now I think P-medium is appropriate.
Isn't that what the macro backtrace is for? is in the macro, while is the invocation, if I'm reading the JSON correctly. The change is that the hack has been completely removed and now s pointing to the definition of a macro are identical in the same-crate and cross-crate cases. This should work great for anything built locally by Cargo, where the source is available anyway. No tools should've relied on to detect macros, but rather the actual macro backtrace, which would've worked same-crate before the change. The only non-misuse of detection is to ignore it as a non-real file. Paths starting with e.g. is an orthogonal problem, further exposed by this change, hence my suggestion that we should prioritize fixing that. "crate" is likely the wrong granularity here, if you have the ability you should probably do this for "outside of the current workspace" instead. The compiler itself can't, and relies on a flag (that's not exposed in the JSON) which indicates that the file wasn't loaded by this crate but by a dependency.
assign I'm not quite sure how this is going to be resolved (it may be that the tools are working as expected, or at least within the bounds of what users can expect), but I'm letting eddy take charge of resolution one way or another.
I think the resolution here is that I'll wait for to land, and then I'll send a PR to update the documentation. I think at a minimum this should be included in the release notes. It would be nice to try to communicate this to tool developers, but I don't know if there is a single way to do that, maybe an internals post?

Discussion:
"spans": [ { /* The file where the span is located. <del> For spans located within a macro expansion, this will be the name of the expanded macro in the format "<MACRONAME macros>". </del> <ins> Note that this path may not exist. For example, if the path points to the standard library, and the rust src is not available in the sysroot, then it may point to a non-existent file. Beware that this may also point to the source of an external crate. </ins> */ "file_name": "lib.rs", /* The byte offset where the span starts (0-based, inclusive). */