summary refs log tree commit diff
path: root/compiler/rustc_resolve/src/late
AgeCommit message (Collapse)AuthorLines
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-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-4/+5
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-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-08rustc_resolve: Use `#![feature(format_args_capture)]`Vadim Petrochenkov-1/+1
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-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-01Auto merge of #78420 - estebank:suggest-assoc-fn, r=petrochenkovbors-11/+47
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-30Fix even more clippy warningsJoshua Nelson-34/+20
2020-10-26Suggest calling associated `fn` inside `trait`sEsteban Küber-11/+47
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-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>
2020-10-09address review commentsEsteban Küber-8/+16
2020-10-09Given `<T as Trait>::A: Ty` suggest `T: Trait<A = Ty>`Esteban Küber-0/+118
Fix #75829
2020-10-09Suggest removing bounds even when potential typoEsteban Küber-15/+21
2020-10-09Tweak output and add test casesEsteban Küber-5/+51
2020-10-09Point out why a trait is expected on `Struct + 'lt`Esteban Küber-1/+10
2020-10-07Auto merge of #77341 - davidtwco:issue-73427-you-might-have-meant-variant, ↵bors-21/+124
r=estebank resolve: improve "try using the enum's variant" Fixes #73427. This PR improves the "try using the enum's variant" suggestion: - Variants in suggestions would not result in more errors (e.g. use of a struct variant is only suggested if the suggestion can trivially construct that variant). Therefore, suggestions are only emitted for variants that have no fields (since the suggestion can't know what value fields would have). - Suggestions include the syntax for constructing the variant. If a struct or tuple variant is suggested, then it is constructed in the suggestion - unless in pattern-matching or when arguments are already provided. - A help message is added which mentions the variants which are no longer suggested. All of the diagnostic logic introduced by this PR is separated from the normal code path for a successful compilation. r? `@estebank`
2020-10-02resolve: prohibit anon const non-static lifetimesDavid Wood-0/+33
This commit modifies name resolution to emit an error when non-static lifetimes are used in anonymous constants when the `min_const_generics` feature is enabled. Signed-off-by: David Wood <david@davidtw.co>
2020-09-29resolve: improve "try using the enum's variant"David Wood-21/+124
This commit improves the "try using the enum's variant" suggestion: - Variants in suggestions would not result in more errors (e.g. use of a struct variant is only suggested if the suggestion can trivially construct that variant). Therefore, suggestions are only emitted for variants that have no fields (since the suggestion can't know what value fields would have). - Suggestions include the syntax for constructing the variant. If a struct or tuple variant is suggested, then it is constructed in the suggestion - unless in pattern-matching or when arguments are already provided. - A help message is added which mentions the variants which are no longer suggested. Signed-off-by: David Wood <david@davidtw.co>
2020-09-17use strip_prefix over starts_with and manual slicing based on pattern length ↵Matthias Krüger-2/+2
(clippy::manual_strip)
2020-09-15fix a couple of stylistic clippy warningsMatthias Krüger-1/+1
namely: clippy::redundant_pattern_matching clippy::redundant_pattern clippy::search_is_some clippy::filter_next clippy::into_iter_on_ref clippy::clone_on_copy clippy::needless_return
2020-09-11Auto merge of #76499 - guswynn:priv_des, r=petrochenkovbors-10/+45
Give better diagnostic when using a private tuple struct constructor Fixes #75907 Some notes: 1. This required some deep changes, including removing a Copy impl for PatKind. If some tests fail, I would still appreciate review on the overall approach 2. this only works with basic patterns (no wildcards for example), and fails if there is any problems getting the visibility of the fields (i am not sure what the failure that can happen in resolve_visibility_speculative, but we check the length of our fields in both cases against each other, so if anything goes wrong, we fall back to the worse error. This could be extended to more patterns 3. this does not yet deal with #75906, but I believe it will be similar 4. let me know if you want more tests 5. doesn't yet at the suggestion that `@yoshuawuyts` suggested at the end of their issue, but that could be added relatively easily (i believe)
2020-09-11Give better diagnostic when using a private tuple struct constructorGus Wynn-10/+45
2020-09-10Attach `TokenStream` to `ast::Path`Aaron Hill-2/+4
2020-09-09remove redundant clonesMatthias Krüger-1/+1
(clippy::redundant_clone)
2020-08-30Suggest `if let x = y` when encountering `if x = y`Esteban Küber-0/+13
Detect potential cases where `if let` was meant but `let` was left out. Fix #44990.
2020-08-30mv compiler to compiler/mark-0/+4458
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-07-13 11:12:28 +0000