about summary refs log tree commit diff
path: root/src/librustc_ast_lowering/item.rs
AgeCommit message (Collapse)AuthorLines
2020-08-30mv compiler to compiler/mark-1458/+0
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-17rust_ast::ast => rustc_astUjjwal Sharma-1/+1
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-08Eliminate the `SessionGlobals` from `librustc_ast`.Nicholas Nethercote-2/+1
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-02Replace from log to tracingbishtpawan-1/+1
2020-08-02Replace from log to tracing in libsrustrustc_ast_lowering, ↵bishtpawan-1/+1
librustc_ast_passes, librustc_ast_pretty
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-0/+2
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-06-21Move remaining `NodeId` APIs from `Definitions` to `Resolver`marmeladema-11/+6
2020-06-11Allow all impl trait types to capture bound lifetimesMatthew Jasper-4/+26
2020-06-11Stop special casing top level TAITMatthew Jasper-41/+15
2020-05-29Remove remaining calls to `as_local_node_id`marmeladema-4/+7
2020-05-08Remove ast::{Ident, Name} reexports.Camille GILLOT-1/+1
2020-04-14Rename AssocKind::Method to AssocKind::FnRustin-Liu-2/+2
Rename fn_has_self_argument to fn_has_self_parameter Rename AssocItemKind::Method to AssocItemKind::Fn Refine has_no_input_arg Refine has_no_input_arg Revert has_no_input_arg Refine suggestion_descr Move as_def_kind into AssocKind Signed-off-by: Rustin-Liu <rustin.liu@gmail.com> Fix tidy check issue Signed-off-by: Rustin-Liu <rustin.liu@gmail.com>
2020-04-08librustc_hir: return LocalDefId instead of DefId in local_def_idmarmeladema-5/+5
2020-04-06Auto merge of #70737 - Centril:cleanup-lower-item-id, r=estebankbors-11/+2
cleanup `lower_item_id` r? @oli-obk
2020-04-03cleanup lower_item_idMazdak Farrokhzad-11/+2
2020-04-01Hide `task_context` when lowering bodyJonas Schievink-0/+2
2020-03-30Use if let instead of match when only matching a single variant ↵Matthias Krüger-10/+7
(clippy::single_match) Makes code more compact and reduces nestig.
2020-03-23Auto merge of #69649 - estebank:negative-impl-span, r=Centrilbors-13/+21
Tweak output for invalid negative impl errors Follow up to #69722. Tweak negative impl errors emitted in the HIR: ``` error[E0192]: invalid negative impl --> $DIR/E0192.rs:9:6 | LL | impl !Trait for Foo { } | ^^^^^^ | = note: negative impls are only allowed for auto traits, like `Send` and `Sync` ```
2020-03-22Tweak output for invalid negative impl errorsEsteban Küber-13/+21
2020-03-21lowering: bug! -> panic!Mazdak Farrokhzad-4/+3
2020-03-21separate out an arena for HIRMazdak Farrokhzad-1/+1
2020-03-21Rollup merge of #69033 - jonas-schievink:resume-with-context, r=tmandryMazdak Farrokhzad-2/+2
Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct, there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.
2020-03-19rustc: use LocalDefId instead of DefIndex in hir::lowering.Eduard-Mihai Burtescu-9/+14
2020-03-17Don't create AST fragments when lowering to HIRJonas Schievink-1/+1
2020-03-17Make async/await lowering use resume argumentsJonas Schievink-1/+1
2020-03-16Rollup merge of #69989 - petrochenkov:nolegacy, r=eddyb,matthewjasperDylan DPC-4/+4
resolve/hygiene: `macro_rules` are not "legacy" The "modern" vs "legacy" naming was introduced by jseyfried during initial implementation of macros 2.0. At this point it's clear that `macro_rules` are not going anywhere and won't be deprecated in the near future. So this PR changes the naming "legacy" (when it implies "macro_rules") to "macro_rules". This should also help people reading this code because it's wasn't obvious that "legacy" actually meant "macro_rules" in these contexts. The most contentious renaming here is probably ``` fn modern -> fn normalize_to_macros_2_0 fn modern_and_legacy -> fn normalize_to_macro_rules ``` Other alternatives that I could think of are `normalize_to_opaque`/`normalize_to_semitransparent`, or `strip_non_opaque`/`strip_transparent`, but they seemed less intuitive. The documentation to these functions can be found in `symbol.rs`. r? @matthewjasper
2020-03-15More Method->Fn renamingMark Mansi-3/+3
2020-03-16hygiene: `modern` -> `normalize_to_macros_2_0`Vadim Petrochenkov-1/+1
`modern_and_legacy` -> `normalize_to_macro_rules`
2020-03-16ast/hir: `MacroDef::legacy` -> `MacroDef::macro_rules`Vadim Petrochenkov-3/+3
2020-03-15Rollup merge of #69988 - petrochenkov:nomacrodef, r=CentrilMazdak Farrokhzad-6/+6
rustc_metadata: Remove `rmeta::MacroDef` And other related cleanups. Follow-up to https://github.com/rust-lang/rust/pull/66364. r? @Centril
2020-03-15Rollup merge of #69589 - petrochenkov:maccall, r=CentrilMazdak Farrokhzad-6/+6
ast: `Mac`/`Macro` -> `MacCall` It's now obvious that these refer to macro calls rather than to macro definitions. It's also a single name instead of two different names in different places. `rustc_expand` usually calls macro calls in a wide sense (including attributes and derives) "macro invocations", but structures and variants renamed in this PR are only relevant to fn-like macros, so it's simpler and clearer to just call them calls. cc https://github.com/rust-lang/rust/pull/63586#discussion_r314232513 r? @eddyb
2020-03-14rustc_metadata: Remove `rmeta::MacroDef`Vadim Petrochenkov-6/+6
Use `ast::MacroDef` instead. Also remove `Session::imported_macro_spans`, external macros have spans now.
2020-03-12ast: `Mac`/`Macro` -> `MacCall`Vadim Petrochenkov-6/+6
2020-03-12Rollup merge of #69674 - mark-i-m:assoc-fn, r=matthewjasperMazdak Farrokhzad-2/+2
Rename DefKind::Method and TraitItemKind::Method r? @eddyb, @Centril, or @matthewjasper cc #69498 #60163
2020-03-03rename TraitItemKind::Method -> FnMark Mansi-2/+2
2020-03-01ast: Unmerge structures for associated items and foreign itemsVadim Petrochenkov-14/+6
2020-02-29Rename `syntax` to `rustc_ast` in source codeVadim Petrochenkov-4/+4
2020-02-24parse/ast: move `Defaultness` into variants.Mazdak Farrokhzad-24/+24
2020-02-24add `Span` to `ast::Defaultness::Default`.Mazdak Farrokhzad-8/+4
2020-02-22parse: allow `type Foo: Ord` syntactically.Mazdak Farrokhzad-9/+9
2020-02-18Remove "not yet implemented" warningDylan MacKenzie-9/+1
2020-02-15parse extern constsMazdak Farrokhzad-0/+5
2020-02-15parse associated statics.Mazdak Farrokhzad-4/+9