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

Tracking issue for constant prop not causing add'l errors (RFC #1229) #28238

Closed
nikomatsakis opened this issue Sep 4, 2015 · 9 comments
Closed
Labels
A-const-eval Area: Constant evaluation, covers all const contexts (static, const fn, ...) A-lint Area: Lints (warnings about flaws in source code) such as unused_mut. B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. B-unstable Blocker: Implemented in the nightly compiler and unstable. C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC S-tracking-needs-summary Status: It's hard to tell what's been done and what hasn't! Someone should do some investigation. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-lang Relevant to the language team, which will review and decide on the PR/issue.

Comments

@nikomatsakis
Copy link
Contributor

Tracking issue for rust-lang/rfcs#1229

cc @oli-obk

@eddyb
Copy link
Member

eddyb commented Sep 12, 2015

Can we move the errors trans::consts generates to check_const?
E.g. only bar causes an error here (a special-case I added before the overflow checks were implemented):

fn foo<T>() -> u8 { 1 + 255 }
fn bar<T>() -> u8 { 1 / 0 }

foo only errors if it is monomorphized, even though the overflow exists in the generic definition.

@oli-obk
Copy link
Contributor

oli-obk commented Oct 2, 2015

@eddyb: that sounds reasonable as a second step, but is orthogonal to the RFC. I also don't want to create a humongous PR, so I'll address the port to check_const right afterwards. It's probably better to create a new issue (and assign it to me if you want)

bors added a commit that referenced this issue Oct 18, 2015
This PR turns statically known erroneous code (e.g. numeric overflow) into a warning and continues normal code-generation to emit the same code that would have been generated without `check_const` detecting that the result can be computed at compile-time.

<del>It's not done yet, as I don't know how to properly emit a lint from trans. I can't seem to extract the real lint level of the item the erroneous expression is in.</del> It's an unconditional warning now.

r? @pnkfelix 

cc @nikomatsakis 

* [RFC 1229 text](https://github.com/rust-lang/rfcs/blob/master/text/1229-compile-time-asserts.md)
* RFC PR: rust-lang/rfcs#1229
* tracking issue: #28238
@brson brson added the B-unstable Blocker: Implemented in the nightly compiler and unstable. label Mar 1, 2017
@brson
Copy link
Contributor

brson commented Mar 1, 2017

@eddyb This is ancient. Can it move forward yet?

@eddyb
Copy link
Member

eddyb commented Mar 1, 2017

@brson Nope, this is blocked on miri!

@Mark-Simulacrum Mark-Simulacrum added C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC and removed C-enhancement Category: An issue proposing an enhancement or a PR with one. C-feature-request Category: A feature request, i.e: not implemented / a PR. labels Jul 22, 2017
@oli-obk oli-obk added the A-const-eval Area: Constant evaluation, covers all const contexts (static, const fn, ...) label Apr 15, 2018
@XAMPPRocky
Copy link
Member

@eddyb What is currently blocking this issue?

@oli-obk
Copy link
Contributor

oli-obk commented Jul 14, 2018

The new const propagator needs to be fixed to actually lint these functions

  1. even if they are unused (make them nongeneric and don't use them -> no lint)
  2. even if they are generic (currently generic functions seem to not get linted)

@Centril Centril added T-lang Relevant to the language team, which will review and decide on the PR/issue. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jan 1, 2019
@jonas-schievink jonas-schievink added the A-lint Area: Lints (warnings about flaws in source code) such as unused_mut. label Mar 28, 2020
@joshtriplett
Copy link
Member

joshtriplett commented Nov 10, 2021

From today's @rust-lang/lang meeting:

ping @RalfJung @oli-obk
Is this currently done? Based on the description, this sounds like something that's working now.

@joshtriplett joshtriplett added the S-tracking-needs-summary Status: It's hard to tell what's been done and what hasn't! Someone should do some investigation. label Nov 10, 2021
@RalfJung
Copy link
Member

Yeah I think this is implemented, but I also don't know what @oli-obk had in mind in their last comment here. @oli-obk what would be an example for something that fails (failed?) to get the lint?

@oli-obk
Copy link
Contributor

oli-obk commented Mar 9, 2022

We are now checking everything properly. I don't remember if my comment was wrong or if it got addressed.

@oli-obk oli-obk closed this as completed Mar 9, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-const-eval Area: Constant evaluation, covers all const contexts (static, const fn, ...) A-lint Area: Lints (warnings about flaws in source code) such as unused_mut. B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. B-unstable Blocker: Implemented in the nightly compiler and unstable. C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC S-tracking-needs-summary Status: It's hard to tell what's been done and what hasn't! Someone should do some investigation. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-lang Relevant to the language team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

10 participants