Stepan Tubanov

> Is this change motivated by some kind of "real" example? I think it would be reasonable that users might still want to be warned when macro-generated code uses a...

When you call `connect` it creates just 1 connection. When you begin a transaction - that acquires one connection from the pool it's not returned to the pool until transaction...

Can also be useful to keep track of additional data per connection: `HashMap`

@xFrednet > > May be we could add an attribute `allow_in_external_macros` (alongside path and reason attributes) for each type and apply based on that? > > I'd suggest adding a...

@rustbot ready

> Another option would be to have a list of macros, that can use disallowed types. This could probably be useful in general, for other lints as well, so it'd...

> With this, I assume you mean it seems good to you, to take the current implementation? Personally I would prefer a simple `true`/`false` option. If necessary it can later...

@xFrednet I started looking into it, but I'm not sure how to implement it. Is there an example of this logic somewhere in other lints? Specifically filtering based on which...

Until this is fixed as a workaround you can do this: ```rust // `conn` implements `sqlx::Executor` conn.execute(sqlx::raw_sql("...")).await.unwrap(); ```

> That's expected behavior. The global::shutdown_tracer_provider() should only decrement the reference it is holding. There shouldn't be any flush/shutdown mechanism exposed at API/global level as per the specs. It's kind...