about summary refs log tree commit diff
path: root/src/test/ui/malformed
AgeCommit message (Collapse)AuthorLines
2023-01-11Move /src/test to /testsAlbert Larsan-317/+0
2022-12-13Make some diagnostics not depend on the source of what they reference being ↵Oli Scherer-6/+0
available
2022-10-01bless ui testsMaybe Waffle-1/+1
2022-08-26Implementation of import_name_typeDaniel Paoliello-2/+2
2022-05-05Overhaul `MacArgs::Eq`.Nicholas Nethercote-4/+4
The value in `MacArgs::Eq` is currently represented as a `Token`. Because of `TokenKind::Interpolated`, `Token` can be either a token or an arbitrary AST fragment. In practice, a `MacArgs::Eq` starts out as a literal or macro call AST fragment, and then is later lowered to a literal token. But this is very non-obvious. `Token` is a much more general type than what is needed. This commit restricts things, by introducing a new type `MacArgsEqKind` that is either an AST expression (pre-lowering) or an AST literal (post-lowering). The downside is that the code is a bit more verbose in a few places. The benefit is that makes it much clearer what the possibilities are (though also shorter in some other places). Also, it removes one use of `TokenKind::Interpolated`, taking us a step closer to removing that variant, which will let us make `Token` impl `Copy` and remove many "handle Interpolated" code paths in the parser. Things to note: - Error messages have improved. Messages like this: ``` unexpected token: `"bug" + "found"` ``` now say "unexpected expression", which makes more sense. Although arbitrary expressions can exist within tokens thanks to `TokenKind::Interpolated`, that's not obvious to anyone who doesn't know compiler internals. - In `parse_mac_args_common`, we no longer need to collect tokens for the value expression.
2022-04-05Suggest derivable trait on E0277ohno418-0/+8
2021-09-25Move malformed attribute code to a function and fix inner attribute suggestion.Eric Huss-2/+2
Moving to a dedicated function in preparation for other validation. The suggestion given didn't consider if it was an inner attribute.
2021-08-16Use note to point at bound introducing requirementEsteban Küber-6/+6
2021-08-11Modify structured suggestion outputEsteban Küber-2/+2
* On suggestions that include deletions, use a diff inspired output format * When suggesting addition, use `+` as underline * Color highlight modified span
2021-08-04Auto merge of #86155 - alexcrichton:abort-on-unwind, r=nikomatsakisbors-63/+0
rustc: Fill out remaining parts of C-unwind ABI 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-04Remove trailing whitespace from error messagesFabian Wolff-2/+2
2021-08-03rustc: Fill out remaining parts of C-unwind ABIAlex Crichton-63/+0
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-07-27Add long explanation for E0498Chris Midgley-0/+1
2021-05-12Show macro name in 'this error originates in macro' messageAaron Hill-2/+2
When there are multiple macros in use, it can be difficult to tell which one was responsible for producing an error.
2021-02-07expand/resolve: Turn `#[derive]` into a regular macro attributeVadim Petrochenkov-24/+8
2020-12-09Accept arbitrary expressions in key-value attributes at parse timeVadim Petrochenkov-21/+10
2020-11-19expand: Stop derive expansion un unexpected targets earlyVadim Petrochenkov-9/+2
Collect derive placeholders using `collect` instead of `push`
2020-09-08Update testsGuillaume Gomez-1/+2
2020-09-02pretty: trim paths of unique symbolsDan Aloni-6/+6
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.
2020-07-27mv std libs to library/mark-2/+2
2020-04-18Do not emit note for projected derived obligationsEsteban Küber-2/+0
2020-04-18Maintain chain of derived obligationsEsteban Küber-0/+12
When evaluating the derived obligations from super traits, maintain a reference to the original obligation in order to give more actionable context in the output.
2020-04-11rustc: Add a warning count upon completionRoccoDev-3/+3
2020-03-29#[link]: mention wasm_import_module instead of cfgJonas Schievink-2/+2
2020-02-27error_derive_forbidden_on_non_adt: be more gracefulMazdak Farrokhzad-0/+36
2020-02-06rustc_macros: don't limit the -Zmacro-backtrace suggestion to extern macros.Eduard-Mihai Burtescu-0/+8
2020-01-12Add backticks in appropriate placesvarkor-1/+1
2019-12-06parse_meta: ditch parse_in_attrMazdak Farrokhzad-0/+35
2019-12-06derive: avoid parse_in_attrMazdak Farrokhzad-9/+26
2019-12-06cfg_attr: avoid .outer_tokensMazdak Farrokhzad-4/+6
2019-12-01rustc_plugin: Remove support for plugin argumentsVadim Petrochenkov-4/+4
2019-11-08Rollup merge of #66007 - estebank:remove-here, r=CentrilMazdak Farrokhzad-2/+2
Remove "here" from "expected one of X here"
2019-11-06Remove "here" from "expected one of X here"Esteban Küber-2/+2
2019-11-06ill_formed_attribute_input -> denyMazdak Farrokhzad-27/+23
2019-11-02Update error annotations in tests that successfully compileTomasz Miąsko-9/+19
Those annotation are silently ignored rather than begin validated against compiler output. Update them before validation is enabled, to avoid test failures.
2019-10-24Increase spacing for suggestions in diagnosticsEsteban Küber-0/+2
Make the spacing between the code snippet and verbose structured suggestions consistent with note and help messages.
2019-10-17Plugins deprecation: don’t suggest simply removing the attributeSimon Sapin-6/+6
Building Servo with a recent Nightly produces: ```rust warning: use of deprecated attribute `plugin`: compiler plugins are deprecated. See https://github.com/rust-lang/rust/issues/29597 --> components/script/lib.rs:14:1 | 14 | #![plugin(script_plugins)] | ^^^^^^^^^^^^^^^^^^^^^^^^^^ help: remove this attribute | = note: `#[warn(deprecated)]` on by default ``` First, linking to https://github.com/rust-lang/rust/issues/29597 is not ideal since there is pretty much no discussion there of the deprecation and what can be used instead. This PR changes the link to the deprecation PR which does have more discussion. Second, the “remove this attribute” suggestion is rather unhelpful. Just because a feature is deprecated doesn’t mean that simply removing its use without a replacement is acceptable. In the case of custom lint, there is no replacement available. Prefixing a message with “help:” when telling users that they’re screwed honestly feels disrespectful. This PR also changes the message to be more factual.
2019-10-03plugin_registrary: use normal deprecation instead of hard coded warning.Mazdak Farrokhzad-18/+12
2019-10-03Deprecate `#![plugin]` and `#[plugin_registrar]`.Mazdak Farrokhzad-3/+36
2019-08-23`--bless` some tests due to message format change.Mazdak Farrokhzad-4/+2
2019-07-17normalize use of backticks in compiler messages for librustc/lintSamy Kacimi-1/+1
https://github.com/rust-lang/rust/issues/60532
2019-07-03Migrate compile-pass annotations to build-passYuki Okushi-1/+1
2019-06-22Lint empty 'derive()' as unused attribute.Mazdak Farrokhzad-10/+1
2019-06-08Introduce `#[rustc_dummy]` attribute and use it in testsVadim Petrochenkov-9/+9
Unlike other built-in attributes, this attribute accepts any input
2019-05-25Reword malformed attribute input diagnosticsEsteban Küber-36/+48
- Handle empty `cfg_attr` attribute - Reword empty `derive` attribute error - Use consistend error message: "malformed `attrname` attribute input" - Provide suggestions when possible - Move note/help to label/suggestion - Use consistent wording "ill-formed" -> "malformed" - Move diagnostic logic out of parser
2019-05-24Revert changes that belong to separate PREsteban Küber-21/+12
2019-05-24review commentsEsteban Küber-1/+1
2019-05-24Tweak macro parse errors when reaching EOF during macro call parseEsteban Küber-25/+31
- Add detail on origin of current parser when reaching EOF and stop saying "found <eof>" and point at the end of macro calls - Handle empty `cfg_attr` attribute - Reword empty `derive` attribute error
2019-05-11Move literal parsing code into a separate fileVadim Petrochenkov-4/+4
Remove some dead code
2019-05-11Simplify conversions between tokens and semantic literalsVadim Petrochenkov-9/+5
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-25 16:08:57 +0000