Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deny the overflowing_literals lint for all editions #55632

Merged
merged 2 commits into from
Feb 25, 2019

Conversation

ollie27
Copy link
Member

@ollie27 ollie27 commented Nov 2, 2018

The overflowing_literals was made deny by default for the 2018 edition by #54507, however I'm not aware of any reason it can't be made deny by default for the 2015 edition as well.

@rust-highfive
Copy link
Collaborator

r? @nikomatsakis

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

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Nov 2, 2018
@rust-highfive
Copy link
Collaborator

The job x86_64-gnu-llvm-5.0 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.
travis_time:end:0de321d0:start=1541197078263157112,finish=1541197137001122189,duration=58737965077
$ git checkout -qf FETCH_HEAD
travis_fold:end:git.checkout

Encrypted environment variables have been removed for security reasons.
See https://docs.travis-ci.com/user/pull-requests/#Pull-Requests-and-Security-Restrictions
$ export SCCACHE_BUCKET=rust-lang-ci-sccache2
$ export SCCACHE_REGION=us-west-1
Setting environment variables from .travis.yml
$ export IMAGE=x86_64-gnu-llvm-5.0
---
[00:51:22] .................................................................................................... 100/4983
[00:51:25] .................................................................................................... 200/4983
[00:51:28] ...........................................................................................ii....... 300/4983
[00:51:31] .........................................................................................iii........ 400/4983
[00:51:34] iiiiiiii.iii...........................iii...........................................i...........i.. 500/4983
[00:51:41] .................................................................................................... 700/4983
[00:51:48] ..................................................................i...........i..................... 800/4983
[00:51:51] ....................................................................................iiiii........... 900/4983
[00:51:55] .................................................................................................... 1000/4983
---
[00:52:34] .................................................................................................... 2200/4983
[00:52:39] .................................................................................................... 2300/4983
[00:52:42] .................................................................................................... 2400/4983
[00:52:46] .................................................................................................... 2500/4983
[00:52:50] ..................................................................iiiiiiiii......................... 2600/4983
[00:52:57] ..................ii................................................................................ 2800/4983
[00:53:00] .................................................................................................... 2900/4983
[00:53:04] .................................................................................................... 3000/4983
[00:53:07] .............i...................................................................................... 3100/4983
---
travis_time:start:test_codegen
Check compiletest suite=codegen mode=codegen (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
[01:06:55] 
[01:06:55] running 115 tests
[01:06:58] i..ii...iii..iii.....i...i.........i..iii...........i.....i.....ii...i..i.ii..............i...ii..ii 100/115
[01:06:58] .i....iiii.....
[01:06:58] 
[01:06:58]  finished in 3.577
[01:06:58] travis_fold:end:test_codegen

---
travis_time:start:test_debuginfo
Check compiletest suite=debuginfo mode=debuginfo-both (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
[01:07:13] 
[01:07:13] running 118 tests
[01:07:38] .iiiii...i.....i..i...i..i.i..i.i..i.....i..i....i..........iiii.........i.i....i...i.......ii.i.i.i 100/118
[01:07:42] ......iii.i.....ii
[01:07:42] 
[01:07:42]  finished in 28.620
[01:07:42] travis_fold:end:test_debuginfo

---
[01:42:30] 
[01:42:30] failures:
[01:42:30] 
[01:42:30] ---- /checkout/src/doc/rustc/src/lints/listing/warn-by-default.md - Warn_by_default_lints::overflowing_literals (line 293) stdout ----
[01:42:30] error: literal out of range for u8
[01:42:30]   |
[01:42:30]   |
[01:42:30] 3 | let x: u8 = 1000;
[01:42:30]   |
[01:42:30]   = note: #[deny(overflowing_literals)] on by default
[01:42:30] 
[01:42:30] thread '/checkout/src/doc/rustc/src/lints/listing/warn-by-default.md - Warn_by_default_lints::overflowing_literals (line 293)' panicked at 'couldn't compile the test', librustdoc/test.rs:332:13
---
[01:42:30] 
[01:42:30] 
[01:42:30] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test
[01:42:30] Build completed unsuccessfully in 0:54:59
[01:42:30] Makefile:58: recipe for target 'check' failed
[01:42:30] make: *** [check] Error 1
3552496 ./obj
3406820 ./obj/build
2767728 ./obj/build/x86_64-unknown-linux-gnu
1195164 ./.git
---
163176 ./.git/modules/src/tools/lldb/objects
163168 ./.git/modules/src/tools/lldb/objects/pack
151412 ./src/tools/clang
150348 ./obj/build/bootstrap/debug/incremental
149112 ./src/llvm-emscripte"$EXE" ]; then printf travis_fold":start:crashlog\n\033[31;1m%s\033[0m\n" "$CORE"; gdb --batch -q -c "$CORE" "$EXE" -iex 'set auto-load off' -iex 'dir src/' -iex 'set sysroot .' -ex bt -ex q; echo travis_fold":"end:crashlog; fi; done || true

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

@nikomatsakis nikomatsakis added I-nominated S-waiting-on-team Status: Awaiting decision from the relevant subteam (see the T-<team> label). T-lang Relevant to the language team, which will review and decide on the PR/issue. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Nov 7, 2018
@nikomatsakis
Copy link
Contributor

Nominating for @rust-lang/lang team discussion -- do we want to do this, and -- if so -- what procedure is required? My guess is "yes", we do want to, but we need at least an FCP, and maybe a crater run to assess overall impact?

@nikomatsakis
Copy link
Contributor

Or perhaps that was done already, I forget?

@Centril
Copy link
Contributor

Centril commented Nov 7, 2018

@nikomatsakis I don't recall any crater run being done; I did some looking around and couldn't find any such run so I think it wasn't done. To be on the safe side I think we need at least such a crater run to be done.

I think if crater shows up 0 or some very very low number then it could be feasible.

@scottmcm
Copy link
Member

scottmcm commented Nov 8, 2018

I still want this, and we can do it regardless of crater because it's just a lint level.

Obviously running a crater run for it is nice -- and is relatively cheap, since it's just a check run with -Doverflowing_literals -- but I feel like any code we're really worried about that's doing this is probably already allowing the lint, so changing the default level wouldn't break them anyway.

@aturon
Copy link
Member

aturon commented Nov 8, 2018

We discussed this in the lang team meeting today. Generally everyone is in favor, but we would like to see a crater run just to assess whether it'd be helpful to adjust some key crates before this gets fully rolled out.

@aturon
Copy link
Member

aturon commented Nov 8, 2018

@bors try

@bors
Copy link
Contributor

bors commented Nov 8, 2018

⌛ Trying commit b049141773332c40635f9da831beb9e81d6387db with merge dc13be39fae8d4c607889b27de374b52586485a3...

@bors
Copy link
Contributor

bors commented Nov 8, 2018

☀️ Test successful - status-travis
State: approved= try=True

@Mark-Simulacrum
Copy link
Member

@craterbot run start=master#653da4fd006c97625247acd7e076d0782cdc149b end=try#dc13be39fae8d4c607889b27de374b52586485a3 mode=check-only

I think this should be the right config but not entirely certain (lints are odd, sometimes). Crater queue is empty anyway.

@craterbot
Copy link
Collaborator

👌 Experiment pr-55632 created and queued.
🔍 You can check out the queue and this experiment's details.

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

@craterbot craterbot added S-waiting-on-crater Status: Waiting on a crater run to be completed. and removed S-waiting-on-team Status: Awaiting decision from the relevant subteam (see the T-<team> label). labels Nov 9, 2018
@craterbot
Copy link
Collaborator

🚧 Experiment pr-55632 is now running on agent aws-2.

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

@craterbot
Copy link
Collaborator

🎉 Experiment pr-55632 is completed!
📰 Open the full report.

⚠️ If you notice any spurious failure please add them to the blacklist!
ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

@craterbot craterbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-crater Status: Waiting on a crater run to be completed. labels Nov 10, 2018
@ollie27
Copy link
Member Author

ollie27 commented Nov 12, 2018

32 regressions. 2 were spurious:

20 are bugs in the crates and code that the compiler should never have accepted in the first place:

10 are hex or binary signed literals that could be considered false positives (#24361):

At least it's clear that we need to make overflowing literals a hard error at some point, at least for decimal and for binary and hex when you specify too many bits.

@Centril
Copy link
Contributor

Centril commented Nov 16, 2018

@ollie27 could you reach out to affected regressed crates (with PRs perhaps) so that we can move ahead?

@Centril
Copy link
Contributor

Centril commented Feb 22, 2019

Failed in rollup #58637, @bors r-

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

ollie27 commented Feb 25, 2019

That should be fixed now.

@Centril
Copy link
Contributor

Centril commented Feb 25, 2019

@bors r+

@bors
Copy link
Contributor

bors commented Feb 25, 2019

📌 Commit e7296fd has been approved by Centril

@bors 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 Feb 25, 2019
Centril added a commit to Centril/rust that referenced this pull request Feb 25, 2019
…r=Centril

Deny the `overflowing_literals` lint for all editions

The `overflowing_literals` was made deny by default for the 2018 edition by rust-lang#54507, however I'm not aware of any reason it can't be made deny by default for the 2015 edition as well.
Centril added a commit to Centril/rust that referenced this pull request Feb 25, 2019
…r=Centril

Deny the `overflowing_literals` lint for all editions

The `overflowing_literals` was made deny by default for the 2018 edition by rust-lang#54507, however I'm not aware of any reason it can't be made deny by default for the 2015 edition as well.
Centril added a commit to Centril/rust that referenced this pull request Feb 25, 2019
…r=Centril

Deny the `overflowing_literals` lint for all editions

The `overflowing_literals` was made deny by default for the 2018 edition by rust-lang#54507, however I'm not aware of any reason it can't be made deny by default for the 2015 edition as well.
bors added a commit that referenced this pull request Feb 25, 2019
Rollup of 10 pull requests

Successful merges:

 - #55632 (Deny the `overflowing_literals` lint for all editions)
 - #58687 (Reduce Miri Code Repetition like `(n << amt) >> amt`)
 - #58690 (Reduce a Code Repetition like `(n << amt) >> amt`)
 - #58718 (Apply docs convention: Replace # Unsafety with # Safety in docs)
 - #58719 (librustc_codegen_llvm: #![deny(elided_lifetimes_in_paths)])
 - #58720 (librustc_codegen_ssa: #![deny(elided_lifetimes_in_paths)])
 - #58722 (librustc_typeck: deny(elided_lifetimes_in_paths))
 - #58723 (librustc: deny(elided_lifetimes_in_paths))
 - #58725 (Test that binop subtyping in rustc_typeck fixes #27949)
 - #58727 (bootstrap: deny(rust_2018_idioms))

Failed merges:

r? @ghost
@bors bors merged commit e7296fd into rust-lang:master Feb 25, 2019
@ollie27 ollie27 deleted the deny_overflowing_literals branch February 25, 2019 14:56
@BurntSushi
Copy link
Member

BurntSushi commented Mar 4, 2019

FWIW, this broke byteorder's test suite. It looks like many of its doc tests were (incorrectly) using overflowing literals. I don't set allow(overflowing_literals), but it looks like lint errors aren't reported via cargo test --doc, so I didn't even know anything was wrong.

Obviously, I will just fix the doc tests here, but I'm curious why this change was made in Rust 2015. The original RFC seems to target Rust 2018, probably because this is a breaking change, no? Have we converted lints to deny before?

More pragmatically, there may be other breakage in the ecosystem that is being missed because it seems like the initial crater run didn't catch this.

@Mark-Simulacrum
Copy link
Member

FWIW we can probably do another crater run in rustdoc mode (I think that'll catch the lint errors, but not sure). How did you notice that it was broken?

@BurntSushi
Copy link
Member

BurntSushi commented Mar 4, 2019

@Dylan-DPC did a crater run: BurntSushi/byteorder#144

I'm not too familiar with crater and what it can and can't catch, so I'm not sure why it wasn't caught before. But if there's a rustdoc mode, then that might explain things.

I also usually have daily cron jobs setup on CI, but it wasn't enabled for byteorder. I added that back in, so that would have caught it too once the new nightly was released.

@BurntSushi
Copy link
Member

I think #41574 would have helped catch the bug on my end as soon as the overflowing literal made it into the doc test.

@Mark-Simulacrum
Copy link
Member

Yeah, that would've been the beta crater run -- interestingly, not the rustdoc mode. (https://crater-reports.s3.amazonaws.com/beta-1.34-1/beta-2019-02-27/reg/byteorder-1.2.7/log.txt is the relevant log).

I think crater presumably invokes rustdoc with that flag? Not sure why it wasn't caught in crater on this PR though.

@Centril Centril added this to the 1.33 milestone Apr 27, 2019
BProg pushed a commit to BProg/des_chipher_rust that referenced this pull request Feb 6, 2020
In a future version of Rust the `overflowing_literals` lint will become deny by default. See rust-lang/rust#55632. When checking for breakage in crates uploaded to crates.io it was discovered that this crate will no longer compile thanks to this lint. The error produced is [here](https://crater-reports.s3.amazonaws.com/pr-55632/try%23dc13be39fae8d4c607889b27de374b52586485a3/gh/BProg.des_chipher_rust/log.txt). This PR should fix the false positive.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
relnotes Marks issues that should be documented in the release notes of the next release. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-lang Relevant to the language team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet