about summary refs log tree commit diff
path: root/src/test
AgeCommit message (Collapse)AuthorLines
2021-04-13Auto merge of #84153 - Dylan-DPC:rollup-5jiqrwu, r=Dylan-DPCbors-3/+64
Rollup of 6 pull requests Successful merges: - #83438 (Update RELEASES.md) - #83707 (Remove `T: Debug` bound on UnsafeCell Debug impl) - #84084 (Stabilize duration_zero.) - #84121 (Stabilize BTree{Map,Set}::retain) - #84140 (Don't call bump in check_mistyped_turbofish_with_multiple_type_params) - #84141 (Fix typo in error message) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
2021-04-13Rollup merge of #84141 - camelid:fix-typo, r=Dylan-DPCDylan DPC-3/+6
Fix typo in error message Also tweaked the message a bit by - removing the hyphen, because in my opinion the hyphen makes the message a bit harder to read, especially combined with the backticks; - adding the word "be", because I think it's a bit clearer that way.
2021-04-13Rollup merge of #84140 - b-naber:parser_past_eof, r=varkorDylan DPC-0/+58
Don't call bump in check_mistyped_turbofish_with_multiple_type_params Fixes https://github.com/rust-lang/rust/issues/84117
2021-04-13Auto merge of #84099 - tmiasko:asm-only-x86_64, r=Amanieubors-5/+7
Check for asm support in UI tests that require it Add `needs-asm-support` compiletest directive, and use it in asm tests that require asm support without relying on any architecture specific features. Closes #84038.
2021-04-13Auto merge of #84082 - andjo403:stabilize_nonzero_leading_trailing_zeros, ↵bors-1/+32
r=m-ou-se Stabilize nonzero_leading_trailing_zeros Stabilizing nonzero_leading_trailing_zeros and due to this also stabilizing the intrinsic cttz_nonzero FCP finished here: https://github.com/rust-lang/rust/issues/79143#issuecomment-817216153 `@rustbot` modify labels: +T-libs Closes #79143
2021-04-13Check for asm support in UI tests that require itTomasz Miąsko-5/+7
Add `needs-asm-support` compiletest directive, and use it in asm tests that require asm support without relying on any architecture specific features.
2021-04-12Fix typo in error messageCamelid-3/+6
Also tweaked the message a bit by - removing the hyphen, because in my opinion the hyphen makes the message a bit harder to read, especially combined with the backticks; - adding the word "be", because I think it's a bit clearer that way.
2021-04-12add testb-naber-0/+58
2021-04-12Turn old edition lints (anonymous-parameters, keyword-idents) into ↵Manish Goregaokar-77/+84
warn-by-default on 2015
2021-04-12Auto merge of #84068 - Amanieu:fix_lint, r=lcnrbors-12/+15
Add `bad_asm_style` to HardwiredLints This was missed when the lint was added, which prevents the lint from being ignored with `#[allow]`.
2021-04-12Rollup merge of #84101 - jyn514:early-pass, r=ManishearthDylan DPC-1/+14
rustdoc: Move crate loader to collect_intra_doc_links::early This groups the similar code together, and also allows making most of collect_intra_doc_links private again. This builds on https://github.com/rust-lang/rust/pull/84066, but it wouldn't be too hard to base it off master if you want this to land first. Helps with https://github.com/rust-lang/rust/issues/83761. r? manishearth Fixes https://github.com/rust-lang/rust/issues/84046
2021-04-12Rollup merge of #84079 - camelid:improve-bare-urls-test, r=jyn514Dylan DPC-18/+80
Improve test for `rustdoc::bare_urls` lint - Rename `url-improvements` test to `bare-urls` - Run rustfix for `bare-urls` test
2021-04-12Rollup merge of #84014 - estebank:cool-bears-hot-tip, r=varkorDylan DPC-31/+155
Improve trait/impl method discrepancy errors * Use more accurate spans * Clean up some code by removing previous hack * Provide structured suggestions Structured suggestions are particularly useful for cases where arbitrary self types are used, like in custom `Future`s, because the way to write `self: Pin<&mut Self>` is not necessarily self-evident when first encountered.
2021-04-12Rollup merge of #83669 - kwj2104:issue-81508-fix, r=varkorDylan DPC-0/+43
Issue 81508 fix Fix #81508 **Problem**: When variable name is used incorrectly as path, error and warning point to undeclared/unused name, when in fact the name is used, just incorrectly (should be used as a variable, not part of a path). **Summary for fix**: When path resolution errs, diagnostics checks for variables in ```ValueNS``` that have the same name (e.g., variable rather than path named Foo), and adds additional suggestion that user may actually intend to use the variable name rather than a path. The fix does not suppress or otherwise change the *warning* that results. I did not find a straightforward way in the code to modify this, but would love to make changes here as well with any guidance.
2021-04-11stabilize const_cttzAndreas Jonson-1/+32
2021-04-11Allow using `-C force-unwind-tables=no` when `panic=unwind`hyd-dev-11/+65
2021-04-11Add test to allow bad_asm_styleAmanieu d'Antras-12/+15
2021-04-11Auto merge of #82608 - Aaron1011:feature/final-preexp-tts, r=petrochenkovbors-713/+725
Implement token-based handling of attributes during expansion This PR modifies the macro expansion infrastructure to handle attributes in a fully token-based manner. As a result: * Derives macros no longer lose spans when their input is modified by eager cfg-expansion. This is accomplished by performing eager cfg-expansion on the token stream that we pass to the derive proc-macro * Inner attributes now preserve spans in all cases, including when we have multiple inner attributes in a row. This is accomplished through the following changes: * New structs `AttrAnnotatedTokenStream` and `AttrAnnotatedTokenTree` are introduced. These are very similar to a normal `TokenTree`, but they also track the position of attributes and attribute targets within the stream. They are built when we collect tokens during parsing. An `AttrAnnotatedTokenStream` is converted to a regular `TokenStream` when we invoke a macro. * Token capturing and `LazyTokenStream` are modified to work with `AttrAnnotatedTokenStream`. A new `ReplaceRange` type is introduced, which is created during the parsing of a nested AST node to make the 'outer' AST node aware of the attributes and attribute target stored deeper in the token stream. * When we need to perform eager cfg-expansion (either due to `#[derive]` or `#[cfg_eval]`), we tokenize and reparse our target, capturing additional information about the locations of `#[cfg]` and `#[cfg_attr]` attributes at any depth within the target. This is a performance optimization, allowing us to perform less work in the typical case where captured tokens never have eager cfg-expansion run.
2021-04-11Implement token-based handling of attributes during expansionAaron Hill-713/+725
This PR modifies the macro expansion infrastructure to handle attributes in a fully token-based manner. As a result: * Derives macros no longer lose spans when their input is modified by eager cfg-expansion. This is accomplished by performing eager cfg-expansion on the token stream that we pass to the derive proc-macro * Inner attributes now preserve spans in all cases, including when we have multiple inner attributes in a row. This is accomplished through the following changes: * New structs `AttrAnnotatedTokenStream` and `AttrAnnotatedTokenTree` are introduced. These are very similar to a normal `TokenTree`, but they also track the position of attributes and attribute targets within the stream. They are built when we collect tokens during parsing. An `AttrAnnotatedTokenStream` is converted to a regular `TokenStream` when we invoke a macro. * Token capturing and `LazyTokenStream` are modified to work with `AttrAnnotatedTokenStream`. A new `ReplaceRange` type is introduced, which is created during the parsing of a nested AST node to make the 'outer' AST node aware of the attributes and attribute target stored deeper in the token stream. * When we need to perform eager cfg-expansion (either due to `#[derive]` or `#[cfg_eval]`), we tokenize and reparse our target, capturing additional information about the locations of `#[cfg]` and `#[cfg_attr]` attributes at any depth within the target. This is a performance optimization, allowing us to perform less work in the typical case where captured tokens never have eager cfg-expansion run.
2021-04-11Auto merge of #83806 - JohnTitor:issue-51446, r=estebankbors-0/+34
Add a regression test for issue-51446 Closes #51446 r? `@estebank`
2021-04-10Preprocess intra-doc links consistentlyJoshua Nelson-1/+14
Previously, rustdoc would panic on links to external crates if they were surrounded by backticks.
2021-04-10Run rustfix for `bare-urls` testCamelid-18/+80
This will help us ensure that it emits valid suggestions.
2021-04-10Rename `url-improvements` test to `bare-urls`Camelid-18/+18
The lint used to be called `non-autolinks`, and linted more than just bare URLs. Now, it is called `bare-urls` and only lints against bare URLs. So, `bare-urls` is a better name for the test.
2021-04-10Auto merge of #84023 - Aaron1011:derive-invoc-order, r=petrochenkovbors-62/+103
Expand derive invocations in left-to-right order While derives were being collected in left-to-order order, the corresponding `Invocation`s were being pushed in the wrong order.
2021-04-10Expand derive invocations in left-to-right orderAaron Hill-62/+103
While derives were being collected in left-to-order order, the corresponding `Invocation`s were being pushed in the wrong order.
2021-04-10Auto merge of #84016 - Aaron1011:new-preexp-tests, r=petrochenkovbors-66/+1199
Add some proc-macro attribute token handling tests Split out from https://github.com/rust-lang/rust/pull/82608 r? `@petrochenkov`
2021-04-10Add some proc-macro attribute token handling testsAaron Hill-66/+1199
2021-04-10Auto merge of #84024 - estebank:unclosed-brace-use, r=jackh726bors-3/+42
Avoid `;` -> `,` recovery and unclosed `}` recovery from being too verbose Those two recovery attempts have a very bad interaction that causes too unnecessary output. Add a simple gate to avoid interpreting a `;` as a `,` when there are unclosed braces. Fix #83498.
2021-04-09Avoid `;` -> `,` recovery and unclosed `}` recovery from being too verboseEsteban Küber-144/+18
Those two recovery attempts have a very bad interaction that causes too unnecessary output. Add a simple gate to avoid interpreting a `;` as a `,` when there are unclosed braces.
2021-04-09Auto merge of #81942 - the8472:reduce-ui-test-threads, r=Mark-Simulacrumbors-5/+16
reduce threads spawned by ui-tests The test harness already spawns enough tests to keep all cores busy. Individual tests should keep their own threading to a minimum to avoid context switch overhead. When running ui tests with lld enabled this shaves about 10% off that testsuite on my machine. Resolves #81946
2021-04-09Auto merge of #84030 - jyn514:no-blanket-impls, r=GuillaumeGomezbors-9/+9
rustdoc: Don't generate blanket impls when running --show-coverage `get_blanket_impls` is the slowest part of rustdoc, and the coverage pass completely ignores blanket impls. This stops running it at all, and also removes some unnecessary checks in `calculate_doc_coverage` that ignored the impl anyway. We don't currently measure --show-coverage in perf.rlo, but I tested this locally on cargo and it brought the time down from 2.9 to 1.6 seconds. This also adds back a commented-out test; Rustdoc has been able to deal with `impl trait` for almost a year now. r? `@GuillaumeGomez`
2021-04-09Add back missing trait testJoshua Nelson-9/+8
Rustdoc has been able to deal with `impl trait` for almost a year now.
2021-04-09rustdoc: Don't generate blanket impls when running --show-coverageJoshua Nelson-0/+1
get_blanket_impls is the slowest part of rustdoc, and the coverage pass completely ignores blanket impls. This stops running it at all, and also removes some unnecessary checks in `calculate_doc_coverage` that ignored the impl anyway. We don't currently measure --show-coverage in perf.rlo, but I tested this locally on cargo and it brought the time down from 2.9 to 1.6 seconds.
2021-04-09Auto merge of #83956 - estebank:issue-83892, r=varkorbors-0/+36
Use a more appropriate span for `;` suggestion Fix #83892.
2021-04-09reduce threads spawned by ui-testsThe8472-5/+16
the test harness already spawns enough tests for all cores, individual tests should keep their own threading to a minimum to avoid context switch overhead some tests fail with 1 CGU, so explicit compile flags have been added to keep their old behavior
2021-04-08Add unclosed brace in use tree testEsteban Küber-0/+165
2021-04-09Auto merge of #83870 - jackh726:binder-refactor-fix, r=nikomatsakisbors-0/+14
Don't concatenate binders across types Partially addresses #83737 There's actually two issues that I uncovered in #83737. The first is that we are concatenating bound vars across types, i.e. in ``` F: Fn(&()) -> &mut (dyn Future<Output = ()> + Unpin) ``` the bound vars on `Future` get set as `for<anon>` since those are the binders on `Fn(&()`. This is obviously wrong, since we should only concatenate directly nested trait refs. This is solved here by introducing a new `TraitRefBoundary` scope, that we put around the "syntactical" trait refs and basically don't allow concatenation across. Now, this alone *shouldn't* be a super terrible problem. At least not until you consider the other issue, which is a much more elusive and harder to design a "perfect" fix. A repro can be seen in: ``` use core::future::Future; async fn handle<F>(slf: &F) where F: Fn(&()) -> &mut (dyn for<'a> Future<Output = ()> + Unpin), { (slf)(&()).await; } ``` Notice the `for<'a>` around `Future`. Here, `'a` is unused, so the `for<'a>` Binder gets changed to a `for<>` Binder in the generator witness, but the "local decl" still has it. This has heavy intersections with region anonymization and erasing. Luckily, it's not *super* common to find this unique set of circumstances. It only became apparently because of the first issue mentioned here. However, this *is* still a problem, so I'm leaving #83737 open. r? `@nikomatsakis`
2021-04-08Auto merge of #83941 - wesleywiser:win_dbginfo_closures, r=nagisabors-0/+91
Improve debuginfo for closures and async functions on Windows MSVC The issue was that the resulting debuginfo was too complex for LLVM to translate into CodeView records correctly. As a result, it simply ignored the debuginfo which meant Windows debuggers could not display any closed over variables when stepping inside a closure or async fn. This fixes that by creating additional allocas on the stack so that the resulting debuginfo is simple (just `*my_variable.dbg.spill`) and LLVM can generate the correct CV records. I also updated some of our existing tests to run in CDB to cover this case. Before (closure): ![image](https://user-images.githubusercontent.com/831192/113756857-e6dc4200-96df-11eb-8d6d-b7ed7a84aad5.png) After (closure): ![image](https://user-images.githubusercontent.com/831192/113757067-2e62ce00-96e0-11eb-89f7-7dc8ab89b1b8.png) Before (async): ![image](https://user-images.githubusercontent.com/831192/114077916-4e2bfa80-9876-11eb-9f15-e302d1faa652.png) After (async): ![image](https://user-images.githubusercontent.com/831192/114077677-0d33e600-9876-11eb-8ce3-cac20a9ea94a.png) Fixes #83709
2021-04-08Provide verbose suggestion for new output typeEsteban Küber-4/+5
2021-04-08Suggest return typeEsteban Küber-7/+40
2021-04-08Suggest changing impl parameter types to match traitEsteban Küber-18/+108
This is particularly useful for cases where arbitrary self types are used, like in custom `Future`s.
2021-04-08Auto merge of #84008 - Dylan-DPC:rollup-invxvg8, r=Dylan-DPCbors-51/+72
Rollup of 6 pull requests Successful merges: - #80733 (Improve links in inline code in `core::pin`.) - #81764 (Stabilize `rustdoc::bare_urls` lint) - #81938 (Stabilize `peekable_peek_mut`) - #83980 (Fix outdated crate names in compiler docs) - #83992 (Merge idents when generating source content) - #84001 (Update Clippy) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
2021-04-08Rollup merge of #81764 - jyn514:lint-links, r=GuillaumeGomezDylan DPC-51/+72
Stabilize `rustdoc::bare_urls` lint Closes https://github.com/rust-lang/rust/issues/77501. Closes https://github.com/rust-lang/rust/issues/83598.
2021-04-08Fix closed over variables not available in debuginfo for Windows MSVCWesley Wiser-0/+91
The issue was that the resulting debuginfo was too complex for LLVM to translate into CodeView records correctly. As a result, it simply ignored the debuginfo which meant Windows debuggers could not display any closed over variables when stepping inside a closure. This fixes that by spilling additional variables to the stack so that the resulting debuginfo is simple (just `*my_variable.dbg.spill`) and LLVM can generate the correct CV records.
2021-04-08Use more accurate spans for trait/impl method arg divergenceEsteban Küber-16/+16
2021-04-08rustc: Add a new `wasm` ABIAlex Crichton-77/+282
This commit implements the idea of a new ABI for the WebAssembly target, one called `"wasm"`. This ABI is entirely of my own invention and has no current precedent, but I think that the addition of this ABI might help solve a number of issues with the WebAssembly targets. When `wasm32-unknown-unknown` was first added to Rust I naively "implemented an abi" for the target. I then went to write `wasm-bindgen` which accidentally relied on details of this ABI. Turns out the ABI definition didn't match C, which is causing issues for C/Rust interop. Currently the compiler has a "wasm32 bindgen compat" ABI which is the original implementation I added, and it's purely there for, well, `wasm-bindgen`. Another issue with the WebAssembly target is that it's not clear to me when and if the default C ABI will change to account for WebAssembly's multi-value feature (a feature that allows functions to return multiple values). Even if this does happen, though, it seems like the C ABI will be guided based on the performance of WebAssembly code and will likely not match even what the current wasm-bindgen-compat ABI is today. This leaves a hole in Rust's expressivity in binding WebAssembly where given a particular import type, Rust may not be able to import that signature with an updated C ABI for multi-value. To fix these issues I had the idea of a new ABI for WebAssembly, one called `wasm`. The definition of this ABI is "what you write maps straight to wasm". The goal here is that whatever you write down in the parameter list or in the return values goes straight into the function's signature in the WebAssembly file. This special ABI is for intentionally matching the ABI of an imported function from the environment or exporting a function with the right signature. With the addition of a new ABI, this enables rustc to: * Eventually remove the "wasm-bindgen compat hack". Once this ABI is stable wasm-bindgen can switch to using it everywhere. Afterwards the wasm32-unknown-unknown target can have its default ABI updated to match C. * Expose the ability to precisely match an ABI signature for a WebAssembly function, regardless of what the C ABI that clang chooses turns out to be. * Continue to evolve the definition of the default C ABI to match what clang does on all targets, since the purpose of that ABI will be explicitly matching C rather than generating particular function imports/exports. Naturally this is implemented as an unstable feature initially, but it would be nice for this to get stabilized (if it works) in the near-ish future to remove the wasm32-unknown-unknown incompatibility with the C ABI. Doing this, however, requires the feature to be on stable because wasm-bindgen works with stable Rust.
2021-04-08Auto merge of #83866 - jyn514:disambiguator-error, r=camelidbors-0/+12
rustdoc: Link to the docs on namespaces when an unknown disambiguator is found cc https://github.com/rust-lang/rust/issues/83859 `@lopopolo` does this look about like what you expected? r? `@camelid`
2021-04-08Rollup merge of #83952 - estebank:issue-83943, r=petrochenkovDylan DPC-4/+40
Account for `ExprKind::Block` when suggesting .into() and deref Fix #83943.
2021-04-08Rollup merge of #83689 - estebank:cool-bears-hot-tip, r=davidtwcoDylan DPC-128/+672
Add more info for common trait resolution and async/await errors * Suggest `Pin::new`/`Box::new`/`Arc::new`/`Box::pin` in more cases * Point at `impl` and type defs introducing requirements on E0277
2021-04-08Rollup merge of #82497 - jyn514:json, r=CraftSpiderDylan DPC-0/+14
Fix handling of `--output-format json` flag - Don't treat it as deprecated on stable and beta channels. Before, it would give confusing and incorrect output: ``` warning: the 'output-format' flag is considered deprecated | = warning: see issue #44136 <https://github.com/rust-lang/rust/issues/44136> for more information error: json output format isn't supported for doc generation ``` Both of those are wrong: output-format isn't deprecated, and json output is supported. - Require -Z unstable-options for `--output-format json` Previously, it was allowed by default on nightly, which made it hard to realize the flag wouldn't be accepted on beta or stable. To get the test working I had to remove `-Z unstable-options`, which x.py passed to compiletest unconditionally. It was first added in https://github.com/rust-lang/rust/commit/8c2ec689c159e7f021d5913efb991aff875be967 so `-Z miri` would be allowed. -Z miri is no longer passed unconditionally, so hopefully removing it won't break anything. r? ```@aDotInTheVoid``` cc ```@HeroicKatora``` ```@CraftSpider``` Thanks to ```@memoryruins``` for pointing it out on Discord! cc ```@Mark-Simulacrum``` for the change to compiletest.