about summary refs log tree commit diff
path: root/src/librustc_ast_lowering
AgeCommit message (Collapse)AuthorLines
2020-08-30mv compiler to compiler/mark-6741/+0
2020-08-24hir: consistent use and naming of lang itemsDavid Wood-1/+1
This commit adjusts the naming of various lang items so that they are consistent and don't include prefixes containing the target or "LangItem". In addition, lang item variants are no longer exported from the `lang_items` module. Signed-off-by: David Wood <david@davidtw.co>
2020-08-22Use smaller def span for functionsAaron Hill-3/+12
Currently, the def span of a funtion encompasses the entire function signature and body. However, this is usually unnecessarily verbose - when we are pointing at an entire function in a diagnostic, we almost always want to point at the signature. The actual contents of the body tends to be irrelevant to the diagnostic we are emitting, and just takes up additional screen space. This commit changes the `def_span` of all function items (freestanding functions, `impl`-block methods, and `trait`-block methods) to be the span of the signature. For example, the function ```rust pub fn foo<T>(val: T) -> T { val } ``` now has a `def_span` corresponding to `pub fn foo<T>(val: T) -> T` (everything before the opening curly brace). Trait methods without a body have a `def_span` which includes the trailing semicolon. For example: ```rust trait Foo { fn bar(); }``` the function definition `Foo::bar` has a `def_span` of `fn bar();` This makes our diagnostic output much shorter, and emphasizes information that is relevant to whatever diagnostic we are reporting. We continue to use the full span (including the body) in a few of places: * MIR building uses the full span when building source scopes. * 'Outlives suggestions' use the full span to sort the diagnostics being emitted. * The `#[rustc_on_unimplemented(enclosing_scope="in this scope")]` attribute points the entire scope body. * The 'unconditional recursion' lint uses the full span to show additional context for the recursive call. All of these cases work only with local items, so we don't need to add anything extra to crate metadata.
2020-08-17Auto merge of #75120 - JulianKnodt:rm_reps, r=oli-obkbors-7/+6
rust_ast::ast => rustc_ast Rework of #71199 which is a rework #70621 Still working on this but just made the PR to track progress r? @Dylan-DPC
2020-08-17Auto merge of #75145 - ↵bors-177/+94
davidtwco:issue-60607-preallocate-defid-for-lang-items, r=petrochenkov Reference lang items during AST lowering Fixes #60607 and fixes #61019. This PR introduces `QPath::LangItem` to the HIR and uses it in AST lowering instead of constructing a `hir::Path` from a slice of symbols: - Credit for much of this work goes to @matthewjasper, I basically just [rebased their earlier work](https://github.com/matthewjasper/rust/commit/a227c706b7809ff07021baf3856b7540d5b57f8a#diff-c0f791ead38d2d02916faaad0f56f41d). - ~~Changes to Clippy might not be correct, they compile but attempting to run tests through `./x.py` produced failures which appeared spurious, so I didn't run any clippy tests.~~ - Changes to save analysis might not be correct - tests pass but I don't have a lot of confidence in those changes being correct. - I've used `GenericBounds::LangItemTrait` rather than changing `PolyTraitRef`, as suggested by @matthewjasper [in this comment](https://github.com/matthewjasper/rust/commit/a227c706b7809ff07021baf3856b7540d5b57f8a#r40107992) but I'd prefer that be left for a follow-up. - I've split things into smaller commits fairly arbitrarily to make the diff easier to review, each commit should compile but might not pass tests until the final commit. r? @oli-obk cc @matthewjasper
2020-08-17rust_ast::ast => rustc_astUjjwal Sharma-7/+6
2020-08-16Rollup merge of #74204 - ayazhafiz:i/74120, r=eddybTyler Mandry-1/+13
Don't visit foreign function bodies when lowering ast to hir Previously the existence of bodies inside a foreign function block would cause a panic in the hir `NodeCollector` during its collection of crate bodies to compute a crate hash: https://github.com/rust-lang/rust/blob/e59b08e62ea691916d2f063cac5aab4634128022/src/librustc_middle/hir/map/collector.rs#L154-L158 The collector walks the hir tree and creates a map of hir nodes, then attaching bodies in the crate to their owner in the map. For a code like ```rust extern "C" { fn f() { fn g() {} } } ``` The crate bodies include the body of the function `g`. But foreign functions cannot have bodies, and while the parser AST permits a foreign function to have a body, the hir doesn't. This means that the body of `f` is not present in the hir, and so neither is `g`. So when the `NodeCollector` finishes the walking the hir, it has no record of `g`, cannot find an owner for the body of `g` it sees in the crate bodies, and blows up. Why do the crate bodies include the body of `g`? The AST walker has a need a for walking function bodies, and FFIs share the same AST node as functions in other contexts. There are at least two options to fix this: - Don't unwrap the map entry for an hir node in the `NodeCollector` - Modifier the ast->hir lowering visitor to ignore foreign function blocks I don't think the first is preferrable, since we want to know when we can't find a body for an hir node that we thought had one (dropping this information may lead to an invalid hash). So this commit implements the second option. Closes #74120
2020-08-16hir: introduce `QPath::LangItem`David Wood-177/+94
This commit introduces `QPath::LangItem` to the HIR and uses it in AST lowering instead of constructing a `hir::Path` from a slice of symbols. This might be better for performance, but is also much cleaner as the previous approach is fragile. In addition, it resolves a bug (#61019) where an extern crate imported as "std" would result in the paths created during AST lowering being resolved incorrectly (or not at all). Co-authored-by: Matthew Jasper <mjjasper1@gmail.com> Signed-off-by: David Wood <david@davidtw.co>
2020-08-10Rollup merge of #75350 - estebank:foreign-fn-with-body-ice, r=davidtwcoYuki Okushi-1/+3
Do not ICE when lowering invalid extern fn with bodies Fix #75283.
2020-08-09Do not ICE when lowering invalid extern fn with bodiesEsteban Küber-1/+3
Fix #75283.
2020-08-08Eliminate the `SessionGlobals` from `librustc_ast`.Nicholas Nethercote-5/+3
By moving `{known,used}_attrs` from `SessionGlobals` to `Session`. This means they are accessed via the `Session`, rather than via TLS. A few `Attr` methods and `librustc_ast` functions are now methods of `Session`. All of this required passing a `Session` to lots of functions that didn't already have one. Some of these functions also had arguments removed, because those arguments could be accessed directly via the `Session` argument. `contains_feature_attr()` was dead, and is removed. Some functions were moved from `librustc_ast` elsewhere because they now need to access `Session`, which isn't available in that crate. - `entry_point_type()` --> `librustc_builtin_macros` - `global_allocator_spans()` --> `librustc_metadata` - `is_proc_macro_attr()` --> `Session`
2020-08-07Auto merge of #74627 - petrochenkov:docbeauty2, r=Aaron1011bors-1/+1
rustc_ast: Stop using "string typing" for doc comment tokens Explicitly store their kind and style retrieved during lexing in the `token::DocComment`. Also don't "beautify" doc comments before converting them to `#[doc]` attributes when passing them to macros (both declarative and procedural). The trimming of empty lines, lines containing only `*`s, etc is purely a rustdoc's job as a part of its presentation of doc strings to users, rustc must not do this and must pass tokens as precisely as possible internally.
2020-08-06rustc_ast: Stop using "string typing" for doc comment tokensVadim Petrochenkov-1/+1
Explicitly store their kind and style retrieved during lexing in the token
2020-08-06Fix ICE when using asm! on an unsupported architectureAmanieu d'Antras-1/+1
Fixes #75220
2020-08-02Auto merge of #74963 - JohnTitor:ptn-ice, r=petrochenkovbors-2/+0
Fix ICEs with `@ ..` binding This reverts #74557 and introduces an alternative fix while ensuring that #74954 is not broken. The diagnostics are verbose though, it fixes three related issues. cc #74954, #74539, and #74702
2020-08-02Replace from log to tracingbishtpawan-3/+3
2020-08-02Replace from log to tracing in libsrustrustc_ast_lowering, ↵bishtpawan-4/+4
librustc_ast_passes, librustc_ast_pretty
2020-07-31Move from `log` to `tracing`Oliver Scherer-1/+1
2020-07-31Fix ICEs with `@ ..` bindingYuki Okushi-2/+0
2020-07-26Hygiene serialization implementationAaron Hill-1/+2
2020-07-23cleanupBastian Kauschke-1/+1
2020-07-23stop sorting generic paramsBastian Kauschke-14/+1
2020-07-15fixup! Don't visit foreign function bodies when lowering ast to hirAyaz Hafiz-0/+2
2020-07-14fixup! Don't visit foreign function bodies when lowering ast to hirAyaz Hafiz-1/+0
2020-07-14fixup! fixup! Don't visit foreign function bodies when lowering ast to hirAyaz Hafiz-10/+2
2020-07-14Suggest borrowing in more unsized fn param casesEsteban Küber-1/+3
2020-07-09fixup! Don't visit foreign function bodies when lowering ast to hirAyaz Hafiz-31/+12
2020-07-09Don't visit foreign function bodies when lowering ast to hirAyaz Hafiz-1/+39
Previously the existence of bodies inside a foreign function block would cause a panic in the hir `NodeCollector` during its collection of crate bodies to compute a crate hash: https://github.com/rust-lang/rust/blob/e59b08e62ea691916d2f063cac5aab4634128022/src/librustc_middle/hir/map/collector.rs#L154-L158 The collector walks the hir tree and creates a map of hir nodes, then attaching bodies in the crate to their owner in the map. For a code like ```rust extern "C" { fn f() { fn g() {} } } ``` The crate bodies include the body of the function `g`. But foreign functions cannot have bodies, and while the parser AST permits a foreign function to have a body, the hir doesn't. This means that the body of `f` is not present in the hir, and so neither is `g`. So when the `NodeCollector` finishes the walking the hir, it has no record of `g`, cannot find an owner for the body of `g` it sees in the crate bodies, and blows up. Why do the crate bodies include the body of `g`? The AST walker has a need a for walking function bodies, and FFIs share the same AST node as functions in other contexts. There are at least two options to fix this: - Don't unwrap the map entry for an hir node in the `NodeCollector` - Modifier the ast->hir lowering visitor to ignore foreign function blocks I don't think the first is preferrable, since we want to know when we can't find a body for an hir node that we thought had one (dropping this information may lead to an invalid hash). So this commit implements the second option. Closes #74120
2020-07-01Rollup merge of #73569 - Aaron1011:fix/macro-rules-group, r=petrochenkovManish Goregaokar-3/+8
Handle `macro_rules!` tokens consistently across crates When we serialize a `macro_rules!` macro, we used a 'lowered' `TokenStream` for its body, which has all `Nonterminal`s expanded in-place via `nt_to_tokenstream`. This matters when an 'outer' `macro_rules!` macro expands to an 'inner' `macro_rules!` macro - the inner macro may use tokens captured from the 'outer' macro in its definition. This means that invoking a foreign `macro_rules!` macro may use a different body `TokenStream` than when the same `macro_rules!` macro is invoked in the same crate. This difference is observable by proc-macros invoked by a `macro_rules!` macro - a `None`-delimited group will be seen in the same-crate case (inserted when convering `Nonterminal`s to the `proc_macro` crate's structs), but no `None`-delimited group in the cross-crate case. To fix this inconsistency, we now insert `None`-delimited groups when 'lowering' a `Nonterminal` `macro_rules!` body, just as we do in `proc_macro_server`. Additionally, we no longer print extra spaces for `None`-delimited groups - as far as pretty-printing is concerned, they don't exist (only their contents do). This ensures that `Display` output of a `TokenStream` does not depend on which crate a `macro_rules!` macro was invoked from. This PR is necessary in order to patch the `solana-genesis-programs` for the upcoming hygiene serialization breakage (https://github.com/rust-lang/rust/pull/72121#issuecomment-646924847). The `solana-genesis-programs` crate will need to use a proc macro to re-span certain tokens in a nested `macro_rules!`, which requires us to consistently use a `None`-delimited group. See `src/test/ui/proc-macro/nested-macro-rules.rs` for an example of the kind of nested `macro_rules!` affected by this crate.
2020-07-01Insert NoDelim groups around nonterminals when lowering macro_rulesAaron Hill-3/+8
2020-07-01Remove `token::FlattenGroup`Vadim Petrochenkov-1/+1
2020-06-28Rollup merge of #73813 - petrochenkov:restrait, r=davidtwcoManish Goregaokar-3/+3
Rename two `Resolver` traits `trait Resolver` -> `trait ResolverExpand` for the resolver interface available from expansion. `trait Resolver` -> `trait ResolverAstLowering` for the resolver interface available from AST lowering. Addresses https://github.com/rust-lang/rust/pull/73587#discussion_r443242556
2020-06-27Rename two `Resolver` traitsVadim Petrochenkov-3/+3
2020-06-26Explain move errors that occur due to method calls involving `self`Aaron Hill-3/+14
This is a re-attempt of #72389 (which was reverted in #73594) Instead of using `ExpnKind::Desugaring` to represent operators, this PR checks the lang item directly.
2020-06-26Rollup merge of #73597 - ayazhafiz:i/const-span, r=ecstatic-morseManish Goregaokar-1/+1
Record span of `const` kw in GenericParamKind Context: this is needed for a fix of https://github.com/rust-lang/rustfmt/issues/4263, which currently records the span of a const generic param incorrectly because the location of the `const` kw is not known. I am not sure how to add tests for this; any guidance in how to do so would be appreciated :slightly_smiling_face:
2020-06-26Rollup merge of #73588 - Amanieu:thumb-fp, r=nagisaManish Goregaokar-0/+1
Fix handling of reserved registers for ARM inline asm `r6` is now disallowed as an operand since LLVM sometimes uses it as a base pointer. The check against using the frame pointer as an operand now takes the platform into account and will block either `r7` or `r11` as appropriate. Fixes #73450 cc @cbiffle
2020-06-26proc_macro: Stop flattening groups with dummy spansVadim Petrochenkov-1/+1
2020-06-23Rollup merge of #73587 - marmeladema:hir-id-ification-final, r=petrochenkovManish Goregaokar-25/+44
Move remaining `NodeId` APIs from `Definitions` to `Resolver` Implements https://github.com/rust-lang/rust/pull/73291#issuecomment-643515557 TL;DR: it moves all fields that are only needed during name resolution passes into the `Resolver` and keep the rest in `Definitions`. This effectively enforces that all references to `NodeId`s are gone once HIR lowering is completed. After this, the only remaining work for #50928 should be to adjust the dev guide. r? @petrochenkov
2020-06-23Record span of `const` kw in GenericParamKindAyaz Hafiz-1/+1
Context: this is needed to fix https://github.com/rust-lang/rustfmt/issues/4263, which currently records the span of a const generic param incorrectly because the location of the `const` kw is not known. I am not sure how to add tests for this; any guidance in how to do so would be appreciated :slightly_smiling_face:
2020-06-22Revert "Rollup merge of #72389 - Aaron1011:feature/move-fn-self-msg, ↵Aaron Hill-19/+5
r=nikomatsakis" This reverts commit 372cb9b69c76a042d0b9d4b48ff6084f64c84a2c, reversing changes made to 5c61a8dc34c3e2fc6d7f02cb288c350f0233f944.
2020-06-21Always create a root definition when creating a new `Definitions` object.marmeladema-7/+7
2020-06-21Move remaining `NodeId` APIs from `Definitions` to `Resolver`marmeladema-24/+43
2020-06-21Fix handling of reserved registers for ARM inline asmAmanieu d'Antras-0/+1
2020-06-20Rollup merge of #73378 - matthewjasper:arena-not-special, r=oli-obkManish Goregaokar-2/+0
Remove use of specialization from librustc_arena This reworks the macro so that specialization, `transmute` and `#[marker]` are not used. r? @oli-obk
2020-06-20Move `trait_map` into `hir::Crate`marmeladema-0/+10
2020-06-15Remove use of specialization from librustc_arenaMatthew Jasper-2/+0
2020-06-15Auto merge of #73369 - RalfJung:rollup-hl8g9zf, r=RalfJungbors-1/+1
Rollup of 10 pull requests Successful merges: - #72707 (Use min_specialization in the remaining rustc crates) - #72740 (On recursive ADT, provide indirection structured suggestion) - #72879 (Miri: avoid tracking current location three times) - #72938 (Stabilize Option::zip) - #73086 (Rename "cyclone" to "apple-a7" per changes in upstream LLVM) - #73104 (Example about explicit mutex dropping) - #73139 (Add methods to go from a nul-terminated Vec<u8> to a CString) - #73296 (Remove vestigial CI job msvc-aux.) - #73304 (Revert heterogeneous SocketAddr PartialEq impls) - #73331 (extend network support for HermitCore) Failed merges: r? @ghost
2020-06-15Rollup merge of #72707 - matthewjasper:rustc_min_spec, r=oli-obkRalf Jung-1/+1
Use min_specialization in the remaining rustc crates This adds a lot of `transmute` calls to replace the unsound uses of specialization. It's ugly, but at least it's honest about what's going on. cc #71420, @RalfJung
2020-06-15Auto merge of #73367 - RalfJung:rollup-4ewvk9b, r=RalfJungbors-5/+19
Rollup of 10 pull requests Successful merges: - #71824 (Check for live drops in constants after drop elaboration) - #72389 (Explain move errors that occur due to method calls involving `self`) - #72556 (Fix trait alias inherent impl resolution) - #72584 (Stabilize vec::Drain::as_slice) - #72598 (Display information about captured variable in `FnMut` error) - #73336 (Group `Pattern::strip_*` method together) - #73341 (_match.rs: fix module doc comment) - #73342 (Fix iterator copied() documentation example code) - #73351 (Update E0446.md) - #73353 (structural_match: non-structural-match ty closures) Failed merges: r? @ghost
2020-06-15Auto merge of #72080 - matthewjasper:uniform-impl-trait, r=nikomatsakisbors-70/+158
Clean up type alias impl trait implementation - Removes special case for top-level impl trait - Removes associated opaque types - Forbid lifetime elision in let position impl trait. This is consistent with the behavior for inferred types. - Handle lifetimes in type alias impl trait more uniformly with other parameters cc #69323 cc #63063 Closes #57188 Closes #62988 Closes #69136 Closes #73061
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-26 14:19:00 +0000