about summary refs log tree commit diff
path: root/src/test/ui/issues
AgeCommit message (Collapse)AuthorLines
2020-10-04Rollup merge of #77368 - est31:apfloat_fix, r=varkorJonas Schievink-0/+24
Backport LLVM apfloat commit to rustc_apfloat Backports LLVM commit: https://github.com/llvm/llvm-project/commit/e34bd1e0b03d20a506ada156d87e1b3a96d82fa2 Fixes #69532
2020-10-04Rollup merge of #77388 - JohnTitor:add-tests, r=Dylan-DPCYuki Okushi-0/+9
Add some regression tests Closes #66501 Closes #68951 Closes #72565 Closes #74244 Closes #75299 The first issue is fixed in 1.43.0, other issues are fixed in the recent nightly.
2020-10-02Rollup merge of #77147 - fusion-engineering-forks:static-mutex, r=dtolnayYuki Okushi-12/+4
Split sys_common::Mutex in StaticMutex and MovableMutex. The (unsafe) `Mutex` from `sys_common` had a rather complicated interface. You were supposed to call `init()` manually, unless you could guarantee it was neither moved nor used reentrantly. Calling `destroy()` was also optional, although it was unclear if 1) resources might be leaked or not, and 2) if `destroy()` should only be called when `init()` was called. This allowed for a number of interesting (confusing?) different ways to use this `Mutex`, all captured in a single type. In practice, this type was only ever used in two ways: 1. As a static variable. In this case, neither `init()` nor `destroy()` are called. The variable is never moved, and it is never used reentrantly. It is only ever locked using the `LockGuard`, never with `raw_lock`. 2. As a `Box`ed variable. In this case, both `init()` and `destroy()` are called, it will be moved and possibly used reentrantly. No other combinations are used anywhere in `std`. This change simplifies things by splitting this `Mutex` type into two types matching the two use cases: `StaticMutex` and `MovableMutex`. The interface of both new types is now both safer and simpler. The first one does not call nor expose `init`/`destroy`, and the second one calls those automatically in its `new()` and `Drop` functions. Also, the locking functions of `MovableMutex` are no longer unsafe. --- This will also make it easier to conditionally box mutexes later, by moving that decision into sys/sys_common. Some of the mutex implementations (at least those of Wasm and 'sys/unsupported') are safe to move, so wouldn't need a box. ~~(But that's blocked on #76932 for now.)~~ (See #77380.)
2020-10-01Auto merge of #77354 - ecstatic-morse:const-checking-moar-errors, r=oli-obkbors-11/+2
Overhaul const-checking diagnostics The primary purpose of this PR was to remove `NonConstOp::STOPS_CONST_CHECKING`, which causes any additional errors found by the const-checker to be silenced. I used this flag to preserve diagnostic parity with `qualify_min_const_fn.rs`, which has since been removed. However, simply removing the flag caused a deluge of errors in some cases, since an error would be emitted any time a local or temporary had a wrong type. To remedy this, I added an alternative system (`DiagnosticImportance`) to silence additional error messages that were likely to distract the user from the underlying issue. When an error of the highest importance occurs, all less important errors are silenced. When no error of the highest importance occurs, all less important errors are emitted after checking is complete. Following the suggestions from the important error is usually enough to fix the less important errors, so this should lead to better UX most of the time. There's also some unrelated diagnostics improvements in this PR isolated in their own commits. Splitting them out would be possible, but a bit of a pain. This isn't as tidy as some of my other PRs, but it should *only* affect diagnostics, never whether or not something passes const-checking. Note that there are a few trivial exceptions to this, like banning `Yield` in all const-contexts, not just `const fn`. As always, meant to be reviewed commit-by-commit. r? `@oli-obk`
2020-10-01Add a regression test for issue-68951Yuki Okushi-0/+9
2020-09-30Backport LLVM apfloat commit to rustc_apfloatest31-0/+24
Backports LLVM commit: https://github.com/llvm/llvm-project/commit/e34bd1e0b03d20a506ada156d87e1b3a96d82fa2 Fixes #69532
2020-09-30Auto merge of #77069 - sexxi-goose:closure_print_2, r=nikomatsakisbors-8/+8
pretty.rs: Update Closure and Generator print More detailed outline: https://github.com/rust-lang/project-rfc-2229/pull/17 Closes: https://github.com/rust-lang/project-rfc-2229/issues/11 r? `@nikomatsakis` cc `@eddyb` `@davidtwco` `@estebank`
2020-09-29Say "doesn't" instead of "wouldn't" in convert messageCamelid-2/+2
2020-09-29Bless testsDylan MacKenzie-11/+2
2020-09-29Add article after "to"Camelid-2/+2
Also added missing backtick in "you can cast" message.
2020-09-29resolve: improve "try using the enum's variant"David Wood-0/+116
This commit improves the "try using the enum's variant" suggestion: - Variants in suggestions would not result in more errors (e.g. use of a struct variant is only suggested if the suggestion can trivially construct that variant). Therefore, suggestions are only emitted for variants that have no fields (since the suggestion can't know what value fields would have). - Suggestions include the syntax for constructing the variant. If a struct or tuple variant is suggested, then it is constructed in the suggestion - unless in pattern-matching or when arguments are already provided. - A help message is added which mentions the variants which are no longer suggested. Signed-off-by: David Wood <david@davidtw.co>
2020-09-29Auto merge of #76754 - varkor:diagnostic-cleanup-ii, r=ecstatic-morsebors-74/+74
Clean up diagnostics for arithmetic operation errors Plus a small tweak to a range pattern error message.
2020-09-28Rollup merge of #77170 - ecstatic-morse:const-fn-ptr, r=oli-obkRalf Jung-5/+5
Remove `#[rustc_allow_const_fn_ptr]` and add `#![feature(const_fn_fn_ptr_basics)]` `rustc_allow_const_fn_ptr` was a hack to work around the lack of an escape hatch for the "min `const fn`" checks in const-stable functions. Now that we have co-opted `allow_internal_unstable` for this purpose, we no longer need a bespoke attribute. Now this functionality is gated under `const_fn_fn_ptr_basics` (how concise!), and `#[allow_internal_unstable(const_fn_fn_ptr_basics)]` replaces `#[rustc_allow_const_fn_ptr]`. `const_fn_fn_ptr_basics` allows function pointer types to appear in the arguments and locals of a `const fn` as well as function pointer casts to be performed inside a `const fn`. Both of these were allowed in constants and statics already. Notably, this does **not** allow users to invoke function pointers in a const context. Presumably, we will use a nicer name for that (`const_fn_ptr`?). r? @oli-obk
2020-09-28Rollup merge of #76711 - davidtwco:issue-51154-param-closure, r=estebankRalf Jung-0/+21
diag: improve closure/generic parameter mismatch Fixes #51154. This PR improves the diagnostic when a type parameter is expected and a closure is found, noting that each closure has a distinct type and therefore could not always match the caller-chosen type of the parameter. r? @estebank
2020-09-28passes: `check_attr` on more targetsDavid Wood-36/+20
This commit modifies `check_attr` so that: - Enum variants are now checked (some attributes would not have been prohibited on variants previously). - `check_expr_attributes` and `check_stmt_attributes` are removed as `check_attributes` can perform the same checks. Signed-off-by: David Wood <david@davidtw.co>
2020-09-28pretty.rs: Update Closure and Generator printAman Arora-8/+8
Co-authored-by: Dhruv Jauhar <dhruvjhr@gmail.com> Co-authored-by: Logan Mosier <logmosier@gmail.com>
2020-09-27Use correct article in help message for conversion or castCamelid-1/+1
Before it always used `an`; now it uses the correct article for the type.
2020-09-27Bless testsDylan MacKenzie-3/+3
2020-09-27Update tests with new feature gateDylan MacKenzie-2/+2
2020-09-27Fix ui test.Mara Bos-12/+4
This test checks if the compiler complains about accesing a private field before complaining (or crashing) about the private function on it not marked as stable/unstable. The interface of the internal type (sys_common's Mutex) used for this was changed. With this change, it uses another function to test for the same issue.
2020-09-26Make invalid integer operation messages consistentvarkor-74/+74
2020-09-26Auto merge of #70743 - oli-obk:eager_const_to_pat_conversion, r=eddybbors-2/+34
Fully destructure constants into patterns r? `@varkor` as discussed in https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/constants.20in.20patterns/near/192789924 we should probably crater it once reviewed
2020-09-25Move from {{closure}}#0 syntax to {closure#0} for (def) path componentsmarmeladema-13/+13
2020-09-23Talk about unpredictable instead of "not deterministic"Oliver Scherer-4/+4
2020-09-22Fix dest prop miscompilation around referencesJonas Schievink-0/+16
2020-09-21Let user see the full type of type-length limit errorKornel Lesiński-9/+17
2020-09-20Use precise errors during const to pat conversion instead of a catch-all on ↵Oliver Scherer-0/+2
the main constant
2020-09-20Lint on function pointers used in patternsOliver Scherer-2/+32
2020-09-20Auto merge of #74949 - oli-obk:validate_const_eval_raw, r=RalfJungbors-26/+26
Validate constants during `const_eval_raw` This PR implements the groundwork for https://github.com/rust-lang/rust/issues/72396 * constants are now validated during `const_eval_raw` * to prevent cycle errors, we do not validate references to statics anymore beyond the fact that they are not dangling * the `const_eval` query ICEs if used on `static` items * as a side effect promoteds are now evaluated to `ConstValue::Scalar` again (since they are just a reference to the actual promoted allocation in most cases).
2020-09-19Rollup merge of #76749 - guswynn:hir_ranges, r=estebankRalf Jung-2/+29
give *even better* suggestion when matching a const range notice that the err already has "constant defined here" so this is now *exceedingly clear* extension to #76222 r? @estebank
2020-09-19Address review commentsOliver Scherer-26/+26
2020-09-17Better handling for exponential-sized types in misc placesValerii Lashmanov-7/+11
Mostly to fix ui/issues/issue-37311-type-length-limit/issue-37311.rs. Most parts of the compiler can handle deeply nested types with a lot of duplicates just fine, but some parts still attempt to naively traverse type tree. Before such problems were caught by type length limit check, but now these places will have to be changed to handle duplicated types gracefully.
2020-09-17Only visit types once when walking the type treeValerii Lashmanov-5/+9
This fixes #72408. Nested closures were resulting in exponential compilation time. As a performance optimization this change introduces MiniSet, which is a simple small storage optimized set.
2020-09-16comments and factor to own methodGus Wynn-2/+2
2020-09-16give better suggestion when matching a const rangeGus Wynn-2/+29
2020-09-14diag: improve closure/generic parameter mismatchDavid Wood-0/+21
This commit improves the diagnostic when a type parameter is expected and a closure is found, noting that each closure has a distinct type and therefore could not always match the caller-chosen type of the parameter. Signed-off-by: David Wood <david@davidtw.co>
2020-09-12Auto merge of #73461 - calebzulawski:validate-attribute-placement, ↵bors-1/+132
r=matthewjasper Validate built-in attribute placement Closes #54584, closes #47725, closes #54044. I've changed silently ignoring some incorrectly placed attributes to errors. I'm not sure what the policy is since this can theoretically break code (should they be warnings instead? does it warrant a crater run?).
2020-09-12Auto merge of #76222 - guswynn:const_diag, r=estebankbors-0/+35
Give better suggestion when const Range*'s are used as patterns Fixes #76191 let me know if there is more/different information you want to show in this case
2020-09-11better diag when const ranges are used in patternsGus Wynn-0/+35
2020-09-11Auto merge of #76499 - guswynn:priv_des, r=petrochenkovbors-0/+72
Give better diagnostic when using a private tuple struct constructor Fixes #75907 Some notes: 1. This required some deep changes, including removing a Copy impl for PatKind. If some tests fail, I would still appreciate review on the overall approach 2. this only works with basic patterns (no wildcards for example), and fails if there is any problems getting the visibility of the fields (i am not sure what the failure that can happen in resolve_visibility_speculative, but we check the length of our fields in both cases against each other, so if anything goes wrong, we fall back to the worse error. This could be extended to more patterns 3. this does not yet deal with #75906, but I believe it will be similar 4. let me know if you want more tests 5. doesn't yet at the suggestion that `@yoshuawuyts` suggested at the end of their issue, but that could be added relatively easily (i believe)
2020-09-11Give better diagnostic when using a private tuple struct constructorGus Wynn-0/+72
2020-09-10typeck/pat: inaccessible private fieldsDavid Wood-0/+60
This commit adjusts the missing field diagnostic logic for struct patterns in typeck to improve the diagnostic when the missing fields are inaccessible. Signed-off-by: David Wood <david@davidtw.co>
2020-09-10typeck/expr: inaccessible private fieldsDavid Wood-0/+18
This commit adjusts the missing field diagnostic logic for struct expressions in typeck to improve the diagnostic when the missing fields are inaccessible. Signed-off-by: David Wood <david@davidtw.co>
2020-09-10Fix broken test on MSVCCaleb Zulawski-1/+0
2020-09-09Rollup merge of #75984 - kornelski:typeormodule, r=matthewjasperTyler Mandry-3/+3
Improve unresolved use error message "use of undeclared type or module `foo`" doesn't mention that it could be a crate. This error can happen when users forget to add a dependency to `Cargo.toml`, so I think it's important to mention that it could be a missing crate. I've used a heuristic based on Rust's naming conventions. It complains about an unknown type if the ident starts with an upper-case letter, and crate or module otherwise. It seems to work very well. The expanded error help covers both an unknown type and a missing crate case.
2020-09-08Update testsGuillaume Gomez-6/+9
2020-09-05Emit warnings for misplaced attributes used by some cratesCaleb Zulawski-17/+52
2020-09-05Check placement of more attributesCaleb Zulawski-1/+98
2020-09-03specialization_graph: avoid trimmed paths for OverlapErrorDan Aloni-28/+28
2020-09-02pretty: trim paths of unique symbolsDan Aloni-487/+486
If a symbol name can only be imported from one place for a type, and as long as it was not glob-imported anywhere in the current crate, we can trim its printed path and print only the name. This has wide implications on error messages with types, for example, shortening `std::vec::Vec` to just `Vec`, as long as there is no other `Vec` importable anywhere. This adds a new '-Z trim-diagnostic-paths=false' option to control this feature. On the good path, with no diagnosis printed, we should try to avoid issuing this query, so we need to prevent trimmed_def_paths query on several cases. This change also relies on a previous commit that differentiates between `Debug` and `Display` on various rustc types, where the latter is trimmed and presented to the user and the former is not.
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-07-07 20:33:49 +0000