about summary refs log tree commit diff
path: root/compiler/rustc_error_codes/src
AgeCommit message (Collapse)AuthorLines
2021-10-11Rollup merge of #89710 - sireliah:e0482, r=GuillaumeGomezMatthias Krüger-1/+74
Add long explanation for error E0482 This is longer explanation for error E0482 in the #61137. Please take a look and leave some feedback!
2021-10-11Clarify the error descriptionssireliah-17/+22
2021-10-09Add long explanation for error E0482sireliah-1/+69
2021-10-02Consistently use 'supertrait'.Bruce Mitchener-2/+2
A subset of places referred to 'super-trait', so this changes them to all use 'supertrait'. This matches 'supertype' and some other usages. An exception is 'auto-trait' which is consistently used in that manner.
2021-09-19Rollup merge of #88855 - calebzulawski:feature/simd_shuffle, r=nagisaYuki Okushi-1/+3
Allow simd_shuffle to accept vectors of any length cc ``@rust-lang/project-portable-simd`` ``@workingjubilee``
2021-09-12Do not issue E0071 if a type error has already been reportedFabian Wolff-7/+7
2021-09-11Allow simd_shuffle to accept vectors of any lengthCaleb Zulawski-1/+3
2021-08-30Update E0785.mdMichael Howell-1/+1
2021-08-30fix(rustc_typeck): produce better errors for dyn auto traitMichael Howell-0/+31
Fixes #85026
2021-08-30`feature(const_param_types)` -> `feature(adt_const_params)`lcnr-4/+4
2021-08-30`feature(const_generics)` -> `feature(const_param_types)`lcnr-7/+4
2021-08-23Detect incorrect number of lang item genericsasquared31415-1/+1
2021-08-21Auto merge of #88134 - rylev:force-warn-improvements, r=nikomatsakisbors-1/+1
Force warn improvements As part of stablization of the `--force-warn` option (#86516) I've made the following changes: * Error when the `warnings` lint group is based to the `--force-warn` option * Tests have been updated to make it easier to understand the semantics of `--force-warn` r? `@nikomatsakis`
2021-08-20Change example and tests for E0161.Anton Golov-5/+21
The code will not emit this warning once box expressions require a sized type (since that error is emitted earlier in the flow).
2021-08-18Error when warnings lint group is used with force-warnRyan Levick-1/+1
2021-08-18Auto merge of #86860 - fee1-dead:stabilize, r=LeSeulArtichautbors-4/+0
Stabilize `arbitrary_enum_discriminant` Closes #60553. ---- ## Stabilization Report _copied from https://github.com/rust-lang/rust/issues/60553#issuecomment-865922311_ ### Summary Enables a user to specify *explicit* discriminants on arbitrary enums. Previously, this was hard to achieve: ```rust #[repr(u8)] enum Foo { A(u8) = 0, B(i8) = 1, C(bool) = 42, } ``` Someone would need to add 41 hidden variants in between as a workaround with implicit discriminants. In conjunction with [RFC 2195](https://github.com/rust-lang/rfcs/blob/master/text/2195-really-tagged-unions.md), this feature would provide more flexibility for FFI and unsafe code involving enums. ### Test cases Most tests are in [`src/test/ui/enum-discriminant`](https://github.com/rust-lang/rust/tree/master/src/test/ui/enum-discriminant), there are two [historical](https://github.com/rust-lang/rust/blob/master/src/test/ui/parser/tag-variant-disr-non-nullary.rs) [tests](https://github.com/rust-lang/rust/blob/master/src/test/ui/parser/issue-17383.rs) that are now covered by the feature (removed by this pr due to them being obsolete). ### Edge cases The feature is well defined and does not have many edge cases. One [edge case](https://github.com/rust-lang/rust/issues/70509) was related to another unstable feature named `repr128` and is resolved. ### Previous PRs The [implementation PR](https://github.com/rust-lang/rust/pull/60732) added documentation to the Unstable Book, https://github.com/rust-lang/reference/pull/1055 was opened as a continuation of https://github.com/rust-lang/reference/pull/639. ### Resolution of unresolved questions The questions are resolved in https://github.com/rust-lang/rust/issues/60553#issuecomment-511235271. ---- (someone please add `needs-fcp`)
2021-08-11Rollup merge of #87700 - kornelski:e530text, r=oli-obkYuki Okushi-14/+39
Expand explanation of E0530 The explanation didn't cover a puzzling case of enum variants missing fields.
2021-08-08Auto merge of #87697 - GuillaumeGomez:add-e0784, r=nagisabors-1/+34
Assign E0784 error code for union expression errors
2021-08-06Rollup merge of #87715 - bhgomes:long-explanation-E0625, r=GuillaumeGomezYuki Okushi-1/+29
Add long error explanation for E0625 For #61137.
2021-08-04move full explanation to after erroneous exampleBrandon H. Gomes-4/+5
2021-08-03rustc: Fill out remaining parts of C-unwind ABIAlex Crichton-1/+3
This commit intends to fill out some of the remaining pieces of the C-unwind ABI. This has a number of other changes with it though to move this design space forward a bit. Notably contained within here is: * On `panic=unwind`, the `extern "C"` ABI is now considered as "may unwind". This fixes a longstanding soundness issue where if you `panic!()` in an `extern "C"` function defined in Rust that's actually UB because the LLVM representation for the function has the `nounwind` attribute, but then you unwind. * Whether or not a function unwinds now mainly considers the ABI of the function instead of first checking the panic strategy. This fixes a miscompile of `extern "C-unwind"` with `panic=abort` because that ABI can still unwind. * The aborting stub for non-unwinding ABIs with `panic=unwind` has been reimplemented. Previously this was done as a small tweak during MIR generation, but this has been moved to a separate and dedicated MIR pass. This new pass will, for appropriate functions and function calls, insert a `cleanup` landing pad for any function call that may unwind within a function that is itself not allowed to unwind. Note that this subtly changes some behavior from before where previously on an unwind which was caught-to-abort it would run active destructors in the function, and now it simply immediately aborts the process. * The `#[unwind]` attribute has been removed and all users in tests and such are now using `C-unwind` and `#![feature(c_unwind)]`. I think this is largely the last piece of the RFC to implement. Unfortunately I believe this is still not stabilizable as-is because activating the feature gate changes the behavior of the existing `extern "C"` ABI in a way that has no replacement. My thinking for how to enable this is that we add support for the `C-unwind` ABI on stable Rust first, and then after it hits stable we change the behavior of the `C` ABI. That way anyone straddling stable/beta/nightly can switch to `C-unwind` safely.
2021-08-03remove trailing newlineBrandon H. Gomes-1/+0
2021-08-03Expand explanation of E0530Kornel-14/+39
2021-08-02add long error explanation for E0625Brandon H. Gomes-1/+29
2021-08-02Assign E0784 to union expression errorGuillaume Gomez-1/+34
2021-07-30Update error code descriptionJonas Schievink-14/+4
2021-07-29Rollup merge of #87521 - midgleyc:long-E0498, r=GuillaumeGomezYuki Okushi-1/+23
Add long explanation for E0498 Helps with #61137
2021-07-29Rollup merge of #87435 - ibraheemdev:patch-4, r=JohnTitorYuki Okushi-4/+7
fix example code for E0617 Closes #86908
2021-07-28fix example code for E0617Ibraheem Ahmed-4/+7
2021-07-28Stabilize `arbitrary_enum_discriminant`Deadbeef-4/+0
2021-07-27Indicate E0665 is no longer emittedJacob Pratt-1/+3
2021-07-27Mark code as ignored due to requiring external pluginChris Midgley-1/+1
2021-07-27Add long explanation for E0498Chris Midgley-1/+23
2021-07-26Add long explanation for E0544.Chris Midgley-1/+30
2021-07-21Rollup merge of #87342 - midgleyc:add-E0757-long, r=GuillaumeGomezGuillaume Gomez-1/+34
Add long explanation for E0757 Helps with #61137
2021-07-21docs: normalise wording in line with docsChris Midgley-1/+1
2021-07-21docs: add additional links for ffi_pure / ffi_constChris Midgley-2/+10
2021-07-21Add long explanation for E0757Chris Midgley-1/+26
2021-07-21docs: add newline before exampleChris Midgley-0/+1
2021-07-21docs: remove spurious main functionsChris Midgley-4/+0
2021-07-21add working code exampleChris Midgley-0/+10
2021-07-20Add long explanation for E0722Chris Midgley-1/+25
2021-07-08Rollup merge of #86838 - lambinoo:I-69630-rust_const_unstable_check_const, ↵Guillaume Gomez-6/+6
r=oli-obk Checking that function is const if marked with rustc_const_unstable Fixes #69630 This one is still missing tests to check the behavior but I checked by hand and it seemed to work. I would not mind some direction for writing those unit tests!
2021-07-08fn must be const if marked with stability attributLamb-6/+6
remove trailing newline fix: test with attribute but missing const Update compiler/rustc_passes/src/stability.rs Co-authored-by: Léo Lanteri Thauvin <leseulartichaut@gmail.com> Add test for extern functions fix: using span_help instead of span_suggestion add test for some ABIs + fmt fix Update compiler/rustc_passes/src/stability.rs Co-authored-by: Léo Lanteri Thauvin <leseulartichaut@gmail.com> Refractor and add test for `impl const` Add test to make sure no output + cleanup condition ----------------------------- remove stdcall test, failing CI test C abi is already tested in this, so it is not that useful to test another one. The tested code is blind to which specific ABI for now, as long as it's not an intrinsic one
2021-07-05Rollup merge of #86477 - tlyu:e0716-clarification, r=JohnTitorYuki Okushi-2/+4
E0716: clarify that equivalent code example is erroneous In E0716, there is a code block that is equivalent to the erroneous code example. Especially when viewed with `rustc --explain`, it's not obvious that it is also erroneous, and some users have been confused when they try to change their code to match the erroneous equivalent. `@rustbot` label +A-diagnostics +D-newcomer-roadblock +T-compiler
2021-07-04E0716: clarify that equivalent code example is erroneousTaylor Yu-2/+4
In E0716, there is a code block that is equivalent to the erroneous code example. Especially when viewed with `rustc --explain`, it's not obvious that it is also erroneous, and some users have been confused when they try to change their code to match the erroneous equivalent.
2021-07-02Rollup merge of #86148 - FabianWolff:issue-85855, r=varkorYuki Okushi-1/+1
Check the number of generic lifetime and const parameters of intrinsics This pull request fixes #85855. The current code for type checking intrinsics only checks the number of generic _type_ parameters, but does not check for an incorrect number of lifetime or const parameters, which can cause problems later on, such as the ICE in #85855, where the code thought that it was looking at a type parameter but found a lifetime parameter: ``` error: internal compiler error: compiler/rustc_middle/src/ty/generics.rs:188:18: expected type parameter, but found another generic parameter ``` The changes in this PR add checks for the number of lifetime and const parameters, expand the scope of `E0094` to also apply to these cases, and improve the error message by properly pluralizing the number of expected generic parameters.
2021-07-01Minor adjustments and refactoringFabian Wolff-2/+1
2021-06-29Fix typo and improve documentation for E0632Fabian Wolff-2/+26
2021-06-24Auto merge of #86279 - JohnTitor:transparent-zero-size-fields, r=nikomatsakisbors-5/+5
Permit zero non-zero-field on transparent types Fixes #77841 This makes the transparent fields meet the below: > * A `repr(transparent)` type `T` must meet the following rules: > * It may have any number of 1-ZST fields > * In addition, it may have at most one other field of type U r? `@nikomatsakis`
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-01-12 16:04:58 +0000