Master update 28 05 2020

[MabezDev]

No description provided.

[mtorromeo]

This branch (or xtensa-target since the merge) fails to compile for me with these errors:

   Compiling rustbook v0.1.0 (/build/rust-xtensa-git/src/rust-xtensa/src/tools/rustbook)
error[E0308]: mismatched types
  --> src/tools/rustbook/src/main.rs:95:77
   |
95 |     let target_files = mdbook_linkcheck::load_files_into_memory(&book.book, &mut files);
   |                                                                             ^^^^^^^^^^ expected struct `codespan::file::Files`, found a different struct `codespan::file::Files`
   |
   = note: expected mutable reference `&mut codespan::file::Files<std::string::String>`
              found mutable reference `&mut codespan::file::Files`
   = note: perhaps two different versions of crate `codespan` are being used?

error[E0308]: mismatched types
  --> src/tools/rustbook/src/main.rs:98:77
   |
98 |     let (links, incomplete) = mdbook_linkcheck::extract_links(target_files, &files);
   |                                                                             ^^^^^^ expected struct `codespan::file::Files`, found a different struct `codespan::file::Files`
   |
   = note: expected reference `&codespan::file::Files<std::string::String>`
              found reference `&codespan::file::Files`
   = note: perhaps two different versions of crate `codespan` are being used?

error[E0308]: mismatched types
   --> src/tools/rustbook/src/main.rs:101:75
    |
101 |         mdbook_linkcheck::validate(&links, &linkck_cfg, &src_dir, &cache, &files, incomplete)?;
    |                                                                           ^^^^^^ expected struct `codespan::file::Files`, found a different struct `codespan::file::Files`
    |
    = note: expected reference `&codespan::file::Files<std::string::String>`
               found reference `&codespan::file::Files`
    = note: perhaps two different versions of crate `codespan` are being used?

error[E0599]: no method named `is_server_error` found for reference `&reqwest::error::Error` in the current scope
   --> src/tools/rustbook/src/main.rs:122:31
    |
122 |                 } else if err.is_server_error() {
    |                               ^^^^^^^^^^^^^^^ method not found in `&reqwest::error::Error`

error[E0599]: no method named `is_http` found for reference `&reqwest::error::Error` in the current scope
   --> src/tools/rustbook/src/main.rs:124:32
    |
124 |                 } else if !err.is_http() {
    |                                ^^^^^^^ method not found in `&reqwest::error::Error`

error[E0308]: mismatched types
   --> src/tools/rustbook/src/main.rs:134:42
    |
134 |         Ok((outcome.generate_diagnostics(&files, linkck_cfg.warning_policy), files))
    |                                          ^^^^^^ expected struct `codespan::file::Files`, found a different struct `codespan::file::Files`
    |
    = note: expected reference `&codespan::file::Files<std::string::String>`
               found reference `&codespan::file::Files`
    = note: perhaps two different versions of crate `codespan` are being used?

error[E0308]: mismatched types
   --> src/tools/rustbook/src/main.rs:134:13
    |
134 |         Ok((outcome.generate_diagnostics(&files, linkck_cfg.warning_policy), files))
    |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected struct `codespan_reporting::diagnostic::Diagnostic`, found a different struct `codespan_reporting::diagnostic::Diagnostic`
    |
    = note: expected struct `std::vec::Vec<codespan_reporting::diagnostic::Diagnostic>`
               found struct `std::vec::Vec<codespan_reporting::diagnostic::Diagnostic<codespan::file::FileId>>`
    = note: perhaps two different versions of crate `codespan_reporting` are being used?

error: aborting due to 7 previous errors

Some errors have detailed explanations: E0308, E0599.
For more information about an error, try `rustc --explain E0308`.
error: could not compile `rustbook`.

To learn more, run the command again with --verbose.
command did not execute successfully: "/build/rust-xtensa-git/src/rust-xtensa/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "build" "--target" "x86_64-unknown-linux-gnu" "-Zbinary-dep-depinfo" "-j" "16" "--release" "--frozen" "--manifest-path" "/build/rust-xtensa-git/src/rust-xtensa/src/tools/rustbook/Cargo.toml" "--features" "linkcheck" "--message-format" "json-render-diagnostics"
expected success, got: exit code: 101
failed to run: /build/rust-xtensa-git/src/rust-xtensa/build/bootstrap/debug/bootstrap install
Build completed unsuccessfully in 0:12:51

I was compiling successfully before.

Thanks for your efforts!

[MabezDev]

I cant seem to reproduce your issue, perhaps a fresh clone and build?

[mtorromeo]

I just tried again, still the same error. Tried multiple times deleting the whole project directory, tried building it in a clean chroot with just the base dependencies installed. I always get the same exact error.

To double-check I just checked out again commit 25ae59a and recompiled it and it's working correctly without even cleaning the build directory.

I am not sure what to try next. I guess I could try bisecting the repo to find the first commit with the issue but I am not sure that every commit is supposed to build correctly and there are a lot...

[jessebraham]

I'm experiencing the same problem. I can confirm that the build was succeeding yesterday, but upon a fresh clone of the repo today this error has emerged.

Edit: I can confirm that checking out 25ae59a and building works correctly.

[arjanmels]

It works for me. However need to update llvm manually to later version to support all needed asm commands.
I did the following:

git clone git@github.com:MabezDev/rust-xtensa.git
cd rust-xtensa
git submodule update --init --recursive
cd src/llvm-project
git remote rename origin mabezdev
git remote add origin git@github.com:espressif/llvm-project.git 
git fetch origin
# get latest working version of llvm for xtensa
git checkout a5a002fc33cc86b42693c57fc818c71689b3cebc
# get small edits to llvm needed to support use as rust submodule
git cherry-pick 0951ae090a6febf4ae798a5d6912d02691b7688f
git commit -m "latest working llvm"
cd ../..
git add llvm_project
git commit -m "latest working llvm"
./configure --experimental-targets=Xtensa
./x.py build

[matevarga]

I can also confirm that I cannot compile a freshly cloned xtensa-target branch (exactly the same output as the OP).

[MabezDev]

I'm still struggling to reproduce this issue, I've done multiple clean builds with the following steps:

1. git clone https://github.com/MabezDev/rust-xtensa
2. ./configure --experimental-targets=Xtensa
3. ./x.py build

All of which of compiled successfully on my system. Could you provide some more info on your build environment?

[lexxvir]

Works for me too:

• fetch new commits from this repo then merge them
• git submodule update --init --recursive
• ./configure --experimental-targets=Xtensa
• ./x.py build

[mtorromeo]

Alright, I got what we are doing differently.

I am trying to package the project for Arch Linux with a custom PKGBUILD (basically, it's just a bash script). This doesn't really matter because the errors can be reproduced without running the packaging script.

The steps I was using are a little different, but I tried with many variations. Initially, I was using a separately packaged llvm build (with --llvm-root="/opt/llvm-xtensa") but to make things simple I changed it to just ./configure --experimental-targets=Xtensa --prefix=/some/dir/ as it doesn't really make any difference.

The thing is that ./x.py build works fine but ./x.py dist or ./x.py install doesn't, and I needed to run those commands to copy the built files into the destination directory for the package.

This used to work. Maybe that's also what @matevarga and @jessebraham are trying to do.

[matevarga]

Thanks - correct, build works fine, install doesn't.

[jessebraham]

I think @mtorromeo is on the right path. I'm going from memory here but I am fairly confident it was ./x.py install that caused the error for me as well (I forgot to save the logs 😞). I know it was very late in the process at the very least.

I'm building a Dockerfile but this is essentially what is being run:

$ git clone https://github.com/MabezDev/rust-xtensa.git
$ cd ./rust-xtensa
$ ./configure --experimental-targets="Xtensa" --prefix="$RUST_BUILD"
$ python x.py build
$ python x.py install

I realize I did say 'build' in my previous post so apologies for not being more clear about that.

[MabezDev]

Ah okay, thanks for the clarification, I should be able to reproduce now.

[MabezDev]

I think I've found it. mdbook-linkcheck bumped the codespan version, which meant there were two different versions.

Could you try #35?

[jessebraham]

I have checked out f87a95f and successfully built and installed, so that seems to have done the trick. Thanks!

[mtorromeo]

I confirm it's working fine now. Thanks!

[MabezDev]

Glad to hear it :). When you have it packaged up, would you mind PR'ing a link to it in the readme? I'm sure arch users would appreciate it!

[mtorromeo]

Sure thing! I am still ironing out a few things. Note that there's already a package on AUR [1] but I am working on a cleaner implementation.

I know that by nature of this project it's maybe not an easy thing to do but it would be cool to have some tagged commits for stable/semi-stable builds so that I can prepare a package that follows those "releases".

[1] https://aur.archlinux.org/packages/rust-xtensa-git/

[MabezDev]

That might be quite difficult, but I could try and loosely follow the rust update cycle (every 6 weeks)? If that works for you I could try and do that for the next Rust release?

[mtorromeo]

The idea is a new release should represent a suggested version to use because you either think that it should work better than any other random commit and/or that the user should really update from an older commit because there are important changes in the new version.

6 weeks update cycles should be fine but I think the fixed release windows are something that is more useful to the developers to organize the work into releases and plan features ahead of time. You can use whatever timeline you are comfortable with IMO.

If you think that pulling changes at every push you make to the default branch has the same stability "guarantees" than the releases you would tag, then I don't think you should make your life any harder by worrying about the releases.

I'll leave it up to you, whatever you can do is really appreciated anyway!