Proc macro tweaks #97004

nnethercote · 2022-05-13T06:46:10Z

Various improvements I spotted while looking through the proc macro code.

rust-highfive · 2022-05-13T06:46:12Z

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with r? rust-lang/libs-api @rustbot label +T-libs-api -T-libs to request review from a libs-api team reviewer. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

Stabilizing library features
Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
Changing public documentation in ways that create new stability guarantees
Changing observable runtime behavior of library APIs

nnethercote · 2022-05-13T06:46:20Z

Best reviewed one commit at a time.

library/proc_macro/src/bridge/client.rs

library/proc_macro/src/bridge/closure.rs

bjorn3 · 2022-05-13T09:02:58Z

Apart from the two comments I left everything looks fine.

eddyb

Same as @bjorn3, primary concern is Closure<'a needing its lifetime, and there's a typo in a comment.

library/proc_macro/src/bridge/server.rs

eddyb · 2022-05-13T09:12:26Z

library/proc_macro/src/bridge/buffer.rs

-pub struct Buffer<T: Copy> {
-    data: *mut T,
+pub struct Buffer {
+    data: *mut u8,


For the record, I think the reason I made this generic was to avoid accidentally doing the wrong thing because the types happened to match up (especially since there's unsafe code here) but I'll review this carefully and hopefully this is fine.

Would any type other than u8 make sense here? Doesn't seem like it, especially given that Buffer<u8> was hardcoded in a bunch of places anyway.

That's not what I meant, but rather that writing parametric code can sometimes help avoid making mistakes (which can be catastrophic in unsafe code).

It doesn't make sense at all from the perspective of whether e.g. a C++ container might be templated or not, but in does in Rust because of the type-checking in the generic form.

Anyway it doesn't matter much, I was just explaining that Foo<T> can still make sense even if it's only ever used as a single Foo<Concrete> and the generic nature "isn't taken advantage of".

Hopefully we can remove this Buffer abstraction and move more to e.g. a model closer to read/write syscalls (or io::{Read,Write} traits I suppose, at a higher level).

library/proc_macro/src/bridge/client.rs

library/proc_macro/src/bridge/closure.rs

compiler/rustc_builtin_macros/src/proc_macro_harness.rs

eddyb · 2022-05-13T09:27:55Z

library/proc_macro/src/bridge/mod.rs

-// to avoid borrow conflicts from borrows started by `&mut` arguments.
+// to match the ordering in `reverse_decode`.


I wrote a big comment I just had to remove, heh, until I figured out what was meant by this change.

So yeah it is about the borrow-checker but only directly so for reverse_decode and then reverse_encode has to play along.

I would still maybe add "(which is forced by borrowck)" or something at the end of the comment just to not make it look like the order is arbitrary.

"to match the ordering in reverse_decode" was precisely my attempt to make it clear that the order is not arbitrary. I'm happy to hear alternative wording suggestions.

library/proc_macro/src/bridge/handle.rs

nnethercote · 2022-05-16T02:18:04Z

I have addressed the comments, and added a small new commit "Rename ProcMacroDerive as DeriveProcMacro."

nnethercote · 2022-05-16T05:57:16Z

I added another commit: "Inline and remove Bridge::enter."

nnethercote · 2022-05-17T06:59:32Z

I have added a few more commits, including "Move HandleStore into server.rs" which fixes a couple of FIXME(eddyb) comments.

compiler/rustc_builtin_macros/src/proc_macro_harness.rs

eddyb

LGTM, modulo some comments, and excluding the "inline Bridge::enter" commit - having a really hard time reviewing it with the s/b/buf change thrown in, can that be its commit?

eddyb · 2022-05-18T11:24:17Z

library/proc_macro/src/bridge/server.rs

-/// Declare an associated item of one of the traits below, optionally
-/// adjusting it (i.e., adding bounds to types and default bodies to methods).
-macro_rules! associated_item {
-    (type FreeFunctions) => (type FreeFunctions: 'static;);
-    (type TokenStream) => (type TokenStream: 'static + Clone;);
-    (type TokenStreamBuilder) => (type TokenStreamBuilder: 'static;);
-    (type TokenStreamIter) => (type TokenStreamIter: 'static + Clone;);
-    (type Group) => (type Group: 'static + Clone;);
-    (type Punct) => (type Punct: 'static + Copy + Eq + Hash;);
-    (type Ident) => (type Ident: 'static + Copy + Eq + Hash;);
-    (type Literal) => (type Literal: 'static + Clone;);
-    (type SourceFile) => (type SourceFile: 'static + Clone;);
-    (type MultiSpan) => (type MultiSpan: 'static;);
-    (type Diagnostic) => (type Diagnostic: 'static;);
-    (type Span) => (type Span: 'static + Copy + Eq + Hash;);
+pub trait Types {
+    type FreeFunctions: 'static;
+    type TokenStream: 'static + Clone;
+    type TokenStreamBuilder: 'static;
+    type TokenStreamIter: 'static + Clone;
+    type Group: 'static + Clone;
+    type Punct: 'static + Copy + Eq + Hash;
+    type Ident: 'static + Copy + Eq + Hash;
+    type Literal: 'static + Clone;
+    type SourceFile: 'static + Clone;
+    type MultiSpan: 'static;
+    type Diagnostic: 'static;
+    type Span: 'static + Copy + Eq + Hash;
+}


It would really be nice if this info was in with_api! instead, it just sucks that it would have to look like : (...); instead of : ...; to be easily digestible by proc macros.

I thought about adding these bounds to with_api_types! so that this trait could be a with_api_types invocations and decided against it.

I understand the appeal of DRY and the platonic goal of encoding all of the API information in a single macro so that API changes (e.g. adding new types and/or methods) only requires modifying a single code location. But I don't think that's so important. If adding a new type and/or method requires modifying two or three places (which the compiler will point out for you) it's not that bad.

What is bad, and I have had to struggle with for a couple of days now, is how hard it is to read really macro-heavy code. I have found this bridge code hard to read. I find it hard to do macro substitution in my head. I've written out parts of the expansions of several macro invocations in a separate text file just to see what they look like. I'm contemplating putting such example expansions into comments to help future readers of the code (including me). And this was a case where macro invocation would have saved very little in terms of code length.

eddyb · 2022-05-18T11:26:59Z

library/proc_macro/src/bridge/mod.rs

+// Similar to `with_api`, but only lists the types, and they are divided into
+// the two storage categories.
+macro_rules! with_api_types {
+    ($m:ident) => {
+        $m! {
+            'owned:
+            FreeFunctions,
+            TokenStream,
+            TokenStreamBuilder,
+            TokenStreamIter,
+            Group,
+            Literal,
+            SourceFile,
+            MultiSpan,
+            Diagnostic,
+
+            'interned:
+            Punct,
+            Ident,
+            Span,
+        }
+    };
+}


This isn't great and it would be useful to have this information either in with_api! entirely or not at all there.

I think it's a clear improvement over the existing code. E.g. this macro is right next to with_api!, previously this information was in the define_handles! macro in a different file.

eddyb · 2022-05-18T11:28:18Z

library/proc_macro/src/bridge/client.rs

-        pub struct HandleCounters {
-            $($oty: AtomicUsize,)*
-            $($ity: AtomicUsize,)*
+        pub(super) struct HandleCounters {
+            $(pub(super) $oty: AtomicUsize,)*
+            $(pub(super) $ity: AtomicUsize,)*


I don't think the fields being public is acceptable. The FIXME you went for is likely tied to the fact that it's impossible to have HandleStore::new defined anywhere other than in this module.

You could maybe move everything except HandleStore::new?

Why is it not acceptable? The new division seems better: all the HandleStore stuff is in server.rs, where it belongs. HandleStore does need access to the fields of HandleCounters, but that makes sense given that HandleStore is layered on top of HandleCounters.

(Why is HandleCounters on the client side, BTW? Is it so that each proc macro gets its own separate set of counters? Would there be a problem if it was on the server side and all proc macros shared one set of counters?)

Some good news: your comment also made me realize that there was room for improvement in that last commit. I have removed the pub(super) markers on HandleStore, HandleStore's fields, HandleStore::new, MarkedTypes. I have also removed all the server:: qualifiers from the code moved into server.rs. Thanks for that!

Why is HandleCounters on the client side, BTW?

I just tried moving it into server.rs and everything worked fine. All tests pass, and it removed the need for the pub(super) markings.

Maybe there's a reason for having it in client.rs, but there's no apparent explanation in either the code or the test suite. So I've pushed the commit to this PR in case it's usable.

eddyb

Can you split these commits off into a separate PR?

Inline and remove Bridge::enter.
Move HandleStore into server.rs.
Move counters into server.rs.

(r=me on the 12 other commits at the time of this writing, ideally this will land even if I forget about it for another week)

Everything else is small and largely uncontroversial tweaks, and I think this PR has grown past its original scope, and it's hard for me to reason directly about it (e.g. there's FIXMEs I left in the code that seem to lack the precise reason I couldn't do that specific change originally).

eddyb · 2022-05-27T04:48:31Z

Why is HandleCounters on the client side, BTW?

I just tried moving it into server.rs and everything worked fine. All tests pass, and it removed the need for the pub(super) markings.

Maybe there's a reason for having it in client.rs, but there's no apparent explanation in either the code or the test suite. So I've pushed the commit to this PR in case it's usable.

Replying to this (#97004 (comment)) here so that it doesn't get lost in review comments.

Just to be clear, the code compiling and the tests passing doesn't mean much about failure modes - we generally (at most) have tests for how the proc macro API is meant to be used, and maybe some high-level errors like trying to create invalid tokens, not low-level abuse (which can be tricky to test, or at the very least require a lot of scaffolding and the test itself may become brittle), or even internal properties of the code that don't affect its behavior (not really testable).

(For example, you can't break compilation or tests by making implementation details of unsafe code pub, but it is unsound because then someone can come in, break your abstractions, and cause UB)

The reason for client-side HandleCounters is to stop servers from reusing handles the client may already have (and has snuck into TLS) - that is, we want to always error when using a handle after the invocation "session" that allocated it ended (or after it's dropped, if an owned handle), no matter what safe code does (in the proc macro the user wrote - with wasm isolation we could theoretically even guarantee this for unsafe code as well).

(Apologies for this sort of scenario not being described in code comments, it took a long time to get that code landed so it's possible near the end I didn't even remember myself in great detail every decision)

There is, however, a simplification that can be made: the server can account for never reusing handles if it's the only server that is talking to that "in-memory" instance of the proc macro dylib.

This would always be true for process/wasm isolation (where the get_handle_counters model would be annoying/inefficient to support), because the server would be in charge of "running" the client, to an extent that would guarantee unique control.

Even for the in-process dlopen'd proc macros of today this is case in practice (since the dlopener tends to have unique control), but unlike IPC or wasm FFI there's no guarantee of there being an unique "other side" (like an IPC pipe/socket/etc. or the wasm VM).

So maybe all we need is the client to remember the fn pointer in the dispatch callback (even without #97045, this should be possible with a -> ptr::NonNull<()> method on Closure), in e.g. an AtomicPtr and panic (inside the catch_unwind that will serialize an Err back to the server) if two different servers are observed by the same client.

This has the nice added benefit of removing one of the blockers for any kind of proc macro isolation that doesn't share memory between the client and the server, but I don't think it should be done in this PR (feel free to reference this comment or quote parts of it wherever such an endeavor ends up).

cc @mystor

`u8` is the only type that makes sense for `T`, as demonstrated by the fact that several impls and functions are hardwired to `Buffer<u8>`.

This gives the more obvious derive/attr/bang distinction, and reduces code size slightly.

Similar to the existing `AttrProcMacro` trait.

So it matches the existing `AttrProcMacro` and `BangProcMacro` types.

`reverse_encode` isn't necessary to please the borrow checker, it's to match the ordering done by `reverse_decode`.

There is some non-obvious information required to understand them.

nnethercote · 2022-05-27T06:14:50Z

#97445 is the follow-up.

bjorn3 · 2022-05-27T06:36:32Z

and panic (inside the catch_unwind that will serialize an Err back to the server) if two different servers are observed by the same client.

That will break running multiple rustc sessions in the same process. The proc macro will keep being loaded, but rustc will forget all state (or at least it should).

bors · 2022-05-27T08:37:33Z

☀️ Test successful - checks-actions
Approved by: eddyb
Pushing f558990 to master...

rust-timer · 2022-05-27T10:02:53Z

Finished benchmarking commit (f558990): comparison url.

Instruction count

Primary benchmarks: 😿 relevant regression found
Secondary benchmarks: 😿 relevant regressions found

	mean¹	max	count²
Regressions 😿 (primary)	0.2%	0.2%	1
Regressions 😿 (secondary)	0.6%	1.5%	10
Improvements 🎉 (primary)	N/A	N/A	0
Improvements 🎉 (secondary)	N/A	N/A	0
All 😿🎉 (primary)	0.2%	0.2%	1

Max RSS (memory usage)

Results

Primary benchmarks: no relevant changes found
Secondary benchmarks: 😿 relevant regressions found

	mean¹	max	count²
Regressions 😿 (primary)	N/A	N/A	0
Regressions 😿 (secondary)	1.7%	2.7%	3
Improvements 🎉 (primary)	N/A	N/A	0
Improvements 🎉 (secondary)	N/A	N/A	0
All 😿🎉 (primary)	N/A	N/A	0

Cycles

Results

Primary benchmarks: 😿 relevant regressions found
Secondary benchmarks: 😿 relevant regressions found

	mean¹	max	count²
Regressions 😿 (primary)	2.6%	2.7%	2
Regressions 😿 (secondary)	3.6%	5.4%	9
Improvements 🎉 (primary)	N/A	N/A	0
Improvements 🎉 (secondary)	N/A	N/A	0
All 😿🎉 (primary)	2.6%	2.7%	2

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please open an issue or create a new PR that fixes the regressions, add a comment linking to the newly created issue or PR, and then add the perf-regression-triaged label to this PR.

@rustbot label: +perf-regression

the arithmetic mean of the percent change ↩ ↩² ↩³
number of relevant changes ↩ ↩² ↩³

nnethercote · 2022-05-27T11:51:18Z

Surprising perf regressions. I'll take a look on Monday.

eddyb · 2022-05-27T17:09:44Z

and panic (inside the catch_unwind that will serialize an Err back to the server) if two different servers are observed by the same client.

That will break running multiple rustc sessions in the same process. The proc macro will keep being loaded, but rustc will forget all state (or at least it should).

@bjorn3 Just as the proc macro will remain loaded, so will librustc_driver.so and in that process it would always have the same address for the callback function pointer in the Bridge - worst case, we can also send the address of a server-side static tied to proc_macro::bridge::server, so that it wouldn't even change if rustc is monomorphizing proc_macro::bridge::server functionality multiple times (we also should have some basic "version" negotiation to limit accidents but I'm not sure how to compute one short of adding a build.rs to library/proc_macro that hashes all files in its src...).

proc_macro: don't pass a client-side function pointer through the server. Before this PR, `proc_macro::bridge::Client<F>` contained both: * the C ABI entry-point `run`, that the server can call to start the client * some "payload" `f: F` passed to that entry-point * in practice, this was always a (client-side Rust ABI) `fn` pointer to the actual function the proc macro author wrote, i.e. `#[proc_macro] fn foo(input: TokenStream) -> TokenStream` In other words, the client was passing one of its (Rust) `fn` pointers to the server, which was passing it back to the client, for the client to call (see later below for why that was ever needed). I was inspired by `@nnethercote's` attempt to remove the `get_handle_counters` field from `Client` (see rust-lang#97004 (comment)), which combined with removing the `f` ("payload") field, could theoretically allow for a `#[repr(transparent)]` `Client` that mostly just newtypes the C ABI entry-point `fn` pointer <sub>(and in the context of e.g. wasm isolation, that's *all* you want, since you can reason about it from outside the wasm VM, as just a 32-bit "function table index", that you can pass to the wasm VM to call that function)</sub>. <hr/> So this PR removes that "payload". But it's not a simple refactor: the reason the field existed in the first place is because monomorphizing over a function type doesn't let you call the function without having a value of that type, because function types don't implement anything like `Default`, i.e.: ```rust extern "C" fn ffi_wrapper<A, R, F: Fn(A) -> R>(arg: A) -> R { let f: F = ???; // no way to get a value of `F` f(arg) } ``` That could be solved with something like this, if it was allowed: ```rust extern "C" fn ffi_wrapper< A, R, F: Fn(A) -> R, const f: F // not allowed because the type is a generic param >(arg: A) -> R { f(arg) } ``` Instead, this PR contains a workaround in `proc_macro::bridge::selfless_reify` (see its module-level comment for more details) that can provide something similar to the `ffi_wrapper` example above, but limited to `F` being `Copy` and ZST (and requiring an `F` value to prove the caller actually can create values of `F` and it's not uninhabited or some other unsound situation). <hr/> Hopefully this time we don't have a performance regression, and this has a chance to land. cc `@mystor` `@bjorn3`

nnethercote · 2022-05-29T23:44:49Z

Local measurements indicate that Make Buffer non-generic. is responsible for the perf regression, that's annoying.

It was made non-generic in rust-lang#97004, but that (surprisingly) caused a mild performance regression.

nnethercote · 2022-05-30T01:01:29Z

#97539 is the follow-up for the perf regression.

pnkfelix · 2022-05-31T19:57:24Z

visiting for weekly performance triage. I won't mark this as triaged quite yet, since PR #97539 has not yet landed, but it certainly sounds like it is under control. Thanks @nnethercote !

This fixes a performance regression caused by making `Buffer` non-generic in rust-lang#97004.

…ods, r=eddyb Inline `bridge::Buffer` methods. This fixes a performance regression caused by making `Buffer` non-generic in rust-lang#97004. r? `@eddyb`

nnethercote · 2022-08-03T15:46:11Z

The perf regression ended up being fixed in #97604.

@rustbot label: +perf-regression-triaged

proc_macro: don't pass a client-side function pointer through the server. Before this PR, `proc_macro::bridge::Client<F>` contained both: * the C ABI entry-point `run`, that the server can call to start the client * some "payload" `f: F` passed to that entry-point * in practice, this was always a (client-side Rust ABI) `fn` pointer to the actual function the proc macro author wrote, i.e. `#[proc_macro] fn foo(input: TokenStream) -> TokenStream` In other words, the client was passing one of its (Rust) `fn` pointers to the server, which was passing it back to the client, for the client to call (see later below for why that was ever needed). I was inspired by `@nnethercote's` attempt to remove the `get_handle_counters` field from `Client` (see rust-lang/rust#97004 (comment)), which combined with removing the `f` ("payload") field, could theoretically allow for a `#[repr(transparent)]` `Client` that mostly just newtypes the C ABI entry-point `fn` pointer <sub>(and in the context of e.g. wasm isolation, that's *all* you want, since you can reason about it from outside the wasm VM, as just a 32-bit "function table index", that you can pass to the wasm VM to call that function)</sub>. <hr/> So this PR removes that "payload". But it's not a simple refactor: the reason the field existed in the first place is because monomorphizing over a function type doesn't let you call the function without having a value of that type, because function types don't implement anything like `Default`, i.e.: ```rust extern "C" fn ffi_wrapper<A, R, F: Fn(A) -> R>(arg: A) -> R { let f: F = ???; // no way to get a value of `F` f(arg) } ``` That could be solved with something like this, if it was allowed: ```rust extern "C" fn ffi_wrapper< A, R, F: Fn(A) -> R, const f: F // not allowed because the type is a generic param >(arg: A) -> R { f(arg) } ``` Instead, this PR contains a workaround in `proc_macro::bridge::selfless_reify` (see its module-level comment for more details) that can provide something similar to the `ffi_wrapper` example above, but limited to `F` being `Copy` and ZST (and requiring an `F` value to prove the caller actually can create values of `F` and it's not uninhabited or some other unsound situation). <hr/> Hopefully this time we don't have a performance regression, and this has a chance to land. cc `@mystor` `@bjorn3`

rust-highfive assigned eddyb May 13, 2022

rustbot added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label May 13, 2022

rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label May 13, 2022

bjorn3 reviewed May 13, 2022

View reviewed changes

library/proc_macro/src/bridge/client.rs Outdated Show resolved Hide resolved

bjorn3 reviewed May 13, 2022

View reviewed changes

library/proc_macro/src/bridge/closure.rs Outdated Show resolved Hide resolved

eddyb suggested changes May 13, 2022

View reviewed changes

nnethercote force-pushed the proc-macro-tweaks branch 3 times, most recently from 6166758 to 4e7fe1a Compare May 16, 2022 02:17

nnethercote force-pushed the proc-macro-tweaks branch from fe001db to e718c47 Compare May 17, 2022 06:58

jyn514 reviewed May 17, 2022

View reviewed changes

compiler/rustc_builtin_macros/src/proc_macro_harness.rs Show resolved Hide resolved

eddyb suggested changes May 18, 2022

View reviewed changes

nnethercote force-pushed the proc-macro-tweaks branch from e718c47 to cf47a51 Compare May 18, 2022 23:56

eddyb suggested changes May 27, 2022

View reviewed changes

nnethercote added 9 commits May 27, 2022 15:58

Fix a typo in a comment.

2469ed0

Add some comments.

a61a85e

Improve formatting in associated_item! definition.

e02789c

Make Buffer<T> non-generic.

2ece157

`u8` is the only type that makes sense for `T`, as demonstrated by the fact that several impls and functions are hardwired to `Buffer<u8>`.

Simplify types in proc_macro_harness.rs.

1a9514d

This gives the more obvious derive/attr/bang distinction, and reduces code size slightly.

Rename ProcMacro trait as BangProcMacro.

dbdc7dd

Similar to the existing `AttrProcMacro` trait.

Rename ProcMacroDerive as DeriveProcMacro.

bc70d0d

So it matches the existing `AttrProcMacro` and `BangProcMacro` types.

Clarify a comment.

9a785e0

`reverse_encode` isn't necessary to please the borrow checker, it's to match the ordering done by `reverse_decode`.

Add some comments about _marker fields.

c2c5057

There is some non-obvious information required to understand them.

bors added the merged-by-bors This PR was explicitly merged by bors. label May 27, 2022

bors merged commit f558990 into rust-lang:master May 27, 2022

rustbot added this to the 1.63.0 milestone May 27, 2022

nnethercote deleted the proc-macro-tweaks branch May 27, 2022 09:37

rustbot added the perf-regression Performance regression. label May 27, 2022

eddyb mentioned this pull request May 27, 2022

proc_macro: don't pass a client-side function pointer through the server. #97461

Merged

nnethercote added a commit to nnethercote/rust that referenced this pull request May 29, 2022

Make bridge::Buffer generic again.

b41ece9

It was made non-generic in rust-lang#97004, but that (surprisingly) caused a mild performance regression.

nnethercote mentioned this pull request May 30, 2022

Make bridge::Buffer generic again. #97539

Closed

nnethercote added a commit to nnethercote/rust that referenced this pull request May 31, 2022

Inline bridge::Buffer methods.

dee353d

This fixes a performance regression caused by making `Buffer` non-generic in rust-lang#97004.

nnethercote mentioned this pull request May 31, 2022

Inline bridge::Buffer methods. #97604

Merged

eddyb mentioned this pull request Jun 18, 2022

proc_macro/bridge: remove client->server &HandleCounters passing. #98223

Closed

JohnTitor mentioned this pull request Jul 26, 2022

Fix some links rust-lang/rustc-dev-guide#1411

Merged

rustbot added the perf-regression-triaged The performance regression has been triaged. label Aug 3, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Proc macro tweaks #97004

Proc macro tweaks #97004

nnethercote commented May 13, 2022

rust-highfive commented May 13, 2022

nnethercote commented May 13, 2022

bjorn3 commented May 13, 2022

eddyb left a comment

eddyb May 13, 2022

nnethercote May 13, 2022

eddyb May 18, 2022

eddyb May 13, 2022

nnethercote May 13, 2022

nnethercote commented May 16, 2022

nnethercote commented May 16, 2022

nnethercote commented May 17, 2022

eddyb left a comment

eddyb May 18, 2022

nnethercote May 18, 2022 •

edited

Loading

eddyb May 18, 2022

nnethercote May 18, 2022

eddyb May 18, 2022

nnethercote May 19, 2022

nnethercote May 19, 2022

eddyb left a comment

eddyb commented May 27, 2022

nnethercote commented May 27, 2022

bjorn3 commented May 27, 2022

bors commented May 27, 2022

rust-timer commented May 27, 2022

nnethercote commented May 27, 2022

eddyb commented May 27, 2022

nnethercote commented May 29, 2022

nnethercote commented May 30, 2022

pnkfelix commented May 31, 2022

nnethercote commented Aug 3, 2022

		// to avoid borrow conflicts from borrows started by `&mut` arguments.
		// to match the ordering in `reverse_decode`.

Proc macro tweaks #97004

Proc macro tweaks #97004

Conversation

nnethercote commented May 13, 2022

rust-highfive commented May 13, 2022

nnethercote commented May 13, 2022

bjorn3 commented May 13, 2022

eddyb left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nnethercote commented May 16, 2022

nnethercote commented May 16, 2022

nnethercote commented May 17, 2022

eddyb left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nnethercote May 18, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

eddyb left a comment

Choose a reason for hiding this comment

eddyb commented May 27, 2022

nnethercote commented May 27, 2022

bjorn3 commented May 27, 2022

bors commented May 27, 2022

rust-timer commented May 27, 2022

Footnotes

nnethercote commented May 27, 2022

eddyb commented May 27, 2022

nnethercote commented May 29, 2022

nnethercote commented May 30, 2022

pnkfelix commented May 31, 2022

nnethercote commented Aug 3, 2022

nnethercote May 18, 2022 •

edited

Loading