https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=perf-tmp 2024-12-16T18:08:19+00:00 2024-12-16T18:08:19+00:00 Jonathan Dönszelmann jonathan@donsz.nl 2024-12-13T13:47:11+00:00 urn:sha1:efb98b6552abd00c58a2c1dd171b9086edf28214 2024-12-16T18:08:19+00:00 Jonathan Dönszelmann jonathan@donsz.nl 2024-12-07T14:27:17+00:00 urn:sha1:1341366af911a16c53513d5eda2cc8cf31c8c027 2024-12-15T18:18:46+00:00 Jonathan Dönszelmann jonathan@donsz.nl 2024-10-16T23:14:01+00:00 urn:sha1:d50c0a5480257cbac33b312cb633777f3d2b2483 2024-11-10T09:16:26+00:00 Ralf Jung post@ralfj.de 2024-11-02T20:19:21+00:00 urn:sha1:e96808162ad7ff5906d7b58d32a25abe139e998c 2024-11-10T09:01:27+00:00 Ralf Jung post@ralfj.de 2024-11-02T19:15:18+00:00 urn:sha1:686eeb83e9c6d7f70848cdf84f490f5c1aa3edd3 2024-11-04T22:27:45+00:00 Ralf Jung post@ralfj.de 2024-11-01T21:19:42+00:00 urn:sha1:10723c28964d582814ea8e07dbd8fa7367e0eaee 2024-10-25T18:31:40+00:00 Ralf Jung post@ralfj.de 2024-10-06T17:59:19+00:00 urn:sha1:a0215d8e46aab41219dea0bb1cbaaf97dafe2f89 Fundamentally, we have *three* disjoint categories of functions: 1. const-stable functions 2. private/unstable functions that are meant to be callable from const-stable functions 3. functions that can make use of unstable const features This PR implements the following system: - `#[rustc_const_stable]` puts functions in the first category. It may only be applied to `#[stable]` functions. - `#[rustc_const_unstable]` by default puts functions in the third category. The new attribute `#[rustc_const_stable_indirect]` can be added to such a function to move it into the second category. - `const fn` without a const stability marker are in the second category if they are still unstable. They automatically inherit the feature gate for regular calls, it can now also be used for const-calls. Also, several holes in recursive const stability checking are being closed. There's still one potential hole that is hard to avoid, which is when MIR building automatically inserts calls to a particular function in stable functions -- which happens in the panic machinery. Those need to *not* be `rustc_const_unstable` (or manually get a `rustc_const_stable_indirect`) to be sure they follow recursive const stability. But that's a fairly rare and special case so IMO it's fine. The net effect of this is that a `#[unstable]` or unmarked function can be constified simply by marking it as `const fn`, and it will then be const-callable from stable `const fn` and subject to recursive const stability requirements. If it is publicly reachable (which implies it cannot be unmarked), it will be const-unstable under the same feature gate. Only if the function ever becomes `#[stable]` does it need a `#[rustc_const_unstable]` or `#[rustc_const_stable]` marker to decide if this should also imply const-stability. Adding `#[rustc_const_unstable]` is only needed for (a) functions that need to use unstable const lang features (including intrinsics), or (b) `#[stable]` functions that are not yet intended to be const-stable. Adding `#[rustc_const_stable]` is only needed for functions that are actually meant to be directly callable from stable const code. `#[rustc_const_stable_indirect]` is used to mark intrinsics as const-callable and for `#[rustc_const_unstable]` functions that are actually called from other, exposed-on-stable `const fn`. No other attributes are required. 2024-10-23T20:15:59+00:00 Matthias Krüger matthias.krueger@famsik.de 2024-10-12T09:52:30+00:00 urn:sha1:dab76eccdfbb6f7b4b445ad05ba4ef004c43e130 double_parens filter_map_identity needless_question_mark redundant_guards 2024-10-23T08:14:41+00:00 Ralf Jung post@ralfj.de 2024-10-09T07:01:57+00:00 urn:sha1:ad3991d30382676f987a38243b3097d880b9033a 2024-10-16T07:41:49+00:00 Urgau urgau@numericable.fr 2024-10-16T07:41:49+00:00 urn:sha1:5eb863698964b026149f4ed9f958639eb290f5b3