Add support for `const unsafe? extern fn` by Aaron1011 · Pull Request #64906 · rust-lang/rust

Aaron1011 · 2019-09-29T23:53:36Z

This works just as you might expect - an const extern fn is a const fn that is callable from foreign code.

Currently, panicking is not allowed in consts. When rust-lang/rfcs#2345 (#51999) is stabilized, then panicking in an const extern fn will produce a compile-time error when invoked at compile time, and an abort when invoked at runtime.

Since this is extending the language (we're allowing the const keyword in a new context), I believe that this will need an FCP. However, it's a very minor change, so I didn't think that filing an RFC was necessary.

This will allow libc (and other FFI crates) to make many functions const, without having to give up on making them extern as well.

Tracking issue: #64926.

rust-highfive · 2019-09-29T23:53:43Z

r? @petrochenkov

(rust_highfive has picked a reviewer for you, use r? to override)

Centril · 2019-09-30T00:41:21Z

r? @Centril

src/libsyntax/parse/parser/item.rs

Centril · 2019-09-30T00:52:15Z

Since this is extending the language (we're allowing the const keyword in a new context), I believe that this will need an FCP. However, it's a very minor change, so I didn't think that filing an RFC was necessary.

This should definitely be feature gated (pre-expansion, see #64672 for examples) and not insta-stabilized. Please create a new tracking issue and think add it to the list in #57563.

Aaron1011 · 2019-09-30T19:25:41Z

@Centril: I've added a feature gate. changed the grammar, and created a tracking issue.

src/test/ui/reify-intrinsic.stderr

src/libsyntax/parse/mod.rs

src/libsyntax/feature_gate/active.rs

src/libsyntax/parse/parser.rs

src/libsyntax/parse/parser/item.rs

src/test/ui/parser/removed-syntax-extern-const-fn.rs

src/test/ui/reify-intrinsic.stderr

src/test/ui/consts/const-fn-extern.rs

src/test/ui/feature-gates/feature-gate-const_extern_fn.rs

src/test/ui/consts/const-fn-extern.rs

Aaron1011 · 2019-10-01T01:26:59Z

@Centril I've added more tests

src/libsyntax/parse/mod.rs

src/libsyntax/parse/parser.rs

src/libsyntax/parse/parser/item.rs

src/test/ui/consts/const-extern-fn/const-extern-fn-min-const-fn.rs

src/test/ui/consts/const-extern-fn/const-extern-fn.stderr

src/test/ui/parser/no-const-fn-in-extern-block-unsafe.rs

src/test/ui/consts/const-extern-fn/const-extern-fn-call-extern-fn.rs

Aaron1011 · 2019-10-01T21:51:03Z

@Centril: I've added more tests, and implemented parsing recovering for extern blocks.

This works just as you might expect - an 'extern const fn' is a 'const fn' that is callable from foreign code. Currently, panicking is not allowed in consts. When RFC 2345 is stabilized, then panicking in an 'extern const fn' will produce a compile-time error when invoked at compile time, and an abort when invoked at runtime. Since this is extending the language (we're allowing the `const` keyword in a new context), I believe that this will need an FCP. However, it's a very minor change, so I didn't think that filing an RFC was necessary. This will allow libc (and other FFI crates) to make many functions `const`, without having to give up on making them `extern` as well.

Centril · 2019-10-02T17:06:54Z

Thanks! -- Implementation looks good now.

@rust-lang/lang N.B. this adds support for const unsafe? extern ABI? fn under a feature gate const_extern_fn. The changes are syntactic in nature and the semantic changes mainly just fall out. I'll r+ this since I think it's fine to land for experimentation purposes and the discussion can progress on the tracking issue. However, I think we may eventually want a stabilization RFC that takes into account all of the discussion thus far and elaborates on semantics, use-cases, etc.

@bors r+

bors · 2019-10-02T17:06:56Z

📌 Commit 84b680f has been approved by Centril

…r=Centril Add support for `const unsafe? extern fn` This works just as you might expect - an `const extern fn` is a `const fn` that is callable from foreign code. Currently, panicking is not allowed in `const`s. When rust-lang/rfcs#2345 (rust-lang#51999) is stabilized, then panicking in an `const extern fn` will produce a compile-time error when invoked at compile time, and an abort when invoked at runtime. Since this is extending the language (we're allowing the `const` keyword in a new context), I believe that this will need an FCP. However, it's a very minor change, so I didn't think that filing an RFC was necessary. This will allow libc (and other FFI crates) to make many functions `const`, without having to give up on making them `extern` as well. Tracking issue: rust-lang#64926.

Previously, we were using an `FxHashMap` to collect module re-exports. However, re-exports end up getting serialized into crate metadata, which means that metadata generation was non-deterministic. This resulted in spurious error messages changes (e.g. PR rust-lang#64906) due to pretty-printing implicitly depending on the order of re-exports when computing the proper path to show to the user. See rust-lang#65042 for a long-term strategy to detect this kind of issue

…nkov Make re-export collection deterministic Fixes #65036 Previously, we were using an `FxHashMap` to collect module re-exports. However, re-exports end up getting serialized into crate metadata, which means that metadata generation was non-deterministic. This resulted in spurious error messages changes (e.g. PR #64906) due to pretty-printing implicitly depending on the order of re-exports when computing the proper path to show to the user. See #65042 for a long-term strategy to detect this kind of issue

Aaron1011 · 2019-10-06T17:06:34Z

@Centril : This is ready to be merged now that the non-determinism has been fixed

Centril · 2019-10-06T20:21:12Z

@bors r+

bors · 2019-10-06T20:21:13Z

📌 Commit a4cad41 has been approved by Centril

bors · 2019-10-07T00:12:17Z

⌛ Testing commit a4cad41 with merge 4ac4809...

Add support for `const unsafe? extern fn` This works just as you might expect - an `const extern fn` is a `const fn` that is callable from foreign code. Currently, panicking is not allowed in `const`s. When rust-lang/rfcs#2345 (#51999) is stabilized, then panicking in an `const extern fn` will produce a compile-time error when invoked at compile time, and an abort when invoked at runtime. Since this is extending the language (we're allowing the `const` keyword in a new context), I believe that this will need an FCP. However, it's a very minor change, so I didn't think that filing an RFC was necessary. This will allow libc (and other FFI crates) to make many functions `const`, without having to give up on making them `extern` as well. Tracking issue: #64926.

bors · 2019-10-07T03:45:29Z

☀️ Test successful - checks-azure
Approved by: Centril
Pushing 4ac4809 to master...

RalfJung · 2019-10-09T08:45:06Z

@Aaron1011 Could we also get a test making sure that we properly report an error when calling a const fn using the wrong ABI, such as calling an extern "C" const fn with the call site assuming it is an extern "Rust" const fn? The checks for that should already exist in the engine (for standalone Miri).

Centril · 2019-10-09T09:42:56Z

@RalfJung Excellent point; added a check-box to the tracking issue.

Add support for making functions `const` PR rust-lang/rust#64906 adds the ability to write `const extern fn` and `const unsafe extern fn`, which will allow manys functions in `libc` to become `const`. This is particuarly useful for functions which correspond to C macros (e.g. `CMSG_SPACE`). In C, these macros are constant expressions, allowing them to be used when declaring arrays. However, since the corresponding `libc` functions are not `const`, writing equivalent Rust code is impossible. Users must either perform an unecessary heap allocation, or pull in `bindgen` to evaluate the macro for specific values (e.g. `CMSG_SPACE(1)`). However, the syntax `const extern fn` is not currently parsed by rust. To allow libc to use this without breaking backwards compatibility (i.e. bumping the minimum Rust version), I've taken the following approach: 1. A new off-by-default feature `extern-const-fn` is added to `libc`. 2. The internal `f!` macro has two versions, selected at compile-time by a `cfg_if`. When `extern-const-fn` is enabled, the declared `f!` macro passes through the `const` keyword from the macro user to the final definition (`pub const unsafe extern fn foo`. When `extern-const-fn` is disabled, the `const` keyword passed by the macro user is discarded, resulting in a plain `pub extern const fn` being declared. Unfortunately, I couldn't manage to get `macro_rules` to accept a normal `const` token in the proper place (after `pub`). I had to resort to placing it in curly brackets: ```rust pub {const} fn foo(val: u8) -> i8 { } ``` The `f!` macro then translates this to a function definition with `const` in the proper position. I'd appreciate it if someone who's more familiar with `macro_rules!` could see if I missed a way to get the desired syntax.

rust-highfive assigned petrochenkov Sep 29, 2019

rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Sep 29, 2019

rust-highfive assigned Centril and unassigned petrochenkov Sep 30, 2019

Centril reviewed Sep 30, 2019

View reviewed changes

src/libsyntax/parse/parser/item.rs Outdated Show resolved Hide resolved

src/libsyntax/parse/parser/item.rs Outdated Show resolved Hide resolved

Aaron1011 commented Sep 30, 2019

View reviewed changes

src/test/ui/reify-intrinsic.stderr Outdated Show resolved Hide resolved

Aaron1011 mentioned this pull request Sep 30, 2019

Add support for making functions const rust-lang/libc#1536

Merged

Centril reviewed Sep 30, 2019

View reviewed changes

Centril changed the title ~~Add support for 'extern const fn'~~ Add support for const unsafe? extern fn Sep 30, 2019

Centril reviewed Oct 1, 2019

View reviewed changes

This comment has been minimized.

Sign in to view

Aaron1011 force-pushed the feature/extern-const-fn branch from 99095f4 to 73b50d2 Compare October 2, 2019 04:41

Add missing 'bump'

84b680f

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Oct 2, 2019

Manishearth mentioned this pull request Oct 2, 2019

Rollup of 7 pull requests #65027

Closed

Centril closed this Oct 6, 2019

Centril reopened this Oct 6, 2019

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Oct 6, 2019

bors added the merged-by-bors This PR was explicitly merged by bors. label Oct 7, 2019

bors mentioned this pull request Oct 7, 2019

Object safe for dispatch #57545

Merged

bors merged commit a4cad41 into rust-lang:master Oct 7, 2019

Centril mentioned this pull request Oct 7, 2019

Tracking issue for const extern fn and const unsafe extern fn #64926

Closed

1 task

Aaron1011 deleted the feature/extern-const-fn branch October 7, 2019 05:17

Uh oh!

Conversation

Aaron1011 commented Sep 29, 2019 • edited by Centril Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rust-highfive commented Sep 29, 2019

Uh oh!

Centril commented Sep 30, 2019

Uh oh!

Uh oh!

Uh oh!

Centril commented Sep 30, 2019

Uh oh!

Aaron1011 commented Sep 30, 2019

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Aaron1011 commented Oct 1, 2019

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

This comment has been minimized.

Aaron1011 commented Oct 1, 2019

Uh oh!

Centril commented Oct 2, 2019

Uh oh!

bors commented Oct 2, 2019

Uh oh!

Aaron1011 commented Oct 6, 2019

Uh oh!

Centril commented Oct 6, 2019

Uh oh!

bors commented Oct 6, 2019

Uh oh!

bors commented Oct 7, 2019

Uh oh!

bors commented Oct 7, 2019

Uh oh!

RalfJung commented Oct 9, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Centril commented Oct 9, 2019

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

Aaron1011 commented Sep 29, 2019 •

edited by Centril

Loading

RalfJung commented Oct 9, 2019 •

edited

Loading