about summary refs log tree commit diff
path: root/compiler/rustc_resolve/src
AgeCommit message (Collapse)AuthorLines
2020-11-24Rollup merge of #79374 - mendess:const-param-expr-diagnostic, r=lcnrJonas Schievink-0/+1
Add note to use nightly when using expr in const generics As recommended by `@Icnr` in #73899 and in zulip, I've added a note saying that const expressions can be used in nightly. ``` error: generic parameters may not be used in const operations --> $DIR/issue-61935.rs:10:23 | 6 | Self:FooImpl<{N==0}> | ^ cannot perform const operation using `N` | = help: const parameters may only be used as standalone arguments, i.e. `N` = note: use feature(const_generics) and feature(const_evaluatable_checked) to enable this error: aborting due to previous error ``` I hope the note is well written :sweat_smile:
2020-11-24Swap note for helpmendess-1/+1
2020-11-24Requested changesmendess-1/+1
2020-11-24Add note to use nightly when using expr in const genericsmendess-0/+1
2020-11-24Auto merge of #79294 - petrochenkov:determ, r=varkorbors-9/+20
resolve: Do not put macros into `module.unexpanded_invocations` unless necessary Macro invocations in modules <sup>(*)</sup> need to be tracked because they can produce named items when expanded. We cannot give definite answer to queries like "does this module declare name `n`?" until all macro calls in that module are expanded. Previously we marked too many macros as potentially producing named items. E.g. in this example ```rust mod m { const C: u32 = line!(); } ``` `line!()` cannot emit any items into module `m`, but it was still marked. This PR fixes that and marks macro calls as "unexpanded in module" only if they can actually emit named items into that module. Diagnostics in UI test outputs have different order now because this change affects macro expansion order. <sup>*</sup> Any containers for named items are called modules in resolve (that includes blocks, traits and enums in addition to `mod` items).
2020-11-23Rollup merge of #79236 - lcnr:mcg-resolve-dsb, r=eddybJonas Schievink-1/+6
const_generics: assert resolve hack causes an error prevent the min_const_generics `HACK`s in resolve from triggering a fallback path which successfully compiles so that we don't have to worry about future compat issues when removing it r? `@eddyb` cc `@varkor`
2020-11-22resolve: Do not put macros into `module.unexpanded_invocations` unless necessaryVadim Petrochenkov-9/+20
2020-11-20update bug message for cgBastian Kauschke-1/+1
2020-11-20const_generics: assert resolve hack causes an errorBastian Kauschke-0/+5
2020-11-20rustc_expand: Mark inner `#![test]` attributes as soft-unstableVadim Petrochenkov-15/+14
2020-11-19resolve/expand: Misc cleanupVadim Petrochenkov-5/+1
2020-11-19resolve: Centralize some error reporting for unexpected macro resolutionsVadim Petrochenkov-40/+58
2020-11-19resolve: Introduce a separate `NonMacroAttrKind` for legacy derive helpersVadim Petrochenkov-18/+12
2020-11-18Rollup merge of #78999 - petrochenkov:deprid, r=eddybMara Bos-0/+1
stability: More precise location for deprecation lint on macros One missing piece of https://github.com/rust-lang/rust/pull/73178.
2020-11-15Rollup merge of #79034 - petrochenkov:mrscopes3, r=eddybJonas Schievink-36/+21
rustc_resolve: Make `macro_rules` scope chain compression lazy As suggested in https://github.com/rust-lang/rust/pull/78826#issuecomment-723420664.
2020-11-15Rollup merge of #77802 - jyn514:bootstrap-specific, r=nikomatsakisJonas Schievink-3/+2
Allow making `RUSTC_BOOTSTRAP` conditional on the crate name Motivation: This came up in the [Zulip stream](https://rust-lang.zulipchat.com/#narrow/stream/233931-t-compiler.2Fmajor-changes/topic/Require.20users.20to.20confirm.20they.20know.20RUSTC_.E2.80.A6.20compiler-team.23350/near/208403962) for https://github.com/rust-lang/compiler-team/issues/350. See also https://github.com/rust-lang/cargo/pull/6608#issuecomment-458546258; this implements https://github.com/rust-lang/cargo/issues/6627. The goal is for this to eventually allow prohibiting setting `RUSTC_BOOTSTRAP` in build.rs (https://github.com/rust-lang/cargo/issues/7088). ## User-facing changes - `RUSTC_BOOTSTRAP=1` still works; there is no current plan to remove this. - Things like `RUSTC_BOOTSTRAP=0` no longer activate nightly features. In practice this shouldn't be a big deal, since `RUSTC_BOOTSTRAP` is the opposite of stable and everyone uses `RUSTC_BOOTSTRAP=1` anyway. - `RUSTC_BOOTSTRAP=x` will enable nightly features only for crate `x`. - `RUSTC_BOOTSTRAP=x,y` will enable nightly features only for crates `x` and `y`. ## Implementation changes The main change is that `UnstableOptions::from_environment` now requires an (optional) crate name. If the crate name is unknown (`None`), then the new feature is not available and you still have to use `RUSTC_BOOTSTRAP=1`. In practice this means the feature is only available for `--crate-name`, not for `#![crate_name]`; I'm interested in supporting the second but I'm not sure how. Other major changes: - Added `Session::is_nightly_build()`, which uses the `crate_name` of the session - Added `nightly_options::match_is_nightly_build`, a convenience method for looking up `--crate-name` from CLI arguments. `Session::is_nightly_build()`should be preferred where possible, since it will take into account `#![crate_name]` (I think). - Added `unstable_features` to `rustdoc::RenderOptions` I'm not sure whether this counts as T-compiler or T-lang; _technically_ RUSTC_BOOTSTRAP is an implementation detail, but it's been used so much it seems like this counts as a language change too. r? `@joshtriplett` cc `@Mark-Simulacrum` `@hsivonen`
2020-11-14rustc_resolve: Make `macro_rules` scope chain compression lazyVadim Petrochenkov-36/+21
2020-11-13Auto merge of #78826 - petrochenkov:mrscopes2, r=eddybbors-29/+69
resolve: Collapse `macro_rules` scope chains on the fly Otherwise they grow too long and you have to endlessly walk through them when resolving macros or imports. Addresses https://rust-lang.zulipchat.com/#narrow/stream/247081-t-compiler.2Fperformance/topic/Slow.20Builtin.20Derives/near/215750815
2020-11-12stability: More precise location for deprecation lint on macrosVadim Petrochenkov-0/+1
2020-11-11Implement destructuring assignment for structs and slicesFabian Zaiser-3/+1
Co-authored-by: varkor <github@varkor.com>
2020-11-08Rollup merge of #78860 - petrochenkov:resolvefmt, r=Mark-SimulacrumMara Bos-38/+13
rustc_resolve: Use `#![feature(format_args_capture)]` This is the best new sugar for quite some time. (I only changed places that already used named arguments.)
2020-11-08rustc_resolve: Use `#![feature(format_args_capture)]`Vadim Petrochenkov-38/+13
2020-11-07Allow making `RUSTC_BOOTSTRAP` conditional on the crate nameJoshua Nelson-3/+2
The main change is that `UnstableOptions::from_environment` now requires an (optional) crate name. If the crate name is unknown (`None`), then the new feature is not available and you still have to use `RUSTC_BOOTSTRAP=1`. In practice this means the feature is only available for `--crate-name`, not for `#![crate_name]`; I'm interested in supporting the second but I'm not sure how. Other major changes: - Added `Session::is_nightly_build()`, which uses the `crate_name` of the session - Added `nightly_options::match_is_nightly_build`, a convenience method for looking up `--crate-name` from CLI arguments. `Session::is_nightly_build()`should be preferred where possible, since it will take into account `#![crate_name]` (I think). - Added `unstable_features` to `rustdoc::RenderOptions` There is a user-facing change here: things like `RUSTC_BOOTSTRAP=0` no longer active nightly features. In practice this shouldn't be a big deal, since `RUSTC_BOOTSTRAP` is the opposite of stable and everyone uses `RUSTC_BOOTSTRAP=1` anyway. - Add tests Check against `Cheat`, not whether nightly features are allowed. Nightly features are always allowed on the nightly channel. - Only call `is_nightly_build()` once within a function - Use booleans consistently for rustc_incremental Sessions can't be passed through threads, so `read_file` couldn't take a session. To be consistent, also take a boolean in `write_file_header`.
2020-11-07resolve: Collapse `macro_rules` scope chains on the flyVadim Petrochenkov-29/+69
2020-11-06Revert "Revert "resolve: Avoid "self-confirming" import resolutions in one ↵Mark Rousskov-2/+11
more case"" This reverts commit b20bce8ce54ea9d47c2e3eb0b17cbb6baf916ae2. It retains the test added in that commit as a check-pass test, intended to prevent future (unintentional) regressions.
2020-11-04fix a couple of clippy warnings:Matthias Krüger-3/+2
filter_next manual_strip redundant_static_lifetimes single_char_pattern unnecessary_cast unused_unit op_ref redundant_closure useless_conversion
2020-11-03Expand `NtExpr` tokens only in key-value attributesVadim Petrochenkov-22/+0
2020-11-01Auto merge of #78420 - estebank:suggest-assoc-fn, r=petrochenkovbors-27/+55
Suggest calling associated `fn` inside `trait`s When calling a function that doesn't exist inside of a trait's associated `fn`, and another associated `fn` in that trait has that name, suggest calling it with the appropriate fully-qualified path. Expand the label to be more descriptive. Prompted by the following user experience: https://users.rust-lang.org/t/cannot-find-function/50663
2020-10-30Add back missing commentsJoshua Nelson-0/+1
2020-10-30Fix even more clippy warningsJoshua Nelson-169/+91
2020-10-29Auto merge of #78508 - wesleywiser:optimize_visit_scopes, r=petrochenkovbors-4/+3
[resolve] Use `unwrap_or_else` instead of `unwrap_or` in a hot path This improves the performance of the `resolve_crate` function by 30% for a very large single file crate with auto-generated C bindings. cc `@rylev`
2020-10-29Rollup merge of #78224 - lcnr:repeat-expr, r=varkorYuki Okushi-18/+70
min_const_generics: allow ty param in repeat expr implements https://rust-lang.zulipchat.com/#narrow/stream/260443-project-const-generics/topic/repeat.20expressions Even with `min_const_generics` active, now keeps resulting in future compat warnings instead of hard errors. Const parameters, for example `[0; N + 1]`, still result in hard errors during resolve. ```rust #![allow(dead_code)] fn foo<T>() { [0; std::mem::size_of::<*mut T>()]; } struct Foo<T>(T); impl<T> Foo<T> { const ASSOC: usize = 4; fn test() { [0; Self::ASSOC]; } } ``` r? @varkor cc @petrochenkov
2020-10-28[resolve] Use `unwrap_or_else` instead of `unwrap_or` in a hot pathWesley Wiser-4/+3
This improves the performance of the `resolve_crate` function by 30% for a very large single file crate with auto-generated C bindings.
2020-10-26Suggest calling associated `fn` inside `trait`sEsteban Küber-27/+55
When calling a function that doesn't exist inside of a trait's associated `fn`, and another associated `fn` in that trait has that name, suggest calling it with the appropriate fully-qualified path. Expand the label to be more descriptive. Prompted by the following user experience: https://users.rust-lang.org/t/cannot-find-function/50663
2020-10-26resolve: private fields in tuple struct ctor diagDavid Wood-44/+61
This commit improves the diagnostic emitted when a tuple struct is being constructed which has private fields so that private fields are labelled and the message is improved. Signed-off-by: David Wood <david@davidtw.co>
2020-10-25Rollup merge of #77984 - Aaron1011:fix/macro-mod-weird-parent, r=petrochenkovYuki Okushi-7/+41
Compute proper module parent during resolution Fixes #75982 The direct parent of a module may not be a module (e.g. `const _: () = { #[path = "foo.rs"] mod foo; };`). To find the parent of a module for purposes of resolution, we need to walk up the tree until we hit a module or a crate root.
2020-10-25Auto merge of #77546 - lcnr:impl-trait-closure, r=eddybbors-4/+4
fix def collector for impl trait fixes #77329 We now consistently make `impl Trait` a hir owner, requiring some special casing for synthetic generic params. r? `@eddyb`
2020-10-24Compute proper module parent during resolutionAaron Hill-7/+41
Fixes #75982 The direct parent of a module may not be a module (e.g. `const _: () = { #[path = "foo.rs"] mod foo; };`). To find the parent of a module for purposes of resolution, we need to walk up the tree until we hit a module or a crate root.
2020-10-24resolve: Relax macro resolution consistency check to account for any errorsVadim Petrochenkov-4/+4
2020-10-22min_const_generics: allow ty param in repeat exprBastian Kauschke-18/+70
2020-10-22Auto merge of #78134 - bugadani:arena-nodrop, r=lcnrbors-7/+5
Use `DroplessArena` where we know the type doesn't need drop This PR uses a single `DroplessArena` in resolve instead of three separate `TypedArena`s. `DroplessArena` checks that the type indeed doesn't need drop, so in case the types change, this will result in visible failures.
2020-10-20Resolve: Use dropless arena for types that don't need dropDániel Buga-7/+5
2020-10-19Calculate visibilities once in resolveVadim Petrochenkov-81/+131
Then use them through a query based on resolver outputs
2020-10-18Rollup merge of #78048 - blyxxyz:e0424-improve-self-placement, r=lcnrYuki Okushi-3/+5
Suggest correct place to add `self` parameter when inside closure It would incorrectly suggest adding it as a parameter to the closure instead of the containing function. [For example](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=1936bcd1e5f981573386e0cee985c3c0): ``` help: add a `self` receiver parameter to make the associated `fn` a method | 5 | let _ = || self&self; | ^^^^^ ``` `DiagnosticMetadata.current_function` is only used for these messages so tweaking its behavior should be ok.
2020-10-17Suggest correct place to add `self` parameter when inside closureJan Verbeek-3/+5
It would incorrectly suggest adding it as a parameter to the closure instead of the containing function.
2020-10-17resolve: Do not put nonexistent crate `meta` into preludeVadim Petrochenkov-3/+0
2020-10-17Rollup merge of #77855 - ↵Yuki Okushi-62/+88
davidtwco:pr-77341-follow-up-non-constructable-variants, r=estebank resolve: further improvements to "try using the enum's variant" diagnostic Follow-up on https://github.com/rust-lang/rust/pull/77341#issuecomment-702738281. This PR improves the diagnostic modified in #77341 to suggest not only those variants which do not have fields, but those with fields (by suggesting with placeholders). In addition, the wording of the tuple-variant-only case is improved slightly. I've not made further changes to the tuple-variant-only case (e.g. to only suggest variants with the correct number of fields) because I don't think I have enough information to do so reliably (e.g. in the case where there is an attempt to construct a tuple variant, I have no information on how many fields were provided; and in the case of pattern matching, I only have a slice of spans and would need to check for things like `..` in those spans, which doesn't seem worth it). r? @estebank
2020-10-17Rollup merge of #75209 - Hirrolot:suggest-macro-imports, r=estebankYuki Okushi-0/+11
Suggest imports of unresolved macros Closes https://github.com/rust-lang/rust/issues/75191.
2020-10-15resolve: improve "try using tuple struct" messageDavid Wood-11/+11
This commit improves the tuple struct case added in rust-lang/rust#77341 so that the context is mentioned in more of the message. Signed-off-by: David Wood <david@davidtw.co>
2020-10-15resolve: suggest variants with placeholdersDavid Wood-60/+86
This commit improves the diagnostic modified in rust-lang/rust#77341 to suggest not only those variants which do not have fields, but those with fields (by suggesting with placeholders). Signed-off-by: David Wood <david@davidtw.co>
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-03-01 17:34:34 +0000