about summary refs log tree commit diff
path: root/src/test/ui/async-await
AgeCommit message (Collapse)AuthorLines
2021-07-24Rollup merge of #87322 - chazkiker2:fix/suggestion-ref-sync-send, r=estebankYuki Okushi-0/+48
fix: clarify suggestion that `&T` must refer to `T: Sync` for `&T: Send` ### Description - [x] fix #86507 - [x] add UI test for relevant code from issue - [x] change `rustc_trait_selection/src/traits/error_reporting/suggestions.rs` to include a more clear suggestion when `&T` fails to satisfy `Send` bounds due to the fact that `T` fails to implement `Sync` - [x] update UI test in Clippy: `src/tools/tests/ui/future_not_send.stderr`
2021-07-22Squash all commits.chaz-kiker-0/+48
add test for issue 86507 add stderr for issue 86507 update issue-86507 UI test add comment for the expected error in UI test file add proper 'refers to <ref_type>' in suggestion update diagnostic phrasing; update test to match new phrasing; re-organize logic for checking T: Sync evaluate additional obligation to figure out if T is Sync run './x.py test tidy --bless' incorporate changes from review; reorganize logic for readability
2021-07-22bless nll testsOli Scherer-10/+6
2021-07-20Auto merge of #87244 - jackh726:issue-71883, r=estebankbors-0/+2
Better diagnostics with mismatched types due to implicit static lifetime Fixes #78113 I think this is my first diagnostics PR...definitely happy to hear thoughts on the direction/implementation here. I was originally just trying to solve the error above, where the lifetime on a GAT was causing a cryptic "mismatched types" error. But as I was writing this, I realized that this (unintentionally) also applied to a different case: `wf-in-foreign-fn-decls-issue-80468.rs`. I'm not sure if this diagnostic should get a new error code, or even reuse an existing one. And, there might be some ways to make this even more generalized. Also, the error is a bit more lengthy and verbose than probably needed. So thoughts there are welcome too. This PR essentially ended up adding a new nice region error pass that triggers if a type doesn't match the self type of an impl which is selected because of a predicate because of an implicit static bound on that self type. r? `@estebank`
2021-07-19Better errors when we don't have implicit statics in trait objectsjackh726-0/+2
2021-07-19Various diagnostics clean ups/tweaksEsteban Küber-10/+50
* Always point at macros, including derive macros * Point at non-local items that introduce a trait requirement * On private associated item, point at definition
2021-07-06Add flag to configure `large_assignments` lintTomasz Miąsko-5/+45
The `large_assignments` lints detects moves over specified limit. The limit is configured through `move_size_limit = "N"` attribute placed at the root of a crate. When attribute is absent, the lint is disabled. Make it possible to enable the lint without making any changes to the source code, through a new flag `-Zmove-size-limit=N`. For example, to detect moves exceeding 1023 bytes in a cargo crate, including all dependencies one could use: ``` $ env RUSTFLAGS=-Zmove-size-limit=1024 cargo build -vv ```
2021-07-04allow inference vars in type_implements_traitNiko Matsakis-1/+35
2021-07-03add test caseNiko Matsakis-0/+10
2021-06-25Address PR feedbackRyan Levick-38/+38
2021-06-25Change how edition based future compatibility warnings are handledRyan Levick-38/+38
2021-06-12Pretty print generator witness only in `-Zverbose` modeTomasz Miąsko-6/+6
In release build of deeply-nested-async benchmark the size of `no-opt.bc` file is reduced from 46MB to 62kB.
2021-05-27Test THIR unsafeck for unsafe ops in closuresLeSeulArtichaut-1/+2
2021-05-26bless compare-mode=nll outputNiko Matsakis-1/+1
2021-05-26stabilize member constraintsNiko Matsakis-70/+4
2021-05-22Remove some errors in UI testsLeSeulArtichaut-19/+3
As we now need to run THIR unsafeck before MIR build, errors in unsafeck can cause the compilation to be aborted earlier.
2021-05-18Auto merge of #84767 - scottmcm:try_trait_actual, r=lcnrbors-19/+19
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-16Suppress spurious errors inside `async fn`Aaron Hill-0/+25
Fixes #73741
2021-05-13Auto merge of #83129 - LeSeulArtichaut:thir-unsafeck, r=nikomatsakisbors-4/+41
Introduce the beginning of a THIR unsafety checker This poses the foundations for the THIR unsafety checker, so that it can be implemented incrementally: - implements a rudimentary `Visitor` for the THIR (which will definitely need some tweaking in the future) - introduces a new `-Zthir-unsafeck` flag which tells the compiler to use THIR unsafeck instead of MIR unsafeck - implements detection of unsafe functions - adds revisions to the UI tests to test THIR unsafeck alongside MIR unsafeck This uses a very simple query design, where bodies are unsafety-checked on a body per body basis. This however has some big flaws: - the unsafety-checker builds the THIR itself, which means a lot of work is duplicated with MIR building constructing its own copy of the THIR - unsafety-checking closures is currently completely wrong: closures should take into account the "safety context" in which they are created, here we are considering that closures are always a safe context I had intended to fix these problems in follow-up PRs since they are always gated under the `-Zthir-unsafeck` flag (which is explicitely noted to be unsound). r? `@nikomatsakis` cc https://github.com/rust-lang/project-thir-unsafeck/issues/3 https://github.com/rust-lang/project-thir-unsafeck/issues/7
2021-05-12Show macro name in 'this error originates in macro' messageAaron Hill-1/+1
When there are multiple macros in use, it can be difficult to tell which one was responsible for producing an error.
2021-05-11Test `-Zthir-unsafeck` for unsafe function callsLeSeulArtichaut-4/+41
2021-05-11improve diagnosts for GATsb-naber-6/+6
2021-05-06Better rustc_on_unimplemented, and UI test fixesScott McMurray-19/+19
2021-05-01Closure capture borrow diagnostics for disjoint capturesChris Pardy-3/+3
2021-04-29Implement RFC 1260 with feature_name `imported_main`.Charles Lew-12/+2
2021-04-20Limit test to 64 bit systems to keep the sizes in the diagnostics stableOli Scherer-4/+5
2021-04-20TidyOli Scherer-1/+1
2021-04-20Add an attribute to be able to configure the limitOli Scherer-4/+6
2021-04-20Implement a lint that highlights all moves larger than 1000 bytesOli Scherer-0/+59
2021-04-19Rollup merge of #84168 - cjgillot:asi, r=davidtwcoDylan DPC-1/+21
Lower async fn in traits. An error is already created by AST validation. Fixes #84149
2021-04-15Add test.Camille GILLOT-1/+21
2021-04-12Compiler error messages: reduce assertiveness of message E0384James Addison-1/+1
This message is emitted as guidance by the compiler when a developer attempts to reassign a value to an immutable variable. Following the message will always currently work, but it may not always be the best course of action; following the 'consider ...' messaging pattern provides a hint to the developer that it could be wise to explore other alternatives.
2021-04-08Rollup merge of #83689 - estebank:cool-bears-hot-tip, r=davidtwcoDylan DPC-1/+70
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-06Always mention `Box::pin` when dealing with `!Unpin`Esteban Küber-0/+1
2021-04-06Point at `impl` and type defs introducing requirements on E0277Esteban Küber-1/+69
2021-04-06Remove trailing `:` from E0119 messageEsteban Küber-1/+1
2021-04-03Remove redundant `ignore-tidy-linelength` annotationsSimon Jakobi-2/+1
This is step 2 towards fixing #77548. In the codegen and codegen-units test suites, the `//` comment markers were kept in order not to affect any source locations. This is because these tests cannot be automatically `--bless`ed.
2021-04-02Rollup merge of #83673 - hi-rustin:rustin-patch-suggestion, r=estebankDylan DPC-2/+2
give full path of constraint in suggest_constraining_type_param close https://github.com/rust-lang/rust/issues/83513
2021-03-31give full path of constraint in suggest_constraining_type_paramhi-rustin-2/+2
revert file bless with nll mode
2021-03-30Fix tests.Camille GILLOT-1/+1
Avoid invoking queries inside `check_paths`, since we are holding a lock to the reconstructed graph.
2021-03-29Hide unnecessary reference to traitEsteban Küber-3/+0
When the problem for a method not being found in its receiver is due to arbitrary self-types, we don't want to mention importing or implementing the trait, instead we suggest wrapping.
2021-03-29Suggest box/pin/arc ing receiver on method callsEsteban Küber-0/+72
2021-03-15Replace `type_alias_impl_trait` by `min_type_alias_impl_trait` with no ↵Oli Scherer-1/+15
actual changes in behaviour This makes `type_alias_impl_trait` not actually do anything anymore
2021-03-06Move some tests to more suitable subdirsYuki Okushi-0/+29
2021-02-24clarifies error when finding mismatched returned types for async functionsNell Shamrell-8/+16
Signed-off-by: Nell Shamrell <nellshamrell@gmail.com>
2021-02-21reword `;` suggestions to have consistent wordingEsteban Küber-2/+2
2021-02-19Rollup merge of #81496 - guswynn:expected_async_block, r=oli-obkDylan DPC-0/+65
name async generators something more human friendly in type error diagnostic fixes #81457 Some details: 1. I opted to load the generator kind from the hir in TyCategory. I also use 1 impl in the hir for the descr 2. I named both the source of the future, in addition to the general type (`future`), not sure what is preferred 3. I am not sure what is required to make sure "generator" is not referred to anywhere. A brief `rg "\"generator\"" showed me that most diagnostics correctly distinguish from generators and async generator, but the `descr` of `DefKind` is pretty general (not sure how thats used) 4. should the descr impl of AsyncGeneratorKind use its display impl instead of copying the string?
2021-02-18Rollup merge of #82203 - c410-f3r:tests-tests-tests, r=Dylan-DPCYuki Okushi-0/+27
Move some tests to more reasonable directories - 4 cc #81941
2021-02-16Move some tests to more reasonable directoriesCaio-0/+27
2021-02-15name async generators something more human friendly in type error diagnosticsGus Wynn-0/+65
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-07-14 04:59:59 +0000