about summary refs log tree commit diff
path: root/compiler/rustc_resolve/src
AgeCommit message (Collapse)AuthorLines
2020-12-28Rollup merge of #80411 - petrochenkov:nosymwith, r=matthewjasperDylan DPC-1/+4
rustc_span: Remove `Symbol::with` A subset of https://github.com/rust-lang/rust/pull/79425 that is a pure refactoring.
2020-12-28Rollup merge of #80344 - matthiaskrgr:matches, r=Dylan-DPCDylan DPC-11/+8
use matches!() macro in more places
2020-12-27rustc_span: Remove `Symbol::with`Vadim Petrochenkov-1/+4
2020-12-26stabilize min_const_genericsBastian Kauschke-7/+15
2020-12-24use matches!() macro in more placesMatthias Krüger-11/+8
2020-12-20Move std_path construction into conditionDániel Buga-5/+4
2020-12-20Inline a single-use closureDániel Buga-2/+2
2020-12-20Create closure outside of the loopDániel Buga-4/+4
2020-12-20Add missing semicolonDániel Buga-1/+1
2020-12-20Remove unnecessary clonedDániel Buga-1/+1
2020-12-20Precompute vector length in smart_resolve_path_fragmentDániel Buga-1/+2
2020-12-20Clean up with_generic_param_rib, avoid double hashingDániel Buga-24/+17
2020-12-17Enhance error message when misspelled label to value in break expressionDaiki Ihara-0/+20
Apply suggestions from code review Co-authored-by: lcnr <bastian_kauschke@hotmail.de>
2020-12-12Resolve enum field visibility correctlyCamelid-1/+11
Previously, this code treated enum fields' visibility as if they were struct fields. However, that's not correct because the visibility of a struct field with `ast::VisibilityKind::Inherited` is private to the module it's defined in, whereas the visibility of an *enum* field with `ast::VisibilityKind::Inherited` is the visibility of the enum it belongs to.
2020-12-02Tweak diagnostics on shadowing lifetimes/labelsYuki Okushi-1/+1
2020-11-26Remove ForeignMod struct.Camille GILLOT-1/+1
2020-11-24Move lev_distance to rustc_ast, make non-genericArlie Davis-28/+33
rustc_ast currently has a few dependencies on rustc_lexer. Ideally, an AST would not have any dependency its lexer, for minimizing unnecessarily design-time dependencies. Breaking this dependency would also have practical benefits, since modifying rustc_lexer would not trigger a rebuild of rustc_ast. This commit does not remove the rustc_ast --> rustc_lexer dependency, but it does remove one of the sources of this dependency, which is the code that handles fuzzy matching between symbol names for making suggestions in diagnostics. Since that code depends only on Symbol, it is easy to move it to rustc_span. It might even be best to move it to a separate crate, since other tools such as Cargo use the same algorithm, and have simply contain a duplicate of the code. This changes the signature of find_best_match_for_name so that it is no longer generic over its input. I checked the optimized binaries, and this function was duplicated at nearly every call site, because most call sites used short-lived iterator chains, generic over Map and such. But there's no good reason for a function like this to be generic, since all it does is immediately convert the generic input (the Iterator impl) to a concrete Vec<Symbol>. This has all of the costs of generics (duplicated method bodies) with no benefit. Changing find_best_match_for_name to be non-generic removed about 10KB of code from the optimized binary. I know it's a drop in the bucket, but we have to start reducing binary size, and beginning to tame over-use of generics is part of that.
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.
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2025-11-07 21:02:43 +0000