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.

Sign up for GitHub

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

Jump to bottom

Unable to compile syntex_syntax using Rust 1.41 #68729

Closed
yaa110 opened this issue Feb 1, 2020 · 7 comments
Closed

Unable to compile syntex_syntax using Rust 1.41 #68729

yaa110 opened this issue Feb 1, 2020 · 7 comments
Labels
P-low Low priority regression-from-stable-to-stable Performance or correctness regression from one stable version to another. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@yaa110
Copy link

yaa110 commented Feb 1, 2020

Unfortunately, syntex_syntax is not maintained and is not compiled using rust 1.41:

   Compiling syntex_syntax v0.58.1
error[E0423]: expected function, tuple struct or tuple variant, found struct `ast::Name`
   --> /root/.cargo/registry/src/github.com-1ecc6299db9ec823/syntex_syntax-0.58.1/src/symbol.rs:146:27
    |
146 |                       name: ast::Name($index),
    |                             ^^^^^^^^^
...
165 | / declare_keywords! {
166 | |     // Invalid identifier
167 | |     (0,  Invalid,        "")
168 | |
...   |
231 | |     (56, CrateRoot, "{{root}}")
232 | | }
    | |_- in this macro invocation

   Compiling clap v2.33.0
   Compiling nom v3.2.1
   Compiling parking_lot v0.10.0
error: aborting due to previous error

For more information about this error, try `rustc --explain E0423`.
error: could not compile `syntex_syntax`.
warning: build failed, waiting for other jobs to finish...
error: build failed
make[1]: *** [objs/Makefile:1314: cargo] Error 101
# rustc --version
rustc 1.41.0 (5e1a79984 2020-01-27)

# uname -a
Linux 6b52ecd4014b 5.3.18-1-MANJARO #1 SMP PREEMPT Wed Dec 18 18:34:35 UTC 2019 x86_64 GNU/Linux
@jonas-schievink jonas-schievink added I-nominated regression-from-stable-to-stable Performance or correctness regression from one stable version to another. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Feb 1, 2020
@jonas-schievink
Copy link
Contributor

It builds fine on 1.40.

FWIW this is not the most up to date version, which is 0.59.1 and builds fine on 1.41.

@pnkfelix
Copy link
Member

pnkfelix commented Feb 6, 2020

Hmm I hadn't noticed that syntex_syntax had been updated in that manner; I just saw that it has not been maintained in three years (see their readme)

This problem is expected fallout from PR #65785

@pnkfelix
Copy link
Member

pnkfelix commented Feb 6, 2020

triage: P-low, with intent to close. Leaving nominated because I want to at least discuss 1. whether we need/want to collect data on instances of such breakage, and 2. whether we were too aggressive in deciding that going straight to an error without some mitigating mechanism was too aggressive.

@pnkfelix pnkfelix added the P-low Low priority label Feb 6, 2020
@yaa110
Copy link
Author

yaa110 commented Feb 6, 2020 •
edited
Loading

syntex_syntax was used in older versions of bindgen crate and is not maintained. So, this issue could be closed. However, this kind of known breaking changes should be declared in blog posts of rustlang update.

@erikjee erikjee mentioned this issue Feb 10, 2020
Merged
@drahnr drahnr mentioned this issue Feb 11, 2020
Closed
@ftilde ftilde mentioned this issue Feb 15, 2020
Closed
@yanqd0 yanqd0 mentioned this issue Feb 17, 2020
Closed
12 tasks
@pnkfelix
Copy link
Member

pnkfelix commented Mar 4, 2020

Removing nomination label and closing.

As I wrote on zulip:

this was not such a big deal in the end. The main question I would want resolved is whether we actually documented this breaking change somewhere visible (release notes from release blog post or something similar). But that does not need to be a discussion during the synchronous T-compiler meeting.

@pnkfelix pnkfelix closed this as completed Mar 4, 2020
kulp added a commit to kulp/tyrga that referenced this issue Apr 11, 2020
@kulp
Obey clippy::filter_next
ca57155 
It was not initially clear to me why, after changing
`.filter(...).next()` to `.find(...)`, the borrow checker as of Rust
1.41.1 required me to inline `all.lines()` at this point :

    error[E0596]: cannot borrow `lines` as mutable, as it is not declared as mutable
      --> tyrga-bin/../build.rs:53:33
       |
    52 |                     let lines = all.lines();
       |                         ----- help: consider changing this to be mutable: `mut lines`
    53 |                     let wrote = lines
       |                                 ^^^^^ cannot borrow as mutable

    error: aborting due to previous error

    For more information about this error, try `rustc --explain E0596`.

but it [appears][0] that the new error is [expected][1], and that if I
had been using `.find()` previously instead of `.filter(...).next()`, I
would have seen a non-fatal "compat" lint under previous compiler
versions, leading me in the same direction.

[0]: rust-lang/rust#68729
[1]: rust-lang/rust#65785
@lupine lupine mentioned this issue Apr 9, 2021
Merged
@clasatas clasatas mentioned this issue May 17, 2021
Closed
@SurfingNerd SurfingNerd mentioned this issue Jun 17, 2021
Open
@Mawfyy
Copy link

Mawfyy commented Jan 23, 2024

I can reproduce this error in rust 1.73.0, there's any solution to this?

@ShipmasterKyle
Copy link

This can repoduced on rust 1.76.0 as well. Is there a solution?

We could attempt syntex_sytntax to an older version but I'm not sure that it'll solve the issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
P-low Low priority regression-from-stable-to-stable Performance or correctness regression from one stable version to another. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@pnkfelix @jonas-schievink @yaa110 @ShipmasterKyle @Mawfyy