about summary refs log tree commit diff
path: root/src/test
AgeCommit message (Collapse)AuthorLines
2019-09-22Auto merge of #64669 - estebank:unreachable, r=Centrilbors-331/+185
Use span label instead of note in unreachable lint Fix #64636.
2019-09-21review commentsEsteban Küber-2/+2
2019-09-21Do not trigger unreachable lint in async body and Use span labelsEsteban Küber-331/+185
2019-09-21Rollup merge of #64660 - guanqun:unify-errors-for-tuple-struct, r=estebankMazdak Farrokhzad-5/+37
unify errors for tuple/struct variants fix #63983
2019-09-21Rollup merge of #64635 - gnzlbg:const_fn_ptr, r=oli-obkMazdak Farrokhzad-0/+299
Allow using fn pointers in const fn with unleash miri This allows using function pointers in const fns when `-Zunleash-the-miri-within-you` is enabled. If the call to the `const fn` happens in a `const`-context, the function pointer is required to point to a `const fn`: ```rust fn non_const_fn() -> i32 { 42 } const fn const_fn() -> i32 { 42 } const fn foo(x: fn() -> i32) -> i32 { x() } let x: i32 = foo(non_const_fn_ptr); // OK let y: i32 = foo(const_fn_ptr); // OK const X: i32 = foo(non_const_fn_ptr); // ERROR: `non_const_fn` is not `const fn` const Y: i32 = foo(const_fn_ptr); // OK ``` r? @oli-obk
2019-09-21Rollup merge of #64619 - sam09:fix-63962, r=CentrilMazdak Farrokhzad-4/+19
Fixes #63962. Hint about missing tuple parentheses in patterns
2019-09-21Rollup merge of #63907 - estebank:assoc-type-mismatch, r=oli-obkMazdak Farrokhzad-0/+71
Add explanation to type mismatch involving type params and assoc types CC #63711
2019-09-22Fixes #63962. Hint about missing tuple parentheses in patternsSam Radhakrishan-4/+19
2019-09-21unify errors for tuple/struct variantsGuanqun Lu-5/+37
fix #63983
2019-09-21remove featuregnzlbg-84/+255
2019-09-21Rollup merge of #64642 - cuviper:move-for-loop-snippet, r=varkorMazdak Farrokhzad-0/+24
Fix the span used to suggest avoiding for-loop moves It was using the snippet from the "use" span, which often renders the same, but with closures that snippet is on the start of the closure where the value is captured. We should be using the snippet from the span where it was moved into the `for` loop, which is `move_span`. Fixes #64559.
2019-09-21Rollup merge of #64641 - cuviper:extern-rust-ctypes, r=estebankMazdak Farrokhzad-0/+12
Exempt extern "Rust" from improper_ctypes It should be fine for Rust ABIs to involve any Rust type. Fixes #64593.
2019-09-21Rollup merge of #64347 - GuillaumeGomez:E0312, r=oli-obkMazdak Farrokhzad-2/+17
Add long error explanation for E0312 Part of #61137.
2019-09-21Rollup merge of #64010 - c410-f3r:stabilize-attrs-fn, r=CentrilMazdak Farrokhzad-161/+88
Stabilize `param_attrs` in Rust 1.39.0 # Stabilization proposal I propose that we stabilize `#![feature(param_attrs)]`. Tracking issue: #60406 Version: 1.39 (2019-09-26 => beta, 2019-11-07 => stable). ## What is stabilized It is now possible to add outer attributes like `#[cfg(..)]` on formal parameters of functions, closures, and function pointer types. For example: ```rust fn len( #[cfg(windows)] slice: &[u16], #[cfg(not(windows))] slice: &[u8], ) -> usize { slice.len() } ``` ## What isn't stabilized * Documentation comments like `/// Doc` on parameters. * Code expansion of a user-defined `#[proc_macro_attribute]` macro used on parameters. * Built-in attributes other than `cfg`, `cfg_attr`, `allow`, `warn`, `deny`, and `forbid`. Currently, only the lints `unused_variables` and `unused_mut` have effect and may be controlled on parameters. ## Motivation The chief motivations for stabilizing `param_attrs` include: * Finer conditional compilation with `#[cfg(..)]` and linting control of variables. * Richer macro DSLs created by users. * External tools and compiler internals can take advantage of the additional information that the parameters provide. For more examples, see the [RFC][rfc motivation]. ## Reference guide In the grammar of function and function pointer, the grammar of variadic tails (`...`) and parameters are changed respectively from: ```rust FnParam = { pat:Pat ":" }? ty:Type; VaradicTail = "..."; ``` into: ```rust FnParam = OuterAttr* { pat:Pat ":" }? ty:Type; VaradicTail = OuterAttr* "..."; ``` The grammar of a closure parameter is changed from: ```rust ClosureParam = pat:Pat { ":" ty:Type }?; ``` into: ```rust ClosureParam = OuterAttr* pat:Pat { ":" ty:Type }?; ``` More generally, where there's a list of formal (value) parameters separated or terminated by `,` and delimited by `(` and `)`. Each parameter in that list may optionally be prefixed by `OuterAttr+`. Note that in all cases, `OuterAttr*` applies to the whole parameter and not just the pattern. This distinction matters in pretty printing and in turn for macros. ## History * On 2018-10-15, @Robbepop proposes [RFC 2565][rfc], "Attributes in formal function parameter position". * On 2019-04-30, [RFC 2565][rfc] is merged and the tracking issue is made. * On 2019-06-12, a partial implementation was completed. The implementation was done in [#60669][60669] by @c410-f3r and the PR was reviewed by @petrochenkov and @Centril. * On 2019-07-29, [#61238][61238] was fixed in [#61856][61856]. The issue fixed was that lint attributes on function args had no effect. The PR was written by @c410-f3r and reviewed by @matthewjasper, @petrochenkov, and @oli-obk. * On 2019-08-02, a bug [#63210][63210] was filed wherein the attributes on formal parameters would not be passed to macros. The issue was about forgetting to call the relevant method in `fn print_arg` in the pretty printer. In [#63212][63212], written by @Centril on 2019-08-02 and reviewed by @davidtwco, the issue aforementioned was fixed. * This PR stabilizes `param_attrs`. ## Tests * [On Rust 2018, attributes aren't permitted on function parameters without a pattern in trait definitions.](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2565-param-attrs/param-attrs-2018.rs) * [All attributes that should be allowed. This includes `cfg`, `cfg_attr`, and lints check attributes.](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2565-param-attrs/param-attrs-allowed.rs) * [Built-in attributes, which should be forbidden, e.g., `#[test]`, are.](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2565-param-attrs/param-attrs-builtin-attrs.rs) * [`cfg` and `cfg_attr` are properly evaluated.](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2565-param-attrs/param-attrs-cfg.rs) * [`unused_mut`](https://github.com/rust-lang/rust/blob/46f405ec4d7c6bf16fc2eaafe7541019f1da2996/src/test/ui/rfc-2565-param-attrs/param-attrs-cfg.rs) and [`unused_variables`](https://github.com/rust-lang/rust/blob/master/src/test/ui/lint/lint-unused-variables.rs) are correctly applied to parameter patterns. * [Pretty printing takes formal parameter attributes into account.](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2565-param-attrs/param-attrs-pretty.rs) ## Possible future work * Custom attributes inside function parameters aren't currently supported but it is something being worked on internally. * Since documentation comments are syntactic sugar for `#[doc(...)]`, it is possible to allow literal `/// Foo` comments on function parameters. [rfc motivation]: https://github.com/rust-lang/rfcs/blob/master/text/2565-formal-function-parameter-attributes.md#motivation [rfc]: https://github.com/rust-lang/rfcs/pull/2565 [60669]: https://github.com/rust-lang/rust/pull/60669 [61856]: https://github.com/rust-lang/rust/pull/61856 [63210]: https://github.com/rust-lang/rust/issues/63210 [61238]: https://github.com/rust-lang/rust/issues/61238 [63212]: https://github.com/rust-lang/rust/pull/63212 This report is a collaborative work with @Centril.
2019-09-20Fix the span used to suggest avoiding for-loop movesJosh Stone-0/+24
It was using the snippet from the "use" span, which often renders the same, but with closures that snippet is on the start of the closure where the value is captured. We should be using the snippet from the span where it was moved into the `for` loop, which is `move_span`.
2019-09-20Exempt extern "Rust" from improper_ctypesJosh Stone-0/+12
It should be fine for Rust ABIs to involve any Rust type.
2019-09-20Allow using fn pointers in const fn behind const_fn_ptr gategnzlbg-0/+128
2019-09-20Auto merge of #64584 - nikomatsakis:issue-64477-generator-capture-types, r=eddybbors-24/+111
record fewer adjustment types in generator witnesses, avoid spurious drops in MIR construction Don't record all intermediate adjustment types -- That's way more than is needed, and winds up recording types that will never appear in MIR. Note: I'm like 90% sure that this logic is correct, but this stuff is subtle and can be hard to keep straight. However, the risk of this PR is fairly low -- if we miss types here, I believe the most common outcome is an ICE. This fixes the original issue cited by #64477, but I'm leaving the issue open for now since there may be other cases we can detect and improve in a targeted way. r? @Zoxc
2019-09-20Auto merge of #64498 - estebank:point-at-arg, r=Centrilbors-329/+364
When possible point at argument causing item obligation failure Fix https://github.com/rust-lang/rust/issues/41781, fix https://github.com/rust-lang/rust/issues/42855, fix https://github.com/rust-lang/rust/issues/46658, fix https://github.com/rust-lang/rust/issues/48099, fix https://github.com/rust-lang/rust/issues/63143.
2019-09-19add a mir-opt test that we don't add the spurious dropNiko Matsakis-0/+24
2019-09-19When possible, suggest fn callEsteban Küber-6/+8
2019-09-19Ignore obligations coming from desugared call spansEsteban Küber-276/+180
2019-09-19When possible point at argument causing item obligation failureEsteban Küber-504/+633
2019-09-19fix mir-opt testsNiko Matsakis-24/+17
2019-09-19fix tests for 2018Niko Matsakis-0/+4
2019-09-19Rollup merge of #64601 - grovesNL:two-backticks, r=jonas-schievinkMazdak Farrokhzad-1/+1
Fix backticks in documentation Fix a few typos in comments/documentation where backticks were doubled-up on one side.
2019-09-19Rollup merge of #64592 - Aaron1011:feature/unreachable-span, r=CentrilMazdak Farrokhzad-0/+308
Point at original span when emitting unreachable lint Fixes #64590 When we emit an 'unreachable' lint, we now add a note pointing at the expression that actually causes the code to be unreachable (e.g. `return`, `break`, `panic`). This is especially useful when macros are involved, since a diverging expression might be hidden inside of a macro invocation.
2019-09-19Rollup merge of #63448 - RalfJung:miri-discriminant, r=eddybMazdak Farrokhzad-0/+182
fix Miri discriminant handling This can be reviewed commit-by-commit fairly well. The Miri side is at https://github.com/rust-lang/miri/pull/903. Fixes https://github.com/rust-lang/rust/issues/62138 r? @eddyb @oli-obk
2019-09-19avoid generating drops for moved operands of callsNiko Matsakis-0/+46
Currently, after a CALL terminator is created in MIR, we insert DROP statements for all of its operands -- even though they were just moved shortly before! These spurious drops are later removed, but not before causing borrow check errors. This PR series modifies the drop code to track operands that were moved and avoid creating drops for them. Right now, I'm only using this mechanism for calls, but it seems likely it could be used in more places.
2019-09-18Fix backticks in documentationJoshua Groves-1/+1
2019-09-19Rollup merge of #64591 - jamesmunns:grammar-fix, r=jonas-schievinkMazdak Farrokhzad-15/+15
Fix a minor grammar nit, update UI tests Minor fix, but I noticed it while debugging some code
2019-09-19Rollup merge of #64554 - lqd:polonius_tests4, r=nikomatsakisMazdak Farrokhzad-4/+42
Polonius: more `ui` test suite fixes Since #62736, new tests have been added, and the `run-pass` suite was merged into the `ui` suite. This PR adds the missing tests expectations for Polonius, and updates the existing ones where the NLL output has changed in some manner (e.g. ordering of notes) Those are the trivial cases, but a more-detailed explanation is available [in this write-up](https://hackmd.io/CjYB0fs4Q9CweyeTdKWyEg?both#26-async-awaitasync-borrowck-escaping-closure-errorrs-outputs-from-NLL-Polonius-diff) starting at test case 26: they are only differing in diagnostics and instances of other existing test cases differences. Only 3 of the 9020 tests are still "failing" at the moment (1 failure, 2 OOMs). r? @nikomatsakis
2019-09-18Add explanation to type mismatch involving type params and assoc typesEsteban Küber-0/+71
2019-09-18Some formatting cleanupAaron Hill-1/+1
2019-09-18Make note better when all arms in a `match` divergeAaron Hill-6/+6
2019-09-19Restore whitespaceJames Munns-3/+3
2019-09-18Point at original span when emitting unreachable lintAaron Hill-0/+308
Fixes #64590 When we emit an 'unreachable' lint, we now add a note pointing at the expression that actually causes the code to be unreachable (e.g. `return`, `break`, `panic`). This is especially useful when macros are involved, since a diverging expression might be hidden inside of a macro invocation.
2019-09-19Fix a minor grammar nit, update UI testsJames Munns-18/+18
2019-09-18don't record all intermediate adjustment typesNiko Matsakis-0/+20
That's way more than is needed, and winds up recording types that will never appear in MIR.
2019-09-18Rollup merge of #64578 - max-sixty:22656-lldb-8, r=alexcrichtonTyler Mandry-1/+1
Fix issue22656 with LLDB 8 Closes https://github.com/rust-lang/rust/issues/64074
2019-09-18fix debuginfo/issue22656 with LLDB 8Maximilian Roos-1/+1
2019-09-17Rollup merge of #64528 - Aaron1011:fix/proc-macro-type, r=alexcrichtonTyler Mandry-1/+12
Load proc macro metadata in the correct order. Serialized proc macro metadata is assumed to have a one-to-one correspondence with the entries in static array generated by proc_macro_harness. However, we were previously serializing proc macro metadata in a different order than proc macros were laied out in the static array. This lead to us associating the wrong data with a proc macro when generating documentation, causing Rustdoc to generate incorrect docs for proc macros. This commit keeps track of the order in which we insert proc macros into the generated static array. We use this same order when serializing proc macro metadata, ensuring that we can later associate the metadata for a proc macro with its entry in the static array. Fixes #64251
2019-09-17Rollup merge of #64486 - matthewjasper:hygiene-debugging, r=petrochenkovTyler Mandry-1/+11
Print out more information for `-Zunpretty=expanded,hygiene` I've found this helpful when trying to understand how hygiene works. Closes #16420
2019-09-17Generate proc macro harness in AST order.Aaron Hill-1/+12
This ensures that we match the order used by proc macro metadata serialization. Fixes #64251
2019-09-17Auto merge of #64562 - tmandry:rollup-kfk0nuo, r=tmandrybors-30/+7
Rollup of 10 pull requests Successful merges: - #61626 (Get rid of special const intrinsic query in favour of `const_eval`) - #64283 (Updated RELEASES.md for 1.38.0) - #64394 (Shrink `SubregionOrigin`.) - #64429 (Fix failure note `to_str` implementation) - #64436 (improve Vec example soundness in mem::transmute docs) - #64502 (avoid duplicate issues for Miri build failures) - #64505 (Fix inconsistent link formatting) - #64529 (Add an example to Pin::as_mut) - #64541 (document Miri error categories) - #64544 (build-manifest: re-add some comments) Failed merges: r? @ghost
2019-09-17Rollup merge of #64429 - afnanenayet:afnan/fix-failure-note-json-level, ↵Tyler Mandry-2/+2
r=Mark-Simulacrum Fix failure note `to_str` implementation Serialize the level to something a little more useful for a failure note struct. This fixes #60425.
2019-09-17Print syntax contexts and marks when printing hygiene informationMatthew Jasper-0/+10
2019-09-17Auto merge of #64525 - nikomatsakis:issue-64512-drop-order-tail-temp, ↵bors-0/+109
r=davidtwco adjust desugaring for async fn to correct drop order Old desugaring, given a user function body `{ $stmts; $expr }` ``` { let $param_pattern0 = $raw_param0; ... let $param_patternN = $raw_paramN; $stmts; $expr } ``` New desugaring: ``` { let $param_pattern0 = $raw_param0; ... let $param_patternN = $raw_paramN; drop-temps { $stmts; $expr } } ``` The drop-temps is an internal bit of HIR that drops temporaries from the resulting expression, but it should be equivalent to `return { $stmts; $expr }`. Fixes #64512 Fixes #64391
2019-09-17Bless json output of test ui/json-options.rs for Poloniuslqd-0/+1
2019-09-17Bless json output of test ui/json-multiple.rs for Poloniuslqd-0/+1