- 05 6月, 2021 18 次提交
-
-
由 bors 提交于
Rollup of 10 pull requests Successful merges: - #83653 (Remove unused code from `rustc_data_structures::sync`) - #84466 (rustdoc: Remove `PrimitiveType::{to_url_str, as_str}`) - #84880 (Make match in `register_res` easier to read) - #84942 (rustdoc: link to stable/beta docs consistently in documentation) - #85853 (Warn against boxed DST in `improper_ctypes_definitions` lint) - #85939 (Fix suggestion for removing &mut from &mut macro!().) - #85966 (wasm: Make simd types passed via indirection again) - #85979 (don't suggest unsized indirection in where-clauses) - #85983 (Update to semver 1.0.3) - #85988 (Note that `ninja = false` goes under `[llvm]`) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
-
由 Yuki Okushi 提交于
Note that `ninja = false` goes under `[llvm]` Addresses https://github.com/rust-lang/rust/issues/84938#issuecomment-852448332 - `@kornelski` does this look good? r? `@Mark-Simulacrum` cc `@joshtriplett`
-
由 Yuki Okushi 提交于
Update to semver 1.0.3 Fixes https://github.com/rust-lang/cargo/pull/9508#issuecomment-854326213 by pulling in https://github.com/dtolnay/semver/pull/247. Fixes https://github.com/rust-lang/cargo/issues/9543
-
由 Yuki Okushi 提交于
don't suggest unsized indirection in where-clauses Skip where-clauses when suggesting using indirection in combination with `?Sized` bounds on type parameters. Fixes #85943. `@estebank` I think this doesn't conflict with your work in #85947; please let me know if you'd like me to cherry pick it to a new branch based on yours instead.
-
由 Yuki Okushi 提交于
wasm: Make simd types passed via indirection again This commit updates wasm target specs to use `simd_types_indirect: true` again. Long ago this was added since wasm simd types were always translated to `v128` under-the-hood in LLVM, meaning that it didn't matter whether that target feature was enabled or not. Now, however, `v128` is conditionally used in codegen depending on target features enabled, meaning that it's possible to get linker errors about different signatures in code that correctly uses simd types. The fix is the same as for all other platforms, which is to pass the type indirectly.
-
由 Yuki Okushi 提交于
Fix suggestion for removing &mut from &mut macro!(). Fixes #85933 Before: (Note the suggestions.) ``` error[E0308]: mismatched types --> src/main.rs:2:21 | 2 | let _: String = &mut format!(""); | ------ ^^^^^^^^^^^^^^^^ | | | | | expected struct `String`, found `&mut String` | | help: consider removing the borrow: `mut format!("")` | expected due to this error[E0308]: mismatched types --> src/main.rs:3:21 | 3 | let _: String = &mut (format!("")); | ------ ^^^^^^^^^^^^^^^^^^ | | | | | expected struct `String`, found `&mut String` | | help: consider removing the borrow: `mut (format!(""))` | expected due to this ``` After: ``` error[E0308]: mismatched types --> src/main.rs:2:21 | 2 | let _: String = &mut format!(""); | ------ ^^^^^^^^^^^^^^^^ | | | | | expected struct `String`, found `&mut String` | | help: consider removing the borrow: `format!("")` | expected due to this error[E0308]: mismatched types --> src/main.rs:3:21 | 3 | let _: String = &mut (format!("")); | ------ ^^^^^^^^^^^^^^^^^^ | | | | | expected struct `String`, found `&mut String` | | help: consider removing the borrow: `format!("")` | expected due to this ```
-
由 Yuki Okushi 提交于
Warn against boxed DST in `improper_ctypes_definitions` lint Fixes #85714
-
由 Yuki Okushi 提交于
rustdoc: link to stable/beta docs consistently in documentation This is an alternative to https://github.com/rust-lang/rust/pull/84941 which fixes the problem consistently by linking to stable/beta for *all* items, not just for primitives. ## User-facing changes - Intra-doc links to primitives that currently go to rust-lang.org/nightly/std/primitive.x.html will start going to channel that rustdoc was built with. Nightly will continue going to /nightly; Beta will link to /beta; stable compilers will link to /1.52.1 (or whatever version they were built as). - Cross-crate links from std to core currently go to /nightly unconditionally. They will start going to /1.52.0 on stable channels (but remain the same on nightly channels). - Intra-crate links from std to std (or core to core) currently go to the same URL they are hosted at; they will continue to do so. Notably, this is different from everything else because it can preserve the distinction between /stable and /1.52.0 by using relative links. Note that "links" includes both intra-doc links and rustdoc's own automatically generated hyperlinks. ## Implementation changes - Update the testsuite to allow linking to /beta and /1.52.1 in docs - Use an html_root_url for the standard library that's dependent on the channel This avoids linking to nightly docs on stable. - Update rustdoc to use channel-dependent links for primitives from an unknown crate - Set DOC_RUST_LANG_ORG_CHANNEL from bootstrap to ensure it's in sync - Include doc.rust-lang.org in the channel cc Mark-Simulacrum - I know [you were dubious about this in the past](https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/Rustdoc.20unconditionally.20links.20to.20nightly.20libstd.20docs/near/231223124), but I'm not quite sure why? I see this as "just a bugfix", I don't know why rustdoc should unconditionally link to nightly. cc dtolnay who commented in https://github.com/rust-lang/rust/issues/30693: > I would welcome a PR to solve this permanently if anyone has ideas for how. I don't believe we need an RFC. Fixes https://github.com/rust-lang/rust/issues/30693 (note that issue is marked as feature-accepted, although I don't see where it was discussed).
-
由 Yuki Okushi 提交于
Make match in `register_res` easier to read - Don't duplicate DefKind -> ItemType handling; that's a good way to get bugs - Use exhaustive match - Add comments This found that register_res is very wrong in at least one way: if it registers a Res for `Variant`, it should also register one for `Field`. But I don't know whether the one for Variant should be removed or Field added. Maybe someone has ideas? Found while reviewing https://github.com/rust-lang/rust/pull/84176.
-
由 Yuki Okushi 提交于
rustdoc: Remove `PrimitiveType::{to_url_str, as_str}` These can easily be rewritten in terms of `as_sym`, and this avoids bugs where the two get out of sync. I don't expect this to have a perf impact, but I'll start a perf run just in case.
-
由 Yuki Okushi 提交于
Remove unused code from `rustc_data_structures::sync` Found using https://github.com/est31/warnalyzer. Follow-up to https://github.com/rust-lang/rust/pull/83185. r? `@Zoxc` cc `@oli-obk`
-
由 bors 提交于
rustc: Store metadata-in-rlibs in object files This commit updates how rustc compiler metadata is stored in rlibs. Previously metadata was stored as a raw file that has the same format as `--emit metadata`. After this commit, however, the metadata is encoded into a small object file which has one section which is the contents of the metadata. The motivation for this commit is to fix a common case where #83730 arises. The problem is that when rustc crates a `dylib` crate type it needs to include entire rlib files into the dylib, so it passes `--whole-archive` (or the equivalent) to the linker. The problem with this, though, is that the linker will attempt to read all files in the archive. If the metadata file were left as-is (today) then the linker would generate an error saying it can't read the file. The previous solution was to alter the rlib just before linking, creating a new archive in a temporary directory which has the metadata file removed. This problem from before this commit is now removed if the metadata file is stored in an object file that the linker can read. The only caveat we have to take care of is to ensure that the linker never actually includes the contents of the object file into the final output. We apply similar tricks as the `.llvmbc` bytecode sections to do this. This involved changing the metadata loading code a bit, namely updating some of the LLVM C APIs used to use non-deprecated ones and fiddling with the lifetimes a bit to get everything to work out. Otherwise though this isn't intended to be a functional change really, only that metadata is stored differently in archives now. This should end up fixing #83730 because by default dylibs will no longer have their rlib dependencies "altered" meaning that split-debuginfo will continue to have valid paths pointing at the original rlibs. (note that we still "alter" rlibs if LTO is enabled to remove Rust object files and we also "alter" for the #[link(cfg)] feature, but that's rarely used). Closes #83730
-
由 Joshua Nelson 提交于
It's confusing for these to be different, even if some of the methods are unused.
-
由 Joshua Nelson 提交于
Found using https://github.com/est31/warnalyzer.
-
由 Joshua Nelson 提交于
## User-facing changes - Intra-doc links to primitives that currently go to rust-lang.org/nightly/std/primitive.x.html will start going to channel that rustdoc was built with. Nightly will continue going to /nightly; Beta will link to /beta; stable compilers will link to /1.52.1 (or whatever version they were built as). - Cross-crate links from std to core currently go to /nightly unconditionally. They will start going to /1.52.0 on stable channels (but remain the same on nightly channels). - Intra-crate links from std to std (or core to core) currently go to the same URL they are hosted at; they will continue to do so. Notably, this is different from everything else because it can preserve the distinction between /stable and /1.52.0 by using relative links. Note that "links" includes both intra-doc links and rustdoc's own automatically generated hyperlinks. ## Implementation changes - Update the testsuite to allow linking to /beta and /1.52.1 in docs - Use an html_root_url for the standard library that's dependent on the channel This avoids linking to nightly docs on stable. - Update rustdoc to use channel-dependent links for primitives from an unknown crate - Set DOC_RUST_LANG_ORG_CHANNEL from bootstrap to ensure it's in sync - Include doc.rust-lang.org in the channel
-
由 Alex Crichton 提交于
This commit updates how rustc compiler metadata is stored in rlibs. Previously metadata was stored as a raw file that has the same format as `--emit metadata`. After this commit, however, the metadata is encoded into a small object file which has one section which is the contents of the metadata. The motivation for this commit is to fix a common case where #83730 arises. The problem is that when rustc crates a `dylib` crate type it needs to include entire rlib files into the dylib, so it passes `--whole-archive` (or the equivalent) to the linker. The problem with this, though, is that the linker will attempt to read all files in the archive. If the metadata file were left as-is (today) then the linker would generate an error saying it can't read the file. The previous solution was to alter the rlib just before linking, creating a new archive in a temporary directory which has the metadata file removed. This problem from before this commit is now removed if the metadata file is stored in an object file that the linker can read. The only caveat we have to take care of is to ensure that the linker never actually includes the contents of the object file into the final output. We apply similar tricks as the `.llvmbc` bytecode sections to do this. This involved changing the metadata loading code a bit, namely updating some of the LLVM C APIs used to use non-deprecated ones and fiddling with the lifetimes a bit to get everything to work out. Otherwise though this isn't intended to be a functional change really, only that metadata is stored differently in archives now. This should end up fixing #83730 because by default dylibs will no longer have their rlib dependencies "altered" meaning that split-debuginfo will continue to have valid paths pointing at the original rlibs. (note that we still "alter" rlibs if LTO is enabled to remove Rust object files and we also "alter" for the #[link(cfg)] feature, but that's rarely used). Closes #83730
-
由 bors 提交于
Support Android ndk versions `r23-beta3` and up Since android ndk version `r23-beta3`, `libgcc` has been replaced with `libunwind`. This moves the linking of `libgcc`/`libunwind` into the `unwind` crate where we check if the system compiler can find `libunwind` and fall back to `libgcc` if needed.
-
由 Joshua Nelson 提交于
Co-authored-by: NJosh Triplett <josh@joshtriplett.org>
-
- 04 6月, 2021 22 次提交
-
-
由 Tilmann Meyer 提交于
-
由 bors 提交于
Support for force-warns Implements https://github.com/rust-lang/rust/issues/85512. This PR adds a new command line option `force-warns` which will force the provided lints to warn even if they are allowed by some other mechanism such as `#![allow(warnings)]`. Some remaining issues: * https://github.com/rust-lang/rust/issues/85512 mentions that `force-warns` should also be capable of taking lint groups instead of individual lints. This is not implemented. * If a lint has a higher warning level than `warn`, this will cause that lint to warn instead. We probably want to allow the lint to error if it is set to a higher lint and is not allowed somewhere else. * One test is currently ignored because it's not working - when a deny-by-default lint is allowed, it does not currently warn under `force-warns`. I'm not sure why, but I wanted to get this in before the weekend. r? `@nikomatsakis`
-
由 Joshua Nelson 提交于
-
由 bors 提交于
Reland - Report coverage `0` of dead blocks Fixes: #84018 With `-Z instrument-coverage`, coverage reporting of dead blocks (for example, blocks dropped because a conditional branch is dropped, based on const evaluation) is now supported. Note, this PR relands an earlier, reverted PR that failed when compiling generators. The prior issues with generators has been resolved and a new test was added to prevent future regressions. Check out the resulting changes to test coverage of dead blocks in the test coverage reports in this PR. r? `@tmandry` fyi: `@wesleywiser`
-
由 bors 提交于
fix testing Miri with --stage 0 Fixes https://github.com/rust-lang/rust/issues/78778 for Miri. The issue remains open for error_index_generator, which has its own dylib logic: https://github.com/rust-lang/rust/blob/903e369c831d52726a5292f847e384622189d9a0/src/bootstrap/tool.rs#L396-L400 `@jyn514` I could just copy the logic from `add_rustc_lib_path`, but that does not seem great. Any other suggestions? Also I wonder if maybe `prepare_tool_cargo` should already call `add_rustc_lib_path`.
-
由 bors 提交于
Rollup of 8 pull requests Successful merges: - #85717 (Document `From` impls for cow.rs) - #85850 (Remove unused feature gates) - #85888 (Fix typo in internal documentation for `TrustedRandomAccess`) - #85889 (Restoring the `num_def_ids` function in the CStore API ) - #85899 (jsondocck small cleanup) - #85937 (Fix bad suggestions for code from proc_macro) - #85963 (Show `::{{constructor}}` in std::any::type_name().) - #85977 (Fix linkcheck script from getting out of sync.) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
-
由 Yuki Okushi 提交于
Fix linkcheck script from getting out of sync. When there are changes to the linkcheck script, the CI jobs used in the books would download the latest version on master, but run it against nightly. During that 24 hour window, the CI can fail if the script has changes that are incompatible with the last nightly. This fixes it so that it downloads the linkchecker that matches the version of nightly. This also includes a fix to build with release to make it run much faster (I forgot to add this in #85652).
-
由 Yuki Okushi 提交于
Show `::{{constructor}}` in std::any::type_name(). Fix #84666 Before: ``` [src/main.rs:6] type_name::<T>() = "playground::Velocity" [src/main.rs:6] type_name::<T>() = "playground::Velocity" ``` After: ``` [src/main.rs:6] type_name::<T>() = "scratchpad::Velocity::{{constructor}}" [src/main.rs:6] type_name::<T>() = "scratchpad::Velocity" ``` cc ``@scottmcm``
-
由 Yuki Okushi 提交于
Fix bad suggestions for code from proc_macro Fixes #85932 This disables these suggestions for spans from external macros, while keeping them for macros defined locally: Before: ``` 3 | #[hello] | ^^^^^^^^ | | | expected `&mut i32`, found integer | help: consider mutably borrowing here: `&mut #[hello]` ``` After: ``` 3 | #[hello] | ^^^^^^^^ expected `&mut i32`, found integer ``` Unchanged: ``` 26 | macro_rules! bla { () => { x(123); } } | ^^^ | | | expected `&mut i32`, found integer | help: consider mutably borrowing here: `&mut 123` ... 29 | bla!(); | ------- in this macro invocation ```
-
由 Yuki Okushi 提交于
jsondocck small cleanup updated `shlex` (there was some fix https://github.com/comex/rust-shlex/commit/6db4704fcad8393dd6947b1d31720327546a84a2) replaced `lazy_static` with `once_cell` removed `serde` direct dependency (`serde_json` will pull it)
-
由 Yuki Okushi 提交于
Restoring the `num_def_ids` function in the CStore API ## The context I am the maintainer of https://github.com/hacspec/hacspec, an embedded Rust DSL aimed at cryptographic specifications. As it is normal for an embedded DSL, Hacspec's compiler relies on being plugged to the internal API of the Rust compiler, which is unstable and subject to changes. ## The problem The Hacspec compiler features its own typechecker, that performs an additional, more restrictive typechecking pass over the Rust code of a crate. To complete this typechecking, the Hacspec compiler needs to retrieve the signature of functions defined in non-local imported crates. Rather than retrieving these signatures on-demand, the Hacspec compiler pre-populates its typechecking context with all the Hacspec-compatible symbols defined in non-local crates first. This requires having a way to iterate over all the definitions in a non-local crate. I used to do this with `CrateMetadata::all_def_path_hashes_and_def_ids`, but this function was deleted in 908bf5a3. Then, I fellback on `CStore::num_def_ids`, exploiting the fact that all the `DefIds` for a crate have the same `krate_num` and range from `0` to `num_def_ids(krate_num)`. But `num_def_ids` was deleted in b6120bfb. I looked to the `Cstore::item_children_untracked` function to replicate the feature of traversing through all the `DefId` for a crate, using `CRATE_DEF_INDEX` as the root, but this does not work as recursive `Cstore::item_children_untracked` calls do not reach all the symbols I was able to reach using the two previous methods. ## Description of this PR This PR simply restores in the public API of `CStore` the `num_def_ids` function, giving the size of the definition table for a given crate.
-
由 Yuki Okushi 提交于
Fix typo in internal documentation for `TrustedRandomAccess` `next_back` is a method of DoubleEndedIterator, not Iterator.
-
由 Yuki Okushi 提交于
Remove unused feature gates The first commit removes a usage of a feature gate, but I don't expect it to be controversial as the feature gate was only used to workaround a limitation of rust in the past. (closures never being `Clone`) The second commit uses `#[allow_internal_unstable]` to avoid leaking the `trusted_step` feature gate usage from inside the index newtype macro. It didn't work for the `min_specialization` feature gate though. The third commit removes (almost) all feature gates from the compiler that weren't used anyway.
-
由 Yuki Okushi 提交于
Document `From` impls for cow.rs
-
由 David Tolnay 提交于
-
由 bors 提交于
Update Clippy Bi-weekly Clippy update. r? `@Manishearth`
-
由 bors 提交于
Remove unnecessary SpecFromIter impls Unless I’m missing something, these `SpecFromIter<&'a T, …> for Vec<T>` implementations were completely unused.
-
由 marmeladema 提交于
-
由 Taylor Yu 提交于
Skip where-clauses when suggesting using indirection in combination with `?Sized` bounds on type parameters.
-
由 Eric Huss 提交于
-
由 Eric Huss 提交于
-
由 bors 提交于
shrinking the deprecated method span part of https://github.com/rust-lang/rust/issues/85403 r? `@estebank`
-