Aaron Hill

Note that `Span::parent` allows you to write 'completely unhygenic' macros, which can see identifiers in a way that would otherwise be impossible: ```rust // src/lib.rs #![feature(proc_macro_span)] use proc_macro::TokenStream; #[proc_macro] pub...

We might want to gate 'read-only' APIs (e.g. `Span::source_text`, `Span::start`) under a separate feature, since they could be stabilized without increasing the power of proc macros w.r.t hygiene.

> I'm specifically interested in Span::join that would allow for painless proc-macro error messages on stable Before `Span::join` is stabilized, we should decide how it should handle hygiene. If I...

> How do we handle truely-unsized DSTs when we get them? @aturon: Are you referring to `extern type`?

If we decide to make disabled functions return an error code, I think we should have a command-line flag to opt in to the old behavior. There should be a...

The glibc documentation mentions this kind of issue, and how the implementation (supposedly) avoids it: https://sourceware.org/glibc/wiki/Destructor%20support%20for%20thread_local%20variables I suspect that this may be a problem with the particular shared library being...

I've created a standalone C reproducer, using `pthread_key_create`: https://github.com/Aaron1011/pthread_dlopen It does the following: 1. Spawn a new thread from `main()`, and block on it using `pthread_join` 2. From the new...

There's already a glibc bug report for this: https://sourceware.org/bugzilla/show_bug.cgi?id=21032 Unfortunately, it's been open since 2017 without any feedback.

While this not a bug in `libloading`, I think it's a major footgun for anyone using this library. As https://github.com/Aaron1011/pthread_dlopen demonstrates, it's not possible to determine ahead of time if...

> Not unloading the libraries will break a fairly common use-case of hot reloading I may be wrong, but I would think that hot reloading would be less common than...