summary refs log tree commit diff
path: root/compiler/rustc_builtin_macros/src
AgeCommit message (Collapse)AuthorLines
2023-11-09Emit #[inline] on derive(Debug)Ben Kimock-1/+1
2023-11-04Use the correct span when emitting the `env!` resultThom Chiovoloni-1/+1
2023-11-02Minimize `pub` usage in `source_map.rs`.Nicholas Nethercote-1/+2
Most notably, this commit changes the `pub use crate::*;` in that file to `use crate::*;`. This requires a lot of `use` items in other crates to be adjusted, because everything defined within `rustc_span::*` was also available via `rustc_span::source_map::*`, which is bizarre. The commit also removes `SourceMap::span_to_relative_line_string`, which is unused.
2023-10-27Add gen blocks to ast and do some broken ast loweringOli Scherer-1/+1
2023-10-25Auto merge of #116236 - dtolnay:builtinmacrocomment, r=cjgillotbors-94/+112
Modernize rustc_builtin_macros generics helpers - Rustfmt-compatible formatting for the code snippets in comments - Eliminate an _"Extra scope required"_ obsoleted by NLL
2023-10-23Auto merge of #115324 - francorbacho:master, r=davidtwcobors-4/+131
Suggest removing redundant arguments in format!() Closes #105225. This is also a follow-up to #105635, which seems to have become stale. r? `@estebank`
2023-10-22Directly collect into ty_param_names instead of peeking to see if emptyDavid Tolnay-6/+4
2023-10-22Eliminate an "Extra scope required" obsoleted by NLLDavid Tolnay-55/+51
2023-10-22Rustfmt-compatible formatting for code snippets in rustc_builtin_macrosDavid Tolnay-40/+64
2023-10-20s/generator/coroutine/Oli Scherer-1/+1
2023-10-17[RFC 3127 - Trim Paths]: Condition remapped filepath on remap scopesUrgau-3/+8
2023-10-16docs: add Rust logo to more compiler cratesMichael Howell-0/+3
c6e6ecb1afea9695a42d0f148ce153536b279eb5 added it to some of the compiler's crates, but avoided adding it to all of them to reduce bit-rot. This commit adds to more.
2023-10-15Auto merge of #116688 - compiler-errors:rustfmt-up, r=WaffleLapkin,Nilstriebbors-77/+99
Format all the let-chains in compiler crates Since rust-lang/rustfmt#5910 has landed, soon we will have support for formatting let-chains (as soon as rustfmt syncs and beta gets bumped). This PR applies the changes [from master rustfmt to rust-lang/rust eagerly](https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/out.20formatting.20of.20prs/near/374997516), so that the next beta bump does not have to deal with a 200+ file diff and can remain concerned with other things like `cfg(bootstrap)` -- #113637 was a pain to land, for example, because of let-else. I will also add this commit to the ignore list after it has landed. The commands that were run -- I'm not great at bash-foo, but this applies rustfmt to every compiler crate, and then reverts the two crates that should probably be formatted out-of-tree. ``` ~/rustfmt $ ls -1d ~/rust/compiler/* | xargs -I@ cargo run --bin rustfmt -- `@/src/lib.rs` --config-path ~/rust --edition=2021 # format all of the compiler crates ~/rust $ git checkout HEAD -- compiler/rustc_codegen_{gcc,cranelift} # revert changes to cg-gcc and cg-clif ``` cc `@rust-lang/rustfmt` r? `@WaffleLapkin` or `@Nilstrieb` who said they may be able to review this purely mechanical PR :> cc `@Mark-Simulacrum` and `@petrochenkov,` who had some thoughts on the order of operations with big formatting changes in https://github.com/rust-lang/rust/pull/95262#issue-1178993801. I think the situation has changed since then, given that let-chains support exists on master rustfmt now, and I'm fairly confident that this formatting PR should land even if *bootstrap* rustfmt doesn't yet format let-chains in order to lessen the burden of the next beta bump.
2023-10-14Rollup merge of #116696 - c410-f3r:in-doc, r=petrochenkovMatthias Krüger-6/+8
Misc improvements cc https://github.com/rust-lang/rust/pull/116323#discussion_r1355282195 r? `@petrochenkov`
2023-10-13Misc improvementsCaio-6/+8
2023-10-13Format all the let chains in compilerMichael Goulet-77/+99
2023-10-10Don't `escape_debug` the condition of `assert!`.Nicholas Nethercote-1/+1
The assertion in `assert-long-condition.rs` used to be fail like this, all on one line: ``` thread 'main' panicked at 'assertion failed: 1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 + 10 + 11 + 12 + 13 + 14 + 15 + 16 + 17 + 18\n + 19 + 20 + 21 + 22 + 23 + 24 + 25 == 0', tests/ui/macros/assert-long-condition.rs:7:5 ``` The `\n` and subsequent indent is because the condition is pretty-printed, and the pretty-printer inserts a newline. Printing the newline in this way is arguably reasonable given that the message appears within single quotes, which is very similar to a string literal. However, after the assertion printing improvements that were released in 1.73, the assertion now fails like this: ``` thread 'main' panicked at tests/ui/macros/assert-long-condition.rs:7:5: assertion failed: 1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 + 10 + 11 + 12 + 13 + 14 + 15 + 16 + 17 + 18\n + 19 + 20 + 21 + 22 + 23 + 24 + 25 == 0 ``` Now that there are no single quotes around the pretty-printed condition, the `\n` is quite strange. This commit gets rid of the `\n`, by removing the `escape_debug` done on the pretty-printed message. This results in the following: ``` thread 'main' panicked at tests/ui/macros/assert-long-condition.rs:7:5: assertion failed: 1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 + 10 + 11 + 12 + 13 + 14 + 15 + 16 + 17 + 18 + 19 + 20 + 21 + 22 + 23 + 24 + 25 == 0 ``` The overly-large indent is still strange, but that's a separate pretty-printing issue. This change helps with #108341.
2023-10-05Only give autofix suggestion when no named args are presentfrancorbacho-2/+8
2023-10-05Highlight redundant arguments instead of the whole format stringfrancorbacho-5/+4
2023-10-05Fix diagnostics being cancelled even with unused argumentsfrancorbacho-11/+17
2023-10-05Remove unused variablefrancorbacho-5/+4
2023-10-05Document report_redundant_format_arguments()francorbacho-0/+2
2023-10-05Rename report_redundant_placeholders() to report_redundant_format_arguments()francorbacho-2/+2
2023-10-05Use diagnostic impls and add suggestions in redundant format!() argsfrancorbacho-25/+54
2023-10-05Separate report_redundant_placeholders() into its own functionfrancorbacho-52/+62
2023-10-05Suggest removing redundant arguments in format!()francorbacho-4/+80
2023-10-01Factor out the two `entry_point_type` functions.Nicholas Nethercote-16/+2
They are very similar, and each one has a comment about the importance of being kept in sync with the other. This commit removes the duplication.
2023-09-29Change `depth` arg to `at_root`.Nicholas Nethercote-3/+3
This will facilitate a subsequent refactoring.
2023-09-24ConstParamTy: require EqRalf Jung-1/+1
2023-09-18Rollup merge of #115891 - RalfJung:structural-trait-derive, r=nnethercoteMatthias Krüger-114/+42
simplify inject_impl_of_structural_trait There's a comment at `inject_impl_of_structural_trait` saying we cannot use `TraitDef`, but that comment is outdated -- we *can* use `TraitDef` nowadays since it has the `skip_path_as_bound` flag. (The flag needed some fixing, though.)
2023-09-18simplify inject_impl_of_structural_traitRalf Jung-114/+42
2023-09-17Rollup merge of #115611 - lukas-code:format!("{r#ident}"), r=compiler-errorsDylan DPC-26/+46
add diagnostic for raw identifiers in format string Format strings don't support raw identifiers (e.g. `format!("{r#type}")`), but they do support keywords in the format string directly (e.g. `format!("{type}")`). This PR improves the error output when attempting to use a raw identifier in a format string and adds a machine-applicable suggestion to remove the `r#`. fixes https://github.com/rust-lang/rust/issues/115466
2023-09-16Fix invalid markdown codeblock labelGuillaume Gomez-6/+6
2023-09-14Auto merge of #115677 - matthewjasper:let-expr-recovery, r=b-naberbors-1/+1
Improve invalid let expression handling - Move all of the checks for valid let expression positions to parsing. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress some later errors and MIR construction for invalid let expressions. - Fix a (drop) scope issue that was also responsible for #104172. Fixes #104172 Fixes #104868
2023-09-11Move let expression checking to parsingMatthew Jasper-1/+1
There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08Rename the feature, but not the attribute, to `coverage_attribute`Andy Caldwell-1/+1
2023-09-08Rework no_coverage to coverage(off)Andy Caldwell-5/+5
2023-09-06add diagnostic for raw identifiers in format stringLukas Markeffsky-26/+46
2023-08-27Load include_bytes! directly into an LrcBen Kimock-1/+1
2023-08-11rustc: Move `features` from `Session` to `GlobalCtxt`Vadim Petrochenkov-10/+18
Removes two pieces of mutable state. Follow up to #114622.
2023-08-11Auto merge of #114507 - sebastiantoh:issue-114235, r=jackh726bors-12/+28
Add suggestion to quote inlined format argument as string literal Fixes #114235
2023-08-06Generate better function argument names in global_allocator expansionDavid Tolnay-19/+14
2023-08-05Delete some useless casts from global_allocator expansionDavid Tolnay-14/+6
2023-08-05Add suggestion to quote inlined format argument as string literalSebastian Toh-12/+28
2023-08-04Rollup merge of #114434 - Nilstrieb:indexing-spans, r=est31Matthias Krüger-1/+1
Improve spans for indexing expressions fixes #114388 Indexing is similar to method calls in having an arbitrary left-hand-side and then something on the right, which is the main part of the expression. Method calls already have a span for that right part, but indexing does not. This means that long method chains that use indexing have really bad spans, especially when the indexing panics and that span in coverted into a panic location. This does the same thing as method calls for the AST and HIR, storing an extra span which is then put into the `fn_span` field in THIR. r? compiler-errors
2023-08-04Auto merge of #114414 - cjgillot:early-unnameable-test, r=petrochenkovbors-0/+22
Make test harness lint about unnnameable tests. Implementation of https://github.com/rust-lang/rust/pull/113734#discussion_r1283073418 About the options suggested in https://github.com/rust-lang/rust/issues/36629#issuecomment-404753945: adding this case to unused_attribute was just more complicated. I'll try to understand a bit more what you had in mind in https://github.com/rust-lang/rfcs/pull/2471#issuecomment-397241123 This was just simpler to do in a standalone PR. I'll remove the corresponding changes from https://github.com/rust-lang/rust/pull/113734 later. r? `@petrochenkov`
2023-08-04Improve spans for indexing expressionsNilstrieb-1/+1
Indexing is similar to method calls in having an arbitrary left-hand-side and then something on the right, which is the main part of the expression. Method calls already have a span for that right part, but indexing does not. This means that long method chains that use indexing have really bad spans, especially when the indexing panics and that span in coverted into a panic location. This does the same thing as method calls for the AST and HIR, storing an extra span which is then put into the `fn_span` field in THIR.
2023-08-03Make test harness lint about unnnameable tests.Camille GILLOT-0/+22
2023-08-03Remove `MacDelimiter`.Nicholas Nethercote-6/+9
It's the same as `Delimiter`, minus the `Invisible` variant. I'm generally in favour of using types to make impossible states unrepresentable, but this one feels very low-value, and the conversions between the two types are annoying and confusing. Look at the change in `src/tools/rustfmt/src/expr.rs` for an example: the old code converted from `MacDelimiter` to `Delimiter` and back again, for no good reason. This suggests the author was confused about the types.
2023-07-30inline format!() args up to and including rustc_middleMatthias Krüger-38/+31