Stream: t-compiler/major changes

Topic: Filter out query machinery from compiler … compiler-team#410


triagebot (Mar 04 2021 at 10:43, on Zulip):

A new proposal has been announced: Filter out query machinery from compiler backtraces by default #410. It will be announced at the next meeting to try and draw attention to it, but usually MCPs are not discussed during triage meetings. If you think this would benefit from discussion amongst the team, consider proposing a design meeting.

RalfJ (Mar 04 2021 at 11:05, on Zulip):

oO that proposd implementation sounds a lot like a built-in hacky version of https://github.com/dtolnay/linkme, or am I misunderstanding? Cc @oli

oli (Mar 04 2021 at 11:10, on Zulip):

it's pretty much exactly that, except imo it's less hacky than the linkme crate, as it does not rely on linker functionality. It's the MVP needed for https://github.com/rust-lang/const-eval/issues/25#issuecomment-533840428 (which itself is desirable for custom test harnesses, tracing metadata and custom const-evaluated artifacts).

simulacrum (Mar 04 2021 at 12:33, on Zulip):

I'm a bit surprised by the lexical order claim - is this performance sensitive for some reason? Seems fine, just interested if my assumption is wrong that it shouldn't really be called often

oli (Mar 04 2021 at 12:34, on Zulip):

the list may get very big, I don't know. And we would have to walk it for every frame in the backtrace. But even so, I don't like having constants whose value depends on arbitrary decisions by the compiler

simulacrum (Mar 04 2021 at 12:36, on Zulip):

Sure, was just wondering.

oli (Mar 04 2021 at 13:04, on Zulip):

I was just doing premature optimizations. It would indeed be easier to just append them and not do any sorting, so we may just start out like this until we have a significant number of things marked

oli (Mar 04 2021 at 13:04, on Zulip):

I'll adjust the MCP accordingly

simulacrum (Mar 04 2021 at 13:37, on Zulip):

@oli I think the reproducible builds argument is worthwhile, FWIW

simulacrum (Mar 04 2021 at 13:39, on Zulip):

I also want to note that symbol names might not be the best thing - those aren't necessarily available at runtime and are relatively expensive to resolve, maybe we can just store the ip addresses? (i.e. function pointers without the type signature basically)

oli (Mar 04 2021 at 14:03, on Zulip):

hmm... I think I know how to implement that, but it may not actually work in practice if a function is duplicated, as it has multiple addresses then

oli (Mar 04 2021 at 14:03, on Zulip):

we can start with that and see how it goes

simulacrum (Mar 04 2021 at 14:05, on Zulip):

Hm, yes

simulacrum (Mar 04 2021 at 14:05, on Zulip):

But surely the symbol name is then also not going to work? Unless it's the post demangling symbol... Maybe?

oli (Mar 04 2021 at 14:08, on Zulip):

idk, I like the pointer idea and will start with that and see how it fares

simulacrum (Mar 04 2021 at 15:04, on Zulip):

@oli anyway happy to second, not sure if you wanted Felix to take a look specifically

simulacrum (Mar 04 2021 at 15:04, on Zulip):

I can likely also review impl, though depends on how involved with metadata it gets

oli (Mar 04 2021 at 15:05, on Zulip):

I talked about this with felix, not the impl, just the idea. So it's not blocked on them

triagebot (Mar 04 2021 at 15:08, on Zulip):

@T-compiler: Proposal #410 has been seconded, and will be approved in 10 days if no objections are raised.

RalfJ (Mar 05 2021 at 08:53, on Zulip):

oli said:

it's pretty much exactly that, except imo it's less hacky than the linkme crate, as it does not rely on linker functionality. It's the MVP needed for https://github.com/rust-lang/const-eval/issues/25#issuecomment-533840428 (which itself is desirable for custom test harnesses, tracing metadata and custom const-evaluated artifacts).

I'm just saying that feels like a major language (CTFE) feature on its own right that requires an RFC. There's a large design space here. I was very surprised to see this "en passant" in what is superficially an unrelated proposal.^^

oli (Mar 05 2021 at 09:13, on Zulip):

well... it's going to be a really unstable rustc attribute with no intention of getting stabilized. I thought this a situation like rustc_scalar_range_start which is the attribute that gives us the NonZero types

RalfJ (Mar 05 2021 at 09:18, on Zulip):

that attribute is a very thin layer on top of an already existing rustc feature

RalfJ (Mar 05 2021 at 09:18, on Zulip):

this here, OTOH, will require some major infrastructure

oli (Mar 05 2021 at 09:25, on Zulip):

the "only" new thing is the generation of the constant in the end. We already have such "attribute collection queries" (rustc_diagnostic_item works pretty much the same way). I agree that the nice way would be to first RFC a proper feature here, but it also feels like a feature I don't really want to RFC in the next year or so as wg-const-eval has enough unfinished features on its plate

hyd-dev (Mar 05 2021 at 10:11, on Zulip):

I'm not sure if this is related, but I really would love to see "a built-in version of linkme": https://github.com/rust-lang/rust/issues/82371#issuecomment-784421726

RalfJ (Mar 05 2021 at 10:36, on Zulip):

RalfJ said:

that attribute is a very thin layer on top of an already existing rustc feature

also remember that this feature was unsound for quite some time until we fixed the unsafety checker. So it's not a great example for "ad-hoc language extension gone well".^^

RalfJ (Mar 05 2021 at 10:39, on Zulip):

the "only" new thing is the generation of the constant in the end.

We need at least two mechanisms that work together: to "register" an element to be part of this slice (const-eval with side-effects, that sounds tricky), and then at link time something to collect all pieces of the slice and put them into the original slice variable. We need to ensure that CTFE doesn't read from these slices as that would create funny cycles. I think there are quite a few subtleties here.

Notification Bot (Mar 05 2021 at 11:06, on Zulip):

This topic was moved by oli to #t-compiler/const-eval > aggregate arbitrary constants at compile-time into a sing...

triagebot (Mar 25 2021 at 21:19, on Zulip):

This proposal has been accepted: #410.

Last update: May 07 2021 at 08:00UTC