about summary refs log tree commit diff
path: root/src
AgeCommit message (Collapse)AuthorLines
2021-06-05Auto merge of #85919 - workingjubilee:simd-ptrs-are-valid, r=petrochenkovbors-0/+122
Allow raw pointers in SIMD types Closes #85915 by loosening the strictness in typechecking and adding a test to guarantee it passes. This still might be too strict, as references currently do pass monomorphization, but my understanding is that they are not guaranteed to be "scalar" in the same way.
2021-06-05Auto merge of #85457 - jyn514:remove-doc-include, r=GuillaumeGomezbors-285/+41
Remove `doc(include)` This nightly feature is redundant now that `extended_key_value_attributes` is stable (https://github.com/rust-lang/rust/pull/83366). `@rust-lang/rustdoc` not sure if you think this needs FCP; there was already an FCP in #82539, but technically it was for deprecating, not removing the feature altogether. This should not be merged before #83366. cc `@petrochenkov`
2021-06-05Rollup merge of #85988 - jyn514:ninja-error, r=joshtriplettYuki Okushi-1/+1
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`
2021-06-05Rollup merge of #85979 - tlyu:where-no-unsized-indirection, r=estebankYuki Okushi-0/+29
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.
2021-06-05Rollup merge of #85966 - alexcrichton:wasm-simd-indirect, r=workingjubileeYuki Okushi-0/+33
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.
2021-06-05Rollup merge of #85939 - m-ou-se:fix-remove-ref-macro-invocation, r=estebankYuki Okushi-1/+25
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 ```
2021-06-05Rollup merge of #85853 - marmeladema:improper-ctypes-definitions-boxed-dst, ↵Yuki Okushi-20/+55
r=petrochenkov Warn against boxed DST in `improper_ctypes_definitions` lint Fixes #85714
2021-06-05Rollup merge of #84942 - jyn514:channel-replace, r=ManishearthYuki Okushi-102/+135
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).
2021-06-05Rollup merge of #84880 - jyn514:cleanup-itemkind, r=GuillaumeGomezYuki Okushi-20/+37
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.
2021-06-05Rollup merge of #84466 - jyn514:prim-str, r=GuillaumeGomezYuki Okushi-45/+10
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.
2021-06-04rustdoc: link to stable/beta docs consistently in documentationJoshua Nelson-102/+135
## 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
2021-06-04Improve error messageJoshua Nelson-1/+1
Co-authored-by: Josh Triplett <josh@joshtriplett.org>
2021-06-04Auto merge of #85788 - rylev:force-warns, r=nikomatsakisbors-1/+229
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`
2021-06-04Note that `ninja = false` goes under `[llvm]`Joshua Nelson-1/+1
2021-06-04Remove `doc(include)`Joshua Nelson-285/+41
2021-06-04Auto merge of #85385 - richkadel:simpler-simplify-with-coverage, r=wesleywiserbors-49/+116
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`
2021-06-04Auto merge of #85959 - RalfJung:miri-stage-0, r=Mark-Simulacrumbors-3/+12
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`.
2021-06-04Auto merge of #85984 - JohnTitor:rollup-rq0g9ph, r=JohnTitorbors-14/+94
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
2021-06-04Rollup merge of #85977 - ehuss:linkcheck-nightly, r=Mark-SimulacrumYuki Okushi-5/+5
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).
2021-06-04Rollup merge of #85937 - m-ou-se:macro-ref-suggestions, r=estebankYuki Okushi-0/+81
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 ```
2021-06-04Rollup merge of #85899 - klensy:jsondocck-f, r=Mark-SimulacrumYuki Okushi-9/+8
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)
2021-06-04Auto merge of #85954 - flip1995:clippyup, r=Manishearthbors-1305/+2367
Update Clippy Bi-weekly Clippy update. r? `@Manishearth`
2021-06-03Warn against boxed DST in `improper_ctypes_definitions` lintmarmeladema-20/+55
2021-06-03don't suggest unsized indirection in where-clausesTaylor Yu-0/+29
Skip where-clauses when suggesting using indirection in combination with `?Sized` bounds on type parameters.
2021-06-03Build linkcheck script as release to run faster.Eric Huss-1/+1
2021-06-03Fix linkcheck script from getting out of sync.Eric Huss-4/+4
2021-06-03Auto merge of #85617 - hi-rustin:rustin-patch-fix, r=estebankbors-130/+158
shrinking the deprecated method span part of https://github.com/rust-lang/rust/issues/85403 r? `@estebank`
2021-06-03wasm: Make simd types passed via indirection againAlex Crichton-0/+33
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.
2021-06-03Auto merge of #85292 - wesleywiser:enum_debuginfo, r=michaelwoeristerbors-36/+170
Improve debugging experience for enums on windows-msvc This PR makes significant improvements over the status quo of debugging enums on the windows-msvc platform with either WinDbg or Visual Studio in three ways: 1. Improves the debugger experience for directly tagged enums. 2. Fixes a bug which caused the debugger to sometimes show the wrong debug info for niche layout enums. For example, `Option<&u32>` could sometimes use the debug info for `Option<&f64>` instead leading to nonsensical variable values in the debugger. 3. Significantly improves the debugger experience for niche-layout enums. Let's look at a few examples: ```rust pub enum CStyleEnum { Base = 2, Exponent = 16, } pub enum NicheLayoutEnum { Tag1, Data { my_data: CStyleEnum }, Tag2, Tag3, Tag4, } pub enum OtherEnum<T> { Case1(T), Case2(T), } fn main() { let a = Some(CStyleEnum::Base); let b = Option::<CStyleEnum>::None; let c = NicheLayoutEnum::Tag1; let d = NicheLayoutEnum::Data { my_data: CStyleEnum::Exponent }; let e = NicheLayoutEnum::Tag2; let f = Some(&1u32); let g = Option::<&'static u32>::None; let h = Some(&2u64); let i = Option::<&'static u64>::None; let j = Some(12u32); let k = Option::<u32>::None; let l = Some(12.34f64); let m = Option::<f64>::None; let n = CStyleEnum::Base; let o = CStyleEnum::Exponent; let p = Some("IAMA optional string!".to_string()); let q = OtherEnum::Case1(42u32); } ``` This is what WinDbg Preview shows using the latest rustc nightly: ![image](https://user-images.githubusercontent.com/831192/118285353-57c10780-b49f-11eb-97aa-db3abfc09508.png) Most of the variables don't show a meaningful value expect for a few cases that we have targeted natvis definitions covering. Even worse, drilling into many of these variables shows information that can be difficult to interpret without an understanding of the layout of Rust types: ![image](https://user-images.githubusercontent.com/831192/118285609-a1a9ed80-b49f-11eb-9c29-b14576984647.png) With the changes in this PR, we're able to write two natvis definitions that cover all enum cases generally. After building with these changes, WinDbg now shows this instead: ![image](https://user-images.githubusercontent.com/831192/118287730-be472500-b4a1-11eb-8cad-8f6a91c7516b.png) Drilling into the same variables, we can see much more useful information: ![image](https://user-images.githubusercontent.com/831192/118287888-e20a6b00-b4a1-11eb-927f-32cf33a31c16.png) Fixes #84670 Fixes #84671
2021-06-03Auto merge of #85958 - hyd-dev:miri, r=RalfJungbors-7/+11
Update Miri Fixes #85946. r? `@RalfJung`
2021-06-03fix testing Miri with --stage 0Ralf Jung-3/+12
2021-06-03Update Mirihyd-dev-7/+11
2021-06-03Update tests with new casingRyan Levick-9/+9
2021-06-03Add run-make test testing flag stabilityRyan Levick-1/+4
2021-06-03Auto merge of #85952 - JohnTitor:rollup-r00gu9q, r=JohnTitorbors-0/+102
Rollup of 13 pull requests Successful merges: - #83362 (Stabilize `vecdeque_binary_search`) - #85706 (Turn off frame pointer elimination on all Apple platforms. ) - #85724 (Fix issue 85435 by restricting Fake Read precision) - #85852 (Clarify meaning of MachineApplicable suggestions.) - #85877 (Intra doc link-ify a reference to a function) - #85880 (convert assertion on rvalue::threadlocalref to delay bug) - #85896 (Add test for forward declared const param defaults) - #85897 (Update I-unsound label for triagebot) - #85900 (Use pattern matching instead of checking lengths explicitly) - #85911 (Avoid a clone of output_filenames.) - #85926 (Update cargo) - #85934 (Add `Ty::is_union` predicate) - #85935 (Validate type of locals used as indices) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
2021-06-03Merge commit '3ae8faff4d46ad92f194c2a4b941c3152a701b31' into clippyupflip1995-1305/+2367
2021-06-03Rollup merge of #85926 - ehuss:update-cargo, r=ehussYuki Okushi-0/+0
Update cargo 10 commits in e931e4796b61de593aa1097649445e535c9c7ee0..0cecbd67323ca14a7eb6505900d0d7307b00355b 2021-05-24 16:17:27 +0000 to 2021-06-01 20:09:13 +0000 - Configure hosts separately from targets when --target is specified. (rust-lang/cargo#9322) - Add some validation to rustc-link-arg (rust-lang/cargo#9523) - Implement suggestions for unknown features in workspace (rust-lang/cargo#9420) - Extract common `make_dep_path` to cargo_util (rust-lang/cargo#9529) - Add a note about rustflags compatibility. (rust-lang/cargo#9524) - Consolidate doc collision detection. (rust-lang/cargo#9526) - Add `--depth` option for `cargo-tree` (rust-lang/cargo#9499) - `cargo tree -e no-proc-macro` to hide procedural macro dependencies (rust-lang/cargo#9488) - Update to semver 1.0.0 (rust-lang/cargo#9508) - Update tar dependency to 0.4.35 (rust-lang/cargo#9517)
2021-06-03Rollup merge of #85896 - BoxyUwU:remove-fixme-fwd-declared-const-default, ↵Yuki Okushi-0/+42
r=petrochenkov Add test for forward declared const param defaults
2021-06-03Rollup merge of #85880 - csmoe:ice-85768, r=oli-obkYuki Okushi-0/+60
convert assertion on rvalue::threadlocalref to delay bug Closes #85768 r? ``@oli-obk``
2021-06-03Auto merge of #84988 - alexcrichton:safe-target-feature-wasm, r=joshtriplettbors-0/+44
rustc: Allow safe #[target_feature] on wasm This commit updates the compiler's handling of the `#[target_feature]` attribute when applied to functions on WebAssembly-based targets. The compiler in general requires that any functions with `#[target_feature]` are marked as `unsafe` as well, but this commit relaxes the restriction for WebAssembly targets where the attribute can be applied to safe functions as well. The reason this is done is that the motivation for this feature of the compiler is not applicable for WebAssembly targets. In general the `#[target_feature]` attribute is used to enhance target CPU features enabled beyond the basic level for the rest of the compilation. If done improperly this means that your program could execute an instruction that the CPU you happen to be running on does not understand. This is considered undefined behavior where it is unknown what will happen (e.g. it's not a deterministic `SIGILL`). For WebAssembly, however, the target is different. It is not possible for a running WebAssembly program to execute an instruction that the engine does not understand. If this were the case then the program would not have validated in the first place and would not run at all. Even if this were allowed in some hypothetical future where engines have some form of runtime feature detection (which they do not right now) any implementation of such a feature would generate a trap if a module attempts to execute an instruction the module does not understand. This deterministic trap behavior would still not fall into the category of undefined behavior because the trap is deterministic. For these reasons the `#[target_feature]` attribute is now allowed on safe functions, but only for WebAssembly targets. This notably enables the wasm-SIMD intrinsics proposed for stabilization in #74372 to be marked as safe generally instead of today where they're all `unsafe` due to the historical implementation of `#[target_feature]` in the compiler.
2021-06-03Auto merge of #84834 - GuillaumeGomez:sidebar-unification, r=jshabors-99/+173
Sidebar unification This PR does a few things: * Put crates list at all levels (before, it was only on the "top" items) * Fix bug in module sidebar: the list of items was from the parent module. The other changes (on bootstrap mostly) were to allow to generate multiple crates in a same folder so that we can ensure that clicking on the crates in the sidebar works as expected. I added a rustdoc-gui test to ensure everything is where it should be. r? `@jyn514`
2021-06-02Auto merge of #84703 - GuillaumeGomez:cleanup-dom, r=jshabors-241/+256
Clean up dom The commits come from #84480. They were errors reported by the `tidy` script that we will use to ensure that the HTML generated by rustdoc is valid. I checked carefully that there were no difference so in principle it should be exactly the same rendering but a double-check would be very appreciated in case I missed something. Extra note: `<h4>` and some `<h3>` tags were replaced by `<div>` because they're not supposed to contain tags as they currently do. r? `@jsha`
2021-06-02test for more SIMD monomorphization errorsJacob Lifshay-0/+55
build-fail test for simd type with an element type that's a wide pointer test for SIMD element type of optional nonnull ptr to extern type test that wide ptr simd element type of *mut [u8] fails
2021-06-02Update generator testsWesley Wiser-16/+16
2021-06-02Replace h3 for notable traits with divGuillaume Gomez-15/+23
2021-06-02Update rustdoc testsGuillaume Gomez-94/+100
2021-06-02Remove data-level selectors from CSS.Jacob Hoffman-Andrews-82/+20
2021-06-02Add test for removing &mut for &mut format!().Mara Bos-1/+25
2021-06-02Add test for ref suggestions in macros.Mara Bos-0/+81
2021-06-02Restrict access to crate_name.Camille GILLOT-2/+3
Also remove original_crate_name, which had the exact same implementation