summaryrefslogtreecommitdiff
path: root/compiler/rustc_builtin_macros/src
Commit message (Collapse)AuthorAgeFilesLines
...
| * Remove the `NodeId` of `ast::ExprKind::Async`Arpad Borsos2023-03-191-1/+1
| |
* | rustc_interface: Add a new query `pre_configure`Vadim Petrochenkov2023-03-231-5/+12
| | | | | | | | | | | | It partially expands crate attributes before the main expansion pass (without modifying the crate), and the produced preliminary crate attribute list is used for querying a few attributes that are required very early. Crate-level cfg attributes are then expanded normally during the main expansion pass, like attributes on any other nodes.
* | expand: Pass `ast::Crate` by reference to AST transforming passesVadim Petrochenkov2023-03-234-19/+9
| | | | | | | | Also some more attributes are passed by reference.
* | rustc: Remove unused `Session` argument from some attribute functionsVadim Petrochenkov2023-03-226-45/+35
| |
* | Rollup merge of #109301 - Ezrashaw:fix-ctf-ice, r=NilstriebMatthias Krüger2023-03-201-2/+24
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | fix: fix ICE in `custom-test-frameworks` feature Fixes #107454 Simple fix to emit error instead of ICEing. At some point, all the code in `tests.rs` should be refactored, there is a bit of duplication (this PR's code is repeated five times over lol). r? `@Nilstrieb` (active on the linked issue?)
| * | fix: fix ICE in `custom-test-frameworks` featureEzra Shaw2023-03-191-2/+24
| |/
* | Implementing "<test_binary> --list --format json" #107307 #49359Partha P. Das2023-03-151-1/+26
|/
* Properly allow macro expanded `format_args` invocations to uses capturesNilstrieb2023-03-141-35/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Originally, this was kinda half-allowed. There were some primitive checks in place that looked at the span to see whether the input was likely a literal. These "source literal" checks are needed because the spans created during `format_args` parsing only make sense when it is indeed a literal that was written in the source code directly. This is orthogonal to the restriction that the first argument must be a "direct literal", not being exanpanded from macros. This restriction was imposed by [RFC 2795] on the basis of being too confusing. But this was only concerned with the argument of the invocation being a literal, not whether it was a source literal (maybe in spirit it meant it being a source literal, this is not clear to me). Since the original check only really cared about source literals (which is good enough to deny the `format_args!(concat!())` example), macros expanding to `format_args` invocations were able to use implicit captures if they spanned the string in a way that lead back to a source string. The "source literal" checks were not strict enough and caused ICEs in certain cases (see # 106191 (the space is intended to avoid spammy backreferences)). So I tightened it up in # 106195 to really only work if it's a direct source literal. This caused the `indoc` crate to break. `indoc` transformed the source literal by removing whitespace, which made it not a "source literal" anymore (which is required to fix the ICE). But since `indoc` spanned the literal in ways that made the old check think that it's a literal, it was able to use implicit captures (which is useful and nice for the users of `indoc`). This commit properly seperates the previously introduced concepts of "source literal" and "direct literal" and therefore allows `indoc` invocations, which don't create "source literals" to use implicit captures again. [RFC 2795]: https://rust-lang.github.io/rfcs/2795-format-args-implicit-identifiers.html#macro-hygiene
* Remove `box_syntax` from AST and use in toolsclubby7892023-03-121-1/+0
|
* Rollup merge of #108726 - est31:backticks_matchmaking_tidy, r=NilstriebMatthias Krüger2023-03-121-0/+1
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | tidy: enforce comment blocks to have an even number of backticks After PR #108694, most unmatched backticks in `compiler/` comments have been eliminated. This PR adds a tidy lint to ensure no new unmatched backticks are added, and either addresses the lint in the remaining instances it found, or allows it. Very often, backtick containing sections wrap around lines, for example: ```Rust // This function takes a tuple `(Vec<String>, // Box<[u8]>)` and transforms it into `Vec<u8>`. ``` The lint is implemented to work on top of blocks, counting each line with a `//` into a block, and counting if there are an odd or even number of backticks in the entire block, instead of looking at just a single line.
| * Address the new odd backticks tidy lint in compiler/est312023-03-111-0/+1
| |
* | Simplify message pathsest312023-03-111-1/+1
| | | | | | | | | | | | | | | | | | | | This makes it easier to open the messages file while developing on features. The commit was the result of automatted changes: for p in compiler/rustc_*; do mv $p/locales/en-US.ftl $p/messages.ftl; rmdir $p/locales; done for p in compiler/rustc_*; do sed -i "s#\.\./locales/en-US.ftl#../messages.ftl#" $p/src/lib.rs; done
* | Rollup merge of #106844 - Ezrashaw:concat-negative-int-lit, r=dtolnayMatthias Krüger2023-03-111-1/+14
|\ \ | |/ |/| | | | | | | | | | | allow negative numeric literals in `concat!` Fixes #106837 While *technically* negative numeric literals are implemented as unary operations, users can reasonably expect that negative literals are treated the same as positive literals.
| * allow negative numeric literals in `concat!`Ezra Shaw2023-01-151-1/+14
| |
* | Rollup merge of #105798 - Amanieu:relax-asm, r=joshtriplettMatthias Krüger2023-03-101-31/+4
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Relax ordering rules for `asm!` operands The `asm!` and `global_asm!` macros require their operands to appear strictly in the following order: - Template strings - Positional operands - Named operands - Explicit register operands - `clobber_abi` - `options` This is overly strict and can be inconvienent when building complex `asm!` statements with macros. This PR relaxes the ordering requirements as follows: - Template strings must still come before all other operands. - Positional operands must still come before named and explicit register operands. - Named and explicit register operands can be freely mixed. - `options` and `clobber_abi` can appear in any position after the template strings. r? ```````@joshtriplett```````
| * | Relax ordering rules for `asm!` operandsAmanieu d'Antras2023-01-271-31/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The `asm!` and `global_asm!` macros require their operands to appear strictly in the following order: - Template strings - Positional operands - Named operands - Explicit register operands - `clobber_abi` - `options` This is overly strict and can be inconvienent when building complex `asm!` statements with macros. This PR relaxes the ordering requirements as follows: - Template strings must still come before all other operands. - Positional operands must still come before named and explicit register operands. - Named and explicit register operands can be freely mixed. - `options` and `clobber_abi` can appear in any position.
* | | Explain compile-time vs run-time difference in env!() error messageKornel2023-02-281-10/+30
| | |
* | | Replace parse_[sth]_expr with parse_expr_[sth] function namesest312023-02-241-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This resolves an inconsistency in naming style for functions on the parser, between functions parsing specific kinds of items and those for expressions, favoring the parse_item_[sth] style used by functions for items. There are multiple advantages of that style: * functions of both categories are collected in the same place in the rustdoc output. * it helps with autocompletion, as you can narrow down your search for a function to those about expressions. * it mirrors rust's path syntax where less specific things come first, then it gets more specific, i.e. std::collections::hash_map::Entry The disadvantage is that it doesn't "read like a sentence" any more, but I think the advantages weigh more greatly. This change was mostly application of this command: sed -i -E 's/(fn |\.)parse_([[:alnum:]_]+)_expr/\1parse_expr_\2/' compiler/rustc_parse/src/parser/*.rs Plus very minor fixes outside of rustc_parse, and an invocation of x fmt.
* | | errors: generate typed identifiers in each crateDavid Wood2023-02-221-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | Instead of loading the Fluent resources for every crate in `rustc_error_messages`, each crate generates typed identifiers for its own diagnostics and creates a static which are pulled together in the `rustc_driver` crate and provided to the diagnostic emitter. Signed-off-by: David Wood <david.wood@huawei.com>
* | | Use `ThinVec` in a few more AST types.Nicholas Nethercote2023-02-212-3/+3
| | |
* | | Use `ThinVec` in `ast::ExprKind::Match`.Nicholas Nethercote2023-02-215-5/+5
| | |
* | | Use `ThinVec` in `ast::PatKind::Struct`.Nicholas Nethercote2023-02-211-2/+2
| | |
* | | Use `ThinVec` in `ast::Block`.Nicholas Nethercote2023-02-2111-28/+28
| | |
* | | Use `ThinVec` in various AST types.Nicholas Nethercote2023-02-2119-82/+96
| | | | | | | | | | | | | | | This commit changes the sequence parsers to produce `ThinVec`, which triggers numerous conversions.
* | | Use `ThinVec` in `ast::Impl` and related types.Nicholas Nethercote2023-02-211-1/+2
| | |
* | | Use `ThinVec` in `ast::WhereClause`.Nicholas Nethercote2023-02-211-1/+6
| | |
* | | Use `ThinVec` in `ast::Generics` and related types.Nicholas Nethercote2023-02-211-5/+5
| | |
* | | Auto merge of #108128 - clubby789:builtin-derived-attr, r=jackh726bors2023-02-191-2/+1
|\ \ \ | | | | | | | | | | | | | | | | | | | | Properly check for builtin derived code Fixes #108122
| * | | Properly check for builtin derivesclubby7892023-02-161-2/+1
| | | |
* | | | Replace some `then`s with some `then_some`sMaybe Waffle2023-02-161-1/+1
| | | |
* | | | `if $c:expr { Some($r:expr) } else { None }` =>> `$c.then(|| $r)`Maybe Waffle2023-02-162-11/+7
|/ / /
* | | Extend `BYTE_SLICE_IN_PACKED_STRUCT_WITH_DERIVE`.Nicholas Nethercote2023-02-091-20/+35
| | | | | | | | | | | | | | | To temporarily allow a `str` field in a packed struct using `derive`, along with `[u8]`.
* | | Add ~const bounds trait bounds when using derive_constMichael Goulet2023-02-073-10/+27
| | |
* | | Don't generate unecessary `&&self.field` in deriving Debugclubby7892023-02-021-5/+20
| | |
* | | Fix syntax in `-Zunpretty-expanded` output for derived `PartialEq`.Nicholas Nethercote2023-02-011-5/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If you do `derive(PartialEq)` on a packed struct, the output shown by `-Zunpretty=expanded` includes expressions like this: ``` { self.x } == { other.x } ``` This is invalid syntax. This doesn't break compilation, because the AST nodes are constructed within the compiler. But it does mean anyone using `-Zunpretty=expanded` output as a guide for hand-written impls could get a nasty surprise. This commit fixes things by instead using this form: ``` ({ self.x }) == ({ other.x }) ```
* | | Allow more deriving on packed structs.Nicholas Nethercote2023-01-3012-48/+98
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, deriving on packed structs has some non-trivial limitations, related to the fact that taking references on unaligned fields is UB. The current approach to field accesses in derived code: - Normal case: `&self.0` - In a packed struct that derives `Copy`: `&{self.0}` - In a packed struct that doesn't derive `Copy`: `&self.0` Plus, we disallow deriving any builtin traits other than `Default` for any packed generic type, because it's possible that there might be misaligned fields. This is a fairly broad restriction. Plus, we disallow deriving any builtin traits other than `Default` for most packed types that don't derive `Copy`. (The exceptions are those where the alignments inherently satisfy the packing, e.g. in a type with `repr(packed(N))` where all the fields have alignments of `N` or less anyway. Such types are pretty strange, because the `packed` attribute is not having any effect.) This commit introduces a new, simpler approach to field accesses: - Normal case: `&self.0` - In a packed struct: `&{self.0}` In the latter case, this requires that all fields impl `Copy`, which is a new restriction. This means that the following example compiles under the old approach and doesn't compile under the new approach. ``` #[derive(Debug)] struct NonCopy(u8); #[derive(Debug) #[repr(packed)] struct MyType(NonCopy); ``` (Note that the old approach's support for cases like this was brittle. Changing the `u8` to a `u16` would be enough to stop it working. So not much capability is lost here.) However, the other constraints from the old rules are removed. We can now derive builtin traits for packed generic structs like this: ``` trait Trait { type A; } #[derive(Hash)] #[repr(packed)] pub struct Foo<T: Trait>(T, T::A); ``` To allow this, we add a `T: Copy` bound in the derived impl and a `T::A: Copy` bound in where clauses. So `T` and `T::A` must impl `Copy`. We can now also derive builtin traits for packed structs that don't derive `Copy`, so long as the fields impl `Copy`: ``` #[derive(Hash)] #[repr(packed)] pub struct Foo(u32); ``` This includes types that hand-impl `Copy` rather than deriving it, such as the following, that show up in winapi-0.2: ``` #[derive(Clone)] #[repr(packed)] struct MyType(i32); impl Copy for MyType {} ``` The new approach is simpler to understand and implement, and it avoids the need for the `unsafe_derive_on_repr_packed` check. One exception is required for backwards-compatibility: we allow `[u8]` fields for now. There is a new lint for this, `byte_slice_in_packed_struct_with_derive`.
* | | Auto merge of #103659 - clubby789:improve-partialord-derive, r=nagisabors2023-01-281-9/+73
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Special-case deriving `PartialOrd` for enums with dataless variants I was able to get slightly better codegen by flipping the derived `PartialOrd` logic for two-variant enums. I also tried to document the implementation of the derive macro to make the special-case logic a little clearer. ```rs #[derive(PartialEq, PartialOrd)] pub enum A<T> { A, B(T) } ``` ```diff impl<T: ::core::cmp::PartialOrd> ::core::cmp::PartialOrd for A<T> { #[inline] fn partial_cmp( &self, other: &A<T>, ) -> ::core::option::Option<::core::cmp::Ordering> { let __self_tag = ::core::intrinsics::discriminant_value(self); let __arg1_tag = ::core::intrinsics::discriminant_value(other); - match ::core::cmp::PartialOrd::partial_cmp(&__self_tag, &__arg1_tag) { - ::core::option::Option::Some(::core::cmp::Ordering::Equal) => { - match (self, other) { - (A::B(__self_0), A::B(__arg1_0)) => { - ::core::cmp::PartialOrd::partial_cmp(__self_0, __arg1_0) - } - _ => ::core::option::Option::Some(::core::cmp::Ordering::Equal), - } + match (self, other) { + (A::B(__self_0), A::B(__arg1_0)) => { + ::core::cmp::PartialOrd::partial_cmp(__self_0, __arg1_0) } - cmp => cmp, + _ => ::core::cmp::PartialOrd::partial_cmp(&__self_tag, &__arg1_tag), } } } ``` Godbolt: [Current](https://godbolt.org/z/GYjEzG1T8), [New](https://godbolt.org/z/GoK78qx15) I'm not sure how common a case comparing two enums like this (such as `Option`) is, and if it's worth the slowdown of adding a special case to the derive. If it causes overall regressions it might be worth just manually implementing this for `Option`.
| * | | Special case deriving `PartialOrd` for certain enum layoutsclubby7892023-01-151-9/+73
| | |/ | |/|
* | | Replace format flags u32 by enums and bools.Mara Bos2023-01-271-2/+11
| |/ |/|
* | Auto merge of #106745 - m-ou-se:format-args-ast, r=oli-obkbors2023-01-264-605/+11
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Move format_args!() into AST (and expand it during AST lowering) Implements https://github.com/rust-lang/compiler-team/issues/541 This moves FormatArgs from rustc_builtin_macros to rustc_ast_lowering. For now, the end result is the same. But this allows for future changes to do smarter things with format_args!(). It also allows Clippy to directly access the ast::FormatArgs, making things a lot easier. This change turns the format args types into lang items. The builtin macro used to refer to them by their path. After this change, the path is no longer relevant, making it easier to make changes in `core`. This updates clippy to use the new language items, but this doesn't yet make clippy use the ast::FormatArgs structure that's now available. That should be done after this is merged.
| * | Update comment explaining format_args!() expansion.Mara Bos2023-01-121-4/+4
| | |
| * | Expand format_args!() in rust_ast_lowering.Mara Bos2023-01-124-601/+7
| |/
* | Auto merge of #106884 - clubby789:fieldless-enum-debug, r=michaelwoeristerbors2023-01-2111-42/+124
|\ \ | | | | | | | | | | | | | | | Simplify `derive(Debug)` output for fieldless enums Fixes #106875
| * | Special case `derive(Debug)` for fieldless enumsclubby7892023-01-191-2/+49
| | |
| * | Add enum for fieldless unificationclubby7892023-01-1911-43/+78
| |/
* | Remove double spaces after dots in commentsMaybe Waffle2023-01-174-4/+4
|/
* Update format.rsGimbles2023-01-021-1/+1
|
* Rename `Rptr` to `Ref` in AST and HIRNilstrieb2022-12-284-7/+6
| | | | | The name makes a lot more sense, and `ty::TyKind` calls it `Ref` already as well.
* Rollup merge of #105975 - jeremystucki:rustc-remove-needless-lifetimes, r=eholkMatthias Krüger2022-12-241-1/+1
|\ | | | | | | rustc: Remove needless lifetimes
| * rustc: Remove needless lifetimesJeremy Stucki2022-12-201-1/+1
| |
View Lorry Controller Status