What should we guarantee regarding "sort-of unused" extern statics #54388
Comments
pnkfelix
added
T-compiler
|
My current assumptions:
|
|
nominating for discussion at compiler team meeting. |
|
IMO not-a-bug. It is possible to make this sort of case behave consistently regardless of the compilation mode (to make it consistently succeed, a weak definition could be provided, but that seems kind of insane thing to do; to make it consistently fail a non-optimisable reference to the declaration would have to be generated). However, the current behaviour is already fairly consistent across all the toolchains I’ve used so far and has its own benefits as well (not having to generate extra code for example) |
|
discussed at T-compiler meeting But it was at the end of the meeting and I decided, based on the opinions put forward, we should not attempt to reach any final conclusions in a five minute discussion |
|
@nagisa I just want to clarify: when you say "not-a-bug", you are saying the current behavior of rustc is not a bug in rustc, right? (As opposed to, e.g., "the test is not buggy") That is my reading of the paragraphs you wrote after the "not-a-bug", but I just wanted to double-check. |
|
Your interpretation is correct.
…On Thu, Sep 20, 2018, 18:51 Felix S Klock II ***@***.***> wrote:
@nagisa <https://github.com/nagisa> I just want to clarify: when you say
"not-a-bug", you are saying the current behavior of *rustc* is not a bug
in rustc, right?
(As opposed to, e.g., "the test is not buggy")
That is my reading of the paragraphs you wrote after the "not-a-bug", but
I just wanted to double-check.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#54388 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AApc0gCeHRWRGbK7R7OTU4u8bi-qF4hjks5uc7lvgaJpZM4WyJPW>
.
|
|
based on the radio silence over past month, I'm concluding that the compiler's behavior here is not-buggy, and that the test itself should be revised in some manner (perhaps as outlined above) to avoid tripping on this. |
As a drive-by, added `-g` to the compile-flags so that the test more reliably fails to compile when the extern static in question is *not* provided. (I.e. this is making the test more robust in the face of potential future revisions.) Fix rust-lang#54388.
…error-from-rustfixed-code, r=alexcrichton Sidestep link error from rustfix'ed code by using a *defined* static. As a drive-by, added `-g` to the compile-flags so that the test more reliably fails to compile when the extern static in question is *not* provided. (I.e. this is making the test more robust in the face of potential future revisions.) Fix rust-lang#54388.
…error-from-rustfixed-code, r=alexcrichton Sidestep link error from rustfix'ed code by using a *defined* static. As a drive-by, added `-g` to the compile-flags so that the test more reliably fails to compile when the extern static in question is *not* provided. (I.e. this is making the test more robust in the face of potential future revisions.) Fix rust-lang#54388.
Spawned off of #54188 (comment)
Right now we have a "test" that is auto-generated (via
rustfix) that looks like this:rust/src/test/ui/extern/extern-const.fixed
Lines 12 to 25 in f7f4c50
Note that there aren't any definitions provided for that
extern "C" { static C: u8; }; we haven't linked in any code that gives a definition for it.Today,
rustcwill compile that code without complaint (as long as you don't add the-gto the command line). And you can even run it.Likewise,
cargo build --releasewill also compile without complaint: playbut
cargo build(developer aka debug mode) says this (play):So my hypothesis is that LLVM is managing to optimize the code enough that it doesn't notice the missing extern symbol definiton.
(But for some reason, after applying #54188, in some scenarios it does start to notice the missing extern symbol definition.)
The text was updated successfully, but these errors were encountered: