about summary refs log tree commit diff
path: root/src/test
AgeCommit message (Collapse)AuthorLines
2021-05-25Auto merge of #85273 - LeSeulArtichaut:thir-query, r=nikomatsakisbors-59/+35
Make building THIR a stealable query This PR creates a stealable `thir_body` query so that we can build the THIR only once for THIR unsafeck and MIR build. Blocked on #83842. r? `@nikomatsakis`
2021-05-24Auto merge of #85639 - GuillaumeGomez:rollup-modinsi, r=GuillaumeGomezbors-7/+19
Rollup of 4 pull requests Successful merges: - #85271 (Fix indentation in move keyword documentation) - #85551 (Fix search results display) - #85621 (Restore sans-serif font for module items.) - #85628 (Replace more "NULL" with "null") Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
2021-05-24Rollup merge of #85628 - LeSeulArtichaut:thir-null-lowercase, r=estebankGuillaume Gomez-7/+7
Replace more "NULL" with "null" Error messages in THIR unsafeck still contain "NULL", make them lowercase to be consistent with MIR unsafeck (cc #84842).
2021-05-24Rollup merge of #85551 - GuillaumeGomez:fix-search-result-overflow, r=jshaGuillaume Gomez-0/+12
Fix search results display Fixes https://github.com/rust-lang/rust/issues/85544. cc `@dns2utf8` r? `@jsha`
2021-05-24Auto merge of #85596 - scottmcm:more-on-unimplemented, r=estebankbors-13/+11
Extend `rustc_on_implemented` to improve more `?` error messages `_Self` could match the generic definition; this adds that functionality for matching the generic definition of type parameters too. Your advice welcome on the wording of all these messages, and which things belong in the message/label/note. r? `@estebank`
2021-05-24Replace more "NULL" with "null"LeSeulArtichaut-7/+7
2021-05-24Auto merge of #85515 - jedel1043:fix-85480, r=petrochenkovbors-0/+24
Fix ast pretty printing for anonymous types Fixes #85480.
2021-05-24Add test for pretty printing anonymous typesjedel1043-0/+24
2021-05-23Auto merge of #85554 - 12101111:fix-dedup-native-libs, r=petrochenkovbors-0/+36
native lib: defer the duplicate check after relevant_lib check. https://github.com/rust-lang/rust/pull/84794 break code using conditional-compilation with `#[link]` attributes. ```rust #[cfg(target_env = "musl")] cfg_if::cfg_if! { if #[cfg(any(target_feature = "crt-static", feature = "llvm-libunwind"))] { #[link(name = "unwind", kind = "static", modifiers = "-bundle")] extern "C" {} } else { #[link(name = "unwind", cfg(feature = "system-llvm-libunwind"))] #[link(name = "gcc_s", cfg(not(feature = "system-llvm-libunwind")))] extern "C" {} } } ```
2021-05-23Auto merge of #85479 - Stupremee:render-Self_as-type-casts, r=CraftSpiderbors-0/+17
rustdoc: render `<Self as X>::Y` type casts properly Rustdoc didn't render any `<Self as X>` casts which causes invalid code inside the documentation. This is fixed by this PR by checking if the target type `X` is different from `Self`, and if so, it will render a typecast. Resolves #85454
2021-05-23Extend rustc_on_implemented to improve a ?-on-ControlFlow error messageScott McMurray-13/+11
2021-05-23Rollup merge of #85575 - jsha:fix-toggle-settings, r=GuillaumeGomezDylan DPC-1/+2
Fix auto-hide for implementations and implementors. This sets their toggles to be closed in the HTML (matching the default setting), and opens them if the setting indicates to do so. This distinguishes between implementations and implementors based on being descendants of certain named elements. Demo https://hoffman-andrews.com/rust/fix-toggle-settings/std/io/trait.Read.html#implementors and https://hoffman-andrews.com/rust/fix-toggle-settings/std/string/struct.String.html#trait-implementations Fixes #85411 r? `@GuillaumeGomez`
2021-05-22Auto merge of #85078 - RalfJung:const_fn_unsize, r=oli-obkbors-75/+38
stabilize const_fn_unsize I will post a stabilization report and ask for FCP in https://github.com/rust-lang/rust/issues/64992. This PR is for the implementation side of stabilization. r? `@oli-obk` Fixes https://github.com/rust-lang/rust/issues/64992
2021-05-22Fix auto-hide for implementations and implementors.Jacob Hoffman-Andrews-1/+2
This sets their toggles to be closed in the HTML (matching the default setting), and opens them if the setting indicates to do so. This distinguishes between implementations and implementors based on being descendants of certain named elements.
2021-05-22Add test for search result resize widthGuillaume Gomez-0/+12
2021-05-22Remove some errors in UI testsLeSeulArtichaut-29/+5
As we now need to run THIR unsafeck before MIR build, errors in unsafeck can cause the compilation to be aborted earlier.
2021-05-22Make the THIR unsafeck use the `thir_body` queryLeSeulArtichaut-30/+30
2021-05-22Add test for deduplicate native lib in linking12101111-0/+36
2021-05-22const_fn_unsize: check that the cast behaves correctlyRalf Jung-3/+10
2021-05-22stabilize const_fn_unsizeRalf Jung-75/+31
2021-05-22Auto merge of #85568 - GuillaumeGomez:search-result-extra-info, r=jshabors-0/+15
Search result extra info The CSS rule was not updated when we updated the search result, this fixes it: Before: ![Screenshot from 2021-05-21 22-56-17](https://user-images.githubusercontent.com/3050060/119197314-d31a4e80-ba87-11eb-863a-bc0b3de3bfb2.png) After: ![Screenshot from 2021-05-21 22-54-53](https://user-images.githubusercontent.com/3050060/119197227-b54ce980-ba87-11eb-9f43-c10803ca1b90.png) r? `@jsha`
2021-05-21Add test for search result keyword extra infoGuillaume Gomez-0/+15
2021-05-21Auto merge of #85560 - GuillaumeGomez:rollup-8k90rc7, r=GuillaumeGomezbors-55/+575
Rollup of 4 pull requests Successful merges: - #85506 (Reset "focusedByTab" field when doing another search) - #85548 (Remove dead toggle JS code) - #85550 (facepalm: operator precedence fail on my part.) - #85555 (Check for more things in THIR unsafeck) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
2021-05-21Rollup merge of #85555 - LeSeulArtichaut:thir-unsafeck, r=nikomatsakisGuillaume Gomez-55/+575
Check for more things in THIR unsafeck Reunion of #85306, #85381 and #85419 with conflicts resolved. r? `@nikomatsakis`
2021-05-21Check for use of mutable/extern statics in THIR unsafeckLeSeulArtichaut-20/+226
2021-05-21Auto merge of #85511 - Mark-Simulacrum:eq-not-sup, r=nikomatsakisbors-19/+33
Adjust self-type check to require equality When we encounter `SomeType::<X>::foo`, `self_ty` is `SomeType<X>` and the method is defined in an impl on `SomeType<A>`. Previously, we required simply that `self_ty <: impl_ty`, but this is too lax: we should require equality in order to use the method. This was found as part of unrelated work on never type stabilization, but also fixes one of the wf test cases.
2021-05-21Check for ptr-to-int casts in const functions in THIR unsafeckLeSeulArtichaut-13/+88
2021-05-21Check for initialization of layout-restricted typesLeSeulArtichaut-2/+33
2021-05-21Adjust self-type to require equalityMark Rousskov-19/+33
2021-05-20Rollup merge of #85507 - GuillaumeGomez:extend-escape-key-check, r=jshaGuillaume Gomez-3/+10
Extend escape key check Since #84462 has been merged, we can now extend the `escape-key` test. r? `@jsha`
2021-05-20Rollup merge of #85375 - SkiFire13:fix-85347, r=jackh726Guillaume Gomez-0/+29
Fix missing lifetimes diagnostics after #83759 In #83759 while rebasing I didn't realize there was a new function for suggesting to add lifetime arguments. It relied on some invariants, namely that if a generic type/trait has angle brackets then it must have some generic argument, which is now no longer true. This PR updates that function to handle the new invariants. This also adds a new regression test but I'm not sure if that's the correct place for it. Fixes #85347
2021-05-20Extend escape key checkGuillaume Gomez-3/+10
2021-05-20Rollup merge of #84717 - dtolnay:literalfromstr, r=petrochenkovRalf Jung-0/+80
impl FromStr for proc_macro::Literal Note that unlike `impl FromStr for proc_macro::TokenStream`, this impl does not permit whitespace or comments. The input string must consist of nothing but your literal. - `"1".parse::<Literal>()` ⟶ ok - `"1.0".parse::<Literal>()` ⟶ ok - `"'a'".parse::<Literal>()` ⟶ ok - `"\"\n\"".parse::<Literal>()` ⟶ ok - `"0 1".parse::<Literal>()` ⟶ LexError - `" 0".parse::<Literal>()` ⟶ LexError - `"0 ".parse::<Literal>()` ⟶ LexError - `"/* comment */0".parse::<Literal>()` ⟶ LexError - `"0/* comment */".parse::<Literal>()` ⟶ LexError - `"0// comment".parse::<Literal>()` ⟶ LexError --- ## Use case ```rust let hex_int: Literal = format!("0x{:x}", int).parse().unwrap(); ``` The only way this is expressible in the current API is significantly worse. ```rust let hex_int = match format!("0x{:x}", int) .parse::<TokenStream>() .unwrap() .into_iter() .next() .unwrap() { TokenTree::Literal(literal) => literal, _ => unreachable!(), }; ```
2021-05-20Check for calls to functions with `#[target_feature]` in THIR unsafeckLeSeulArtichaut-11/+120
2021-05-20Check for raw pointer dereference in THIR unsafeckLeSeulArtichaut-9/+108
2021-05-19Add proc macro Literal parse testDavid Tolnay-0/+27
2021-05-19Make a more meaningful test for Punct eqDavid Tolnay-5/+5
2021-05-19Move proc_macro tests to ui testDavid Tolnay-0/+25
2021-05-19Make a ui test to take the role of libproc_macro #[test] testsDavid Tolnay-0/+28
2021-05-19rustdoc: add test for issue-85454Justus K-0/+17
2021-05-19Auto merge of #84876 - alexcrichton:inline-thread-locals-cross-crate, ↵bors-0/+56
r=Mark-Simulacrum std: Attempt again to inline thread-local-init across crates Issue #25088 has been part of `thread_local!` for quite some time now. Historical attempts have been made to add `#[inline]` to `__getit` in #43931, #50252, and #59720, but these attempts ended up not landing at the time due to segfaults on Windows. In the interim though with `const`-initialized thread locals AFAIK this is the only remaining bug which is why you might want to use `#[thread_local]` over `thread_local!`. As a result I figured it was time to resubmit this and see how it fares on CI and if I can help debugging any issues that crop up. Closes #25088
2021-05-19Auto merge of #85276 - Bobo1239:more_dso_local, r=nagisabors-4/+37
Set dso_local for more items Related to https://github.com/rust-lang/rust/pull/83592. (cc `@nagisa)` Noticed that on x86_64 with `relocation-model: static` `R_X86_64_GOTPCREL` relocations were still generated in some cases. (related: https://github.com/Rust-for-Linux/linux/issues/135; Rust-for-Linux needs these fixes to successfully build) First time doing anything with LLVM so not sure whether this is correct but the following are some of the things I've tried to convince myself. ## C equivalent Example from clang which also sets `dso_local` in these cases: `clang-12 -fno-PIC -S -emit-llvm test.c` ```C extern int A; int* a() { return &A; } int B; int* b() { return &B; } ``` ``` ; ModuleID = 'test.c' source_filename = "test.c" target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128" target triple = "x86_64-unknown-linux-gnu" `@A` = external dso_local global i32, align 4 `@B` = dso_local global i32 0, align 4 ; Function Attrs: noinline nounwind optnone uwtable define dso_local i32* `@a()` #0 { ret i32* `@A` } ; Function Attrs: noinline nounwind optnone uwtable define dso_local i32* `@b()` #0 { ret i32* `@B` } attributes #0 = { noinline nounwind optnone uwtable "disable-tail-calls"="false" "frame-pointer"="all" "less-precise-fpmad"="false" "min-legal-vector-width"="0" "no-infs-fp-math"="false" "no-jump-tables"="false" "no-nans-fp-math"="false" "no-signed-zeros-fp-math"="false" "no-trapping-math"="true" "stack-protector-buffer-size"="8" "target-cpu"="x86-64" "target-features"="+cx8,+fxsr,+mmx,+sse,+sse2,+x87" "tune-cpu"="generic" "unsafe-fp-math"="false" "use-soft-float"="false" } !llvm.module.flags = !{!0} !llvm.ident = !{!1} !0 = !{i32 1, !"wchar_size", i32 4} !1 = !{!"clang version 12.0.0 (https://github.com/llvm/llvm-project/ b978a93635b584db380274d7c8963c73989944a1)"} ``` `clang-12 -fno-PIC -c test.c` `objdump test.o -r`: ``` test.o: file format elf64-x86-64 RELOCATION RECORDS FOR [.text]: OFFSET TYPE VALUE 0000000000000006 R_X86_64_64 A 0000000000000016 R_X86_64_64 B RELOCATION RECORDS FOR [.eh_frame]: OFFSET TYPE VALUE 0000000000000020 R_X86_64_PC32 .text 0000000000000040 R_X86_64_PC32 .text+0x0000000000000010 ``` ## Comparison to pre-LLVM 12 output `rustc --emit=obj,llvm-ir --target=x86_64-unknown-none-linuxkernel --crate-type rlib test.rs` ```Rust #![feature(no_core, lang_items)] #![no_core] #[lang="sized"] trait Sized {} #[lang="sync"] trait Sync {} #[lang = "drop_in_place"] pub unsafe fn drop_in_place<T: ?Sized>(_: *mut T) {} impl Sync for i32 {} pub static STATIC: i32 = 32; extern { pub static EXT_STATIC: i32; } pub fn a() -> &'static i32 { &STATIC } pub fn b() -> &'static i32 { unsafe {&EXT_STATIC} } ``` `objdump test.o -r` nightly-2021-02-20 (rustc target is `x86_64-linux-kernel`): ``` RELOCATION RECORDS FOR [.text._ZN4test1a17h1024ba65f3424175E]: OFFSET TYPE VALUE 0000000000000007 R_X86_64_32S _ZN4test6STATIC17h3adc41a83746c9ffE RELOCATION RECORDS FOR [.text._ZN4test1b17h86a6a80c1190ac8dE]: OFFSET TYPE VALUE 0000000000000007 R_X86_64_32S EXT_STATIC ``` nightly-2021-05-10: ``` RELOCATION RECORDS FOR [.text._ZN4test1a17he846f03bf37b2d20E]: OFFSET TYPE VALUE 0000000000000007 R_X86_64_GOTPCREL _ZN4test6STATIC17h5a059515bf3d4968E-0x0000000000000004 RELOCATION RECORDS FOR [.text._ZN4test1b17h7e0f7f80fbd91125E]: OFFSET TYPE VALUE 0000000000000007 R_X86_64_GOTPCREL EXT_STATIC-0x0000000000000004 ``` This PR: ``` RELOCATION RECORDS FOR [.text._ZN4test1a17he846f03bf37b2d20E]: OFFSET TYPE VALUE 0000000000000007 R_X86_64_32S _ZN4test6STATIC17h5a059515bf3d4968E RELOCATION RECORDS FOR [.text._ZN4test1b17h7e0f7f80fbd91125E]: OFFSET TYPE VALUE 0000000000000007 R_X86_64_32S EXT_STATIC ```
2021-05-18Rollup merge of #85438 - GuillaumeGomez:fix-escape-handling, r=jshaJack Huey-0/+27
Fix escape handling Currently, when we press Escape while on the search results, nothing is happening, this PR fixes it. More information: it's because in case the element doesn't exist, `hasClass` will return `null`, which coerces into `false` with the `!` comparison operator. But even if it returned `false`, it would still be an issue because if the element doesn't exist, it means it's hidden so in this case it's just as good, hence the additional check I added. r? ``@jsha``
2021-05-18Rollup merge of #83767 - camelid:mangle-v0-fix, r=nikomatsakisJack Huey-0/+104
Fix v0 symbol mangling bug Fixes #83611. r? ``@jackh726``
2021-05-18Rollup merge of #83366 - jyn514:stabilize-key-value-attrs, r=petrochenkovJack Huey-51/+2
Stabilize extended_key_value_attributes Closes https://github.com/rust-lang/rust/issues/44732. Closes https://github.com/rust-lang/rust/issues/78835. Closes https://github.com/rust-lang/rust/issues/82768 (by making it irrelevant). # Stabilization report ## Summary This stabilizes using macro expansion in key-value attributes, like so: ```rust #[doc = include_str!("my_doc.md")] struct S; #[path = concat!(env!("OUT_DIR"), "/generated.rs")] mod m; ``` See Petrochenkov's excellent blog post [on internals](https://internals.rust-lang.org/t/macro-expansion-points-in-attributes/11455) for alternatives that were considered and rejected ("why accept no more and no less?") This has been available on nightly since 1.50 with no major issues. ## Notes ### Accepted syntax The parser accepts arbitrary Rust expressions in this position, but any expression other than a macro invocation will ultimately lead to an error because it is not expected by the built-in expression forms (e.g., `#[doc]`). Note that decorators and the like may be able to observe other expression forms. ### Expansion ordering Expansion of macro expressions in "inert" attributes occurs after decorators have executed, analogously to macro expressions appearing in the function body or other parts of decorator input. There is currently no way for decorators to accept macros in key-value position if macro expansion must be performed before the decorator executes (if the macro can simply be copied into the output for later expansion, that can work). ## Test cases - https://github.com/rust-lang/rust/blob/master/src/test/ui/attributes/key-value-expansion-on-mac.rs - https://github.com/rust-lang/rust/blob/master/src/test/rustdoc/external-doc.rs The feature has also been dogfooded extensively in the compiler and standard library: - https://github.com/rust-lang/rust/pull/83329 - https://github.com/rust-lang/rust/pull/83230 - https://github.com/rust-lang/rust/pull/82641 - https://github.com/rust-lang/rust/pull/80534 ## Implementation history - Initial proposal: https://github.com/rust-lang/rust/issues/55414#issuecomment-554005412 - Experiment to see how much code it would break: https://github.com/rust-lang/rust/pull/67121 - Preliminary work to restrict expansion that would conflict with this feature: https://github.com/rust-lang/rust/pull/77271 - Initial implementation: https://github.com/rust-lang/rust/pull/78837 - Fix for an ICE: https://github.com/rust-lang/rust/pull/80563 ## Unresolved Questions ~~https://github.com/rust-lang/rust/pull/83366#issuecomment-805180738 listed some concerns, but they have been resolved as of this final report.~~ ## Additional Information There are two workarounds that have a similar effect for `#[doc]` attributes on nightly. One is to emulate this behavior by using a limited version of this feature that was stabilized for historical reasons: ```rust macro_rules! forward_inner_docs { ($e:expr => $i:item) => { #[doc = $e] $i }; } forward_inner_docs!(include_str!("lib.rs") => struct S {}); ``` This also works for other attributes (like `#[path = concat!(...)]`). The other is to use `doc(include)`: ```rust #![feature(external_doc)] #[doc(include = "lib.rs")] struct S {} ``` The first works, but is non-trivial for people to discover, and difficult to read and maintain. The second is a strange special-case for a particular use of the macro. This generalizes it to work for any use case, not just including files. I plan to remove `doc(include)` when this is stabilized (https://github.com/rust-lang/rust/pull/82539). The `forward_inner_docs` workaround will still compile without warnings, but I expect it to be used less once it's no longer necessary.
2021-05-18Auto merge of #84767 - scottmcm:try_trait_actual, r=lcnrbors-610/+832
Implement the new desugaring from `try_trait_v2` ~~Currently blocked on https://github.com/rust-lang/rust/issues/84782, which has a PR in https://github.com/rust-lang/rust/pull/84811~~ Rebased atop that fix. `try_trait_v2` tracking issue: https://github.com/rust-lang/rust/issues/84277 Unfortunately this is already touching a ton of things, so if you have suggestions for good ways to split it up, I'd be happy to hear them. (The combination between the use in the library, the compiler changes, the corresponding diagnostic differences, even MIR tests mean that I don't really have a great plan for it other than trying to have decently-readable commits. r? `@ghost` ~~(This probably shouldn't go in during the last week before the fork anyway.)~~ Fork happened.
2021-05-18No matter how trivial the change, tidy always finds a way to complain...Scott McMurray-6/+6
2021-05-18Mention the issue number for the new mir-opt in the FIXMEs scottmcm-3/+3
Thanks for the suggestions, lcnr! Co-authored-by: lcnr <rust@lcnr.de>
2021-05-18std: Attempt again to inline thread-local-init across cratesAlex Crichton-0/+56
Issue #25088 has been part of `thread_local!` for quite some time now. Historical attempts have been made to add `#[inline]` to `__getit` in #43931, #50252, and #59720, but these attempts ended up not landing at the time due to segfaults on Windows. In the interim though with `const`-initialized thread locals AFAIK this is the only remaining bug which is why you might want to use `#[thread_local]` over `thread_local!`. As a result I figured it was time to resubmit this and see how it fares on CI and if I can help debugging any issues that crop up. Closes #25088
2021-05-18Set dso_local for more itemsBoris-Chengbiao Zhou-0/+33