about summary refs log tree commit diff
path: root/src/librustc_resolve
AgeCommit message (Collapse)AuthorLines
2019-07-19hygiene: Tweak naming some moreVadim Petrochenkov-7/+7
2019-07-19Adjust other names after the `Mark` renamingVadim Petrochenkov-22/+22
2019-07-19libsyntax: Remove `Mark` into `ExpnId`Vadim Petrochenkov-58/+59
2019-07-18resolve: Support resolving macro paths without macro kind restrictionsVadim Petrochenkov-13/+15
2019-07-18resolve: Attempt to resolve unresolved paths in macro namespaceVadim Petrochenkov-17/+19
2019-07-18resolve: Move some common code into the scope visitorVadim Petrochenkov-142/+114
2019-07-18resolve: Visit all scopes to collect suggestion candidates for unresolved macrosVadim Petrochenkov-122/+230
2019-07-18resolve: Use `feature(custom_attribute)` fallback only if the feature is enabledVadim Petrochenkov-73/+3
Normally `#![feature(...)]` shouldn't change behavior, but custom attributes in particular are in the process of retirement, and we should not produce a message telling to enable them. It also helps with unifying diagnostics for unresolved macros.
2019-07-18resolve: Decouple scope visiting process from visitor actionsVadim Petrochenkov-138/+170
2019-07-18resolve: Rename `WhereToResolve` into `Scope`Vadim Petrochenkov-71/+79
Also move it into the crate root, it's no longer used for macros only
2019-07-18resolve: Move some diagnostic code into `diagnostics.rs`Vadim Petrochenkov-595/+600
2019-07-13Suggest assoc type on type not found in trait method definitionEsteban Küber-35/+70
2019-07-13Make `register_[long_]diagnostics` hygienicMatthew Jasper-1/+1
2019-07-11expand: Move "derive containers" into a separate `InvocationKind` variantVadim Petrochenkov-4/+4
`InvocationKind::Attr { attr: None, .. }` meaning something entirely different from a regular attribute was confusing as hell.
2019-07-11hygiene: Introduce a helper method for creating new expansionsVadim Petrochenkov-2/+5
Creating a fresh expansion and immediately generating a span from it is the most common scenario. Also avoid allocating `allow_internal_unstable` lists for derive markers repeatedly. And rename `ExpnInfo::with_unstable` to `ExpnInfo::allow_unstable`, seems to be a better fitting name.
2019-07-11resolve: Fix access to extern and stdlib prelude from opaque macrosVadim Petrochenkov-0/+2
Ok, it's hard to explain what happens, but identifier's hygienic contexts need to be "adjusted" to modules/scopes before they are resolved in them. To be resolved in all kinds on preludes the identifier needs to be adjusted to the root expansion (aka "no expansion"). Previously this was done for the `macro m() { ::my_crate::foo }` case, but forgotten for all other cases.
2019-07-11resolve: Divide macro path resolution into speculative and error reporting partsVadim Petrochenkov-56/+51
Also move macro stability checking closer to other checks performed on obtained resolutions. Tighten the stability spans as well, it is an error to *refer* to and unstable entity in any way, not only "call" it.
2019-07-11resolve: Include stdlib prelude into name lookup in macro namespaceVadim Petrochenkov-2/+2
This is going to be used when built-in macros are defined through libcore and made available to other crates through standard library prelude
2019-07-11resolve/expand: Catch macro kind mismatches early in resolveVadim Petrochenkov-1/+12
This way we are processing all of them in a single point, rather than separately for each syntax extension kind. Also, the standard expected/found wording is used.
2019-07-11resolve/expand: `resolve_macro_invocation` no longer returns determinate errorsVadim Petrochenkov-46/+45
It either returns the indeterminacy error, or valid (but perhaps dummy) `SyntaxExtension`. With this change enum `Determinacy` is no longer used in libsyntax and can be moved to resolve. The regressions in diagnosics are fixed in the next commits.
2019-07-11resolve: Make proc macro stubs less stubbyVadim Petrochenkov-45/+70
Create real working and registered (even if dummy) `SyntaxExtension`s for them. This improves error recovery and allows to avoid all special cases for proc macro stubs (except for the error on use, of course). The introduced dummy `SyntaxExtension`s can be used for any other inappropriately resolved macros as well.
2019-07-11def_collector: Simplify tracking of macro invocation parentsVadim Petrochenkov-57/+37
Avoid the tricky scheme with callbacks and keep the invocation parent data where it logically belongs - in `Definitions`. This also allows to create `InvocationData` entries in resolve when the data is actually ready, and remove cells and "uninitialized" variants from it.
2019-07-11hygiene: Reuse `MacroKind` in `ExpnKind`Vadim Petrochenkov-19/+19
Orthogonality and reuse are good.
2019-07-11expand: Get rid of `resolve_macro_path`Vadim Petrochenkov-7/+0
It was used to choose whether to apply derive markers like `#[rustc_copy_clone_marker]` or not, but it was called before all the data required for resolution is available, so it could work incorrectly in some corner cases (like user-defined derives name `Copy` or `Eq`). Delay the decision about markers until the proper resolution results are available instead.
2019-07-11Remove `MacroKind::ProcMacroStub`Vadim Petrochenkov-30/+27
It's internal to resolve and always results in `Res::Err` outside of resolve. Instead put `DefKind::Fn`s themselves into the macro namespace, it's ok. Proc macro stubs are items placed into macro namespase for functions that define proc macros. https://github.com/rust-lang/rust/pull/52383 The rustdoc test is changed because the old test didn't actually reproduce the ICE it was supposed to reproduce.
2019-07-10Rollup merge of #62393 - petrochenkov:notto-disu, r=Mark-SimulacrumMazdak Farrokhzad-20/+12
Fix pretty-printing of `$crate` (take 4) Pretty-print `$crate` as `crate` or `crate_name` in unstructured tokens like `a $crate c` in `foo!(a $crate c)`, but only if those tokens are printed as a part of AST pretty-printing, rather than as a standalone token stream. Fixes https://github.com/rust-lang/rust/issues/62325 Previous iterations - https://github.com/rust-lang/rust/pull/56647, https://github.com/rust-lang/rust/pull/57155, https://github.com/rust-lang/rust/pull/57915.
2019-07-09Resolve `$crate` in all hygienic contexts for pretty-pringingVadim Petrochenkov-20/+12
Stop visiting AST to discover those contexts, just iterate through hygiene data instead
2019-07-09Rollup merge of #62417 - alexreg:fix-self-in-type-alias, r=pnkfelixMazdak Farrokhzad-11/+1
Fix ICEs when `Self` is used in type aliases I think it is right just to disallow this at resolution stage rather than let typeck produce a cyclic error. This is in line with previous behaviour. There was probably no need at all for the change that introduced this bug in #57428, so I've simply reversed it. Fixes #62263, #62364, #62305. r? @eddyb
2019-07-07Rollup merge of #62042 - petrochenkov:macstab, r=matthewjasperMazdak Farrokhzad-24/+51
Support stability and deprecation checking for all macros RELNOTES: Deprecation attributes on macros now have effect. Fixes https://github.com/rust-lang/rust/issues/34079 Fixes https://github.com/rust-lang/rust/issues/49912 Unblocks https://github.com/rust-lang/rust/pull/62086 Unblocks https://github.com/rust-lang/rust/pull/61000
2019-07-07Address review comments + Fix rebaseVadim Petrochenkov-1/+1
2019-07-07syntax: Migrate built-in macros to the regular stability checkingVadim Petrochenkov-3/+10
2019-07-07Support deprecation checking for macrosVadim Petrochenkov-11/+26
2019-07-07resolve: Use standard stability diagnostics for macrosVadim Petrochenkov-8/+7
2019-07-07syntax: Keep full `Stability` in `SyntaxExtension`Vadim Petrochenkov-8/+10
2019-07-07resolve: Check stability for local macros as wellVadim Petrochenkov-11/+10
2019-07-07resolve/expand: Move macro stability checking to an earlier pointVadim Petrochenkov-3/+14
2019-07-07syntax: Remove `NodeId` from `SyntaxExtension`Vadim Petrochenkov-18/+12
2019-07-07rustc: Remove `dylib` crate type from most rustc cratesAlex Crichton-1/+1
Now that procedural macros no longer link transitively to libsyntax, this shouldn't be needed any more! This commit is an experiment in removing all dynamic libraries from rustc except for librustc_driver itself. Let's see how far we can get with that!
2019-07-06resolve: Reserve cfg/cfg_attr/derive only in attribute sub-namespaceVadim Petrochenkov-25/+32
2019-07-06`#[rustc_doc_only_macro]` -> `#[rustc_builtin_macro]`Vadim Petrochenkov-1/+1
2019-07-06Fixed ICEs.Alexander Regueiro-11/+1
2019-07-05Rollup merge of #62133 - petrochenkov:norustc, r=eddybMazdak Farrokhzad-14/+17
Feature gate `rustc` attributes harder Fixes https://github.com/rust-lang/rust/issues/62116
2019-07-05Rollup merge of #61545 - flip1995:internal_lints, r=oli-obkMazdak Farrokhzad-1/+0
Implement another internal lints cc #49509 This adds ~~two~~ one internal lint~~s~~: 1. LINT_PASS_IMPL_WITHOUT_MACRO: Make sure, that the `{declare,impl}_lint_pass` macro is used to implement lint passes. cc #59669 2. ~~USAGE_OF_TYCTXT_AND_SPAN_ARGS: item 2 on the list in #49509~~ ~~With 2. I wasn't sure, if this lint should be applied everywhere. That means a careful review of 0955835 would be great. Also 73fb9b4 allows this lint on some functions. Should I also apply this lint there?~~ TODO (not directly relevant for review): - [ ] https://github.com/rust-lang/rust/pull/59316#discussion_r280186517 (not sure yet, if this works or how to query for `rustc_private`, since it's not in [`Features`](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/feature_gate/struct.Features.html) :thinking: cc @eddyb) - [x] https://github.com/rust-lang/rust/pull/61735#discussion_r292389870 - [x] Check explicitly for the `{declare,impl}_lint_pass!` macros r? @oli-obk
2019-07-04Switch master to 1.38Mark Rousskov-1/+0
2019-07-04Rollup merge of #62258 - petrochenkov:idclean, r=CentrilMazdak Farrokhzad-3/+0
syntax: Unsupport `foo! bar { ... }` macros in the parser Their support in expansion was removed in https://github.com/rust-lang/rust/pull/61606. Also un-reserve `macro_rules` as a macro name, there's no ambiguity between `macro_rules` definitions and macro calls (it also wasn't reserved correctly). cc https://github.com/rust-lang-nursery/wg-grammar/issues/51
2019-07-04Rollup merge of #62249 - czipperz:use-mem-take-instead-of-replace-default, ↵Mazdak Farrokhzad-4/+5
r=dtolnay,Centril Use mem::take instead of mem::replace with default
2019-07-03Remove needless lifetimesJeremy Stucki-3/+3
2019-07-01Enable mem_take feature in relevant cratesChris Gregory-0/+1
2019-07-01Convert more usages overChris Gregory-4/+4
2019-07-01syntax: Unsupport `foo! bar { ... }` macros in the parserVadim Petrochenkov-3/+0
Unreserve `macro_rules` as a macro name
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-07-08 17:39:13 +0000