Skip to content

Crates using placement syntax behind a cfg broken #50832

Description

@emilyalbini

Some crates were using <- behind a feature flag, so they worked on stable even if the placement syntax was nightly-only. After removing it though they fail to compile even on stable with a syntax error, because <- is not recognized anymore.

Activity

  1. added
    T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.
    C-bugCategory: This is a bug.
    on May 17, 2018
  2. added this to the 1.27 milestone on May 17, 2018
  3. kennytm commented on May 17, 2018

    @kennytm
    Member

    It is already fixed in mbox 0.5.0 and 0.4.4.

  4. nikomatsakis commented on May 17, 2018

    @nikomatsakis
    Contributor

    Oh, that's annoying. We should patch rayon-hash.

  5. petrochenkov commented on May 17, 2018

    @petrochenkov
    Contributor

    This is not the first time this is happening, removal of impl Trait for .. {} caused same consequences (see #46480).
    We should probably continue parsing <- and report the error later in AST validation.

  6. nikomatsakis commented on May 17, 2018

    @nikomatsakis
    Contributor

    Discussed in the @rust-lang/compiler meeting. I think we reached this consensus:

    • in this case, yes, we should do as @petrochenkov suggests: keep parsing, error in AST validation
    • if in the future, if it happens that we want to repurpose the syntax, we deal with it then: best of course is to use an edition for it, but maybe by then there no longer exist crates using it
    • going forward, it would be ideal if we could do some kind of "pre-cfg / expansion" feature check to try and avoid this in the future; that may or may not be feasible though, and we couldn't do it retroactively for all existing things anyway
  7. nikomatsakis commented on May 17, 2018

    @nikomatsakis
    Contributor

    Some discussion of the final at or around here in the IRC logs

    https://botbot.me/mozilla/rustc/2018-05-17/?msg=100165163&page=3

  8. nikomatsakis commented on May 17, 2018

    @nikomatsakis
    Contributor

    triage: P-high

  9. nikomatsakis commented on May 17, 2018

    @nikomatsakis
    Contributor

    Would anyone have time to whip up a change to the parser?

    cc @rust-lang/compiler @aidanhs

  10. nikomatsakis commented on May 17, 2018

    @nikomatsakis
    Contributor

    For reference, the PR that reverted the syntax was #48333

  11. cuviper commented on May 17, 2018

    @cuviper
    Member

    I am working on rayon-hash. The quick hack would be to just nuke the placement stuff, but I'm trying to do a proper update to catch up to std's code -- fun with git subtree.

    But frankly, I don't know of anyone really using rayon-hash anyway.

  12. cuviper commented on May 17, 2018

    @cuviper
    Member

    Fixed in rayon-hash 0.3.0.

  13. self-assigned this
    on May 23, 2018
  14. nikomatsakis commented on May 23, 2018

    @nikomatsakis
    Contributor

    I'll handle this.

  15. nikomatsakis commented on May 24, 2018

    @nikomatsakis
    Contributor

    Restored in #51052

  16. leoyvens commented on May 24, 2018

    @leoyvens
    Contributor

    We could try calling more attention to lib authors about this through the API guidelines.

  17. added a commit that references this issue on May 26, 2018
  18. estebank commented on Sep 19, 2018

    @estebank
    Contributor

    The two regressions where about <-, but we also reverted the in syntax as well, which has degraded back a couple of errors, like the following:

    fn main() {
        let i = ();
        for x in in 0..1 {}
        i;
    }
    

    Would it be ok to create a PR removing the in parsing while keeping the current <- handling for a while longer?

    CC #36611 #52964 #51602

  19. added a commit that references this issue on Sep 22, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

C-bugCategory: This is a bug.P-highHigh priorityT-compilerRelevant to the compiler team, which will review and decide on the PR/issue.regression-from-stable-to-betaPerformance or correctness regression from stable to beta.

Type

No type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions