Sync from downstream #14980
Sync from downstream #14980
Conversation
Added byte position range for `proc_macro::Span` Currently, the [`Debug`](https://doc.rust-lang.org/beta/proc_macro/struct.Span.html#impl-Debug-for-Span) implementation for [`proc_macro::Span`](https://doc.rust-lang.org/beta/proc_macro/struct.Span.html#) calls the debug function implemented in the trait implementation of `server::Span` for the type `Rustc` in the `rustc-expand` crate. The current implementation, of the referenced function, looks something like this: ```rust fn debug(&mut self, span: Self::Span) -> String { if self.ecx.ecfg.span_debug { format!("{:?}", span) } else { format!("{:?} bytes({}..{})", span.ctxt(), span.lo().0, span.hi().0) } } ``` It returns the byte position of the [`Span`](https://doc.rust-lang.org/beta/proc_macro/struct.Span.html#) as an interpolated string. Because this is currently the only way to get a spans position in the file, I might lead someone, who is interested in this information, to parsing this interpolated string back into a range of bytes, which I think is a very non-rusty way. The proposed `position()`, method implemented in this PR, gives the ability to directly get this info. It returns a [`std::ops::Range`](https://doc.rust-lang.org/std/ops/struct.Range.html#) wrapping the lowest and highest byte of the [`Span`](https://doc.rust-lang.org/beta/proc_macro/struct.Span.html#). I put it behind the `proc_macro_span` feature flag because many of the other functions that have a similar footprint also are annotated with it, I don't actually know if this is right. It would be great if somebody could take a look at this, thank you very much in advanced.
Report allocation errors as panics OOM is now reported as a panic but with a custom payload type (`AllocErrorPanicPayload`) which holds the layout that was passed to `handle_alloc_error`. This should be review one commit at a time: - The first commit adds `AllocErrorPanicPayload` and changes allocation errors to always be reported as panics. - The second commit removes `#[alloc_error_handler]` and the `alloc_error_hook` API. ACP: rust-lang/libs-team#192 Closes #51540 Closes #51245
This reverts commit abc0660118cc95f47445fd33502a11dd448f5968.
More core::fmt::rt cleanup. - Removes the `V1` suffix from the `Argument` and `Flag` types. - Moves more of the format_args lang items into the `core::fmt::rt` module. (The only remaining lang item in `core::fmt` is `Arguments` itself, which is a public type.) Part of rust-lang/rust#99012 Follow-up to rust-lang/rust#110616
This function/lang_item was introduced in #104321 as a temporary workaround of future lowering. The usage and need for it went away in #104833. After a bootstrap update, the function itself can be removed from `std`.
rustbot
added
the
S-waiting-on-review
|
@bors r+ |
|
☀️ Test successful - checks-actions |
|
Fwiw, this brought the mir bodies back to fail @HKalbasi, i imagine thats because of the fmt argument changes which match latest nightly, but not current stable. Kind of fun how r-a actually breaks because of implementation detail changes 🙂 Are those types lang items? If yes we could maybe somehow make this emit lang items to get around that. |
|
Even before, our expansion was slightly different from that of rustc, but I didn't really understand why 😔. |
|
The previous impl was mainly done to satisfy type inference for macro expression as a whole I think |
|
That remidns me I played around with the concept of lang item paths, wonder if I still have that stash/branch |
|
Ah, I missed the ping, and saw the ping now that I come to this to see what breaks the mir. Yes, it's the I don't see how it is possible to emit lang item paths in macro expanding, but if it is possible to make it working, it is lang item (at least it was in the old version) so I guess there is no problem from this side. But there is a more general problem here, syncing builtin proc-macro implementations with the rustc, which the lang item path solution is not always available for it. An idealistic solution is to share the implementation with the installed rustc somehow, or make them simple proc-macros. A realistic approach is to conditionally expand builtin macros based on the rustc target version, or just reverting this and re applying it when it hits stable. #14846 is maybe also related. |
We would basically allow some special syntax that we'd interpret as a lang item path, something like
That's not a realistic approach, then we are back to having to maintain multiple versions of things which we don't want. The way I see it, we either need to ask upstream to make anything that's implementation detail emitted by builtin macros lang items so the names changing doesn't matter or have them be turned into proper proc-macros whose dylibs are shipped with the toolchain. |
Another problem here is that
We could drop support when it passed some time, and keep only e.g. two latest stable. But okay, let's focus on the lang paths or just drop it until it hits stable.
What I understand from rust-lang/rust#99012 is that it probably wouldn't end in naming changes only. What we can ask is to keeping the old version working for some time.
I like this, but I don't think it would work with |
It could if we allowed something like
Right, |
The |
forgot to reply to this, no news there |
|
The |
This I never understood how they do since you need to resolve the path first before knowing if its a format_args invocation, but resolution obviously happens after AST building. |
|
I think |
No description provided.