fix #24968 more friend error message for Self in fn args
#25096
Conversation
|
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @nrc (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. The way Github handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see CONTRIBUTING.md for more information. |
|
Your message sounds like a type error. I would prefer one in the style of "use of Self outside of an impl". |
I've been working with some archives generated by MSVC's `lib.exe` tool lately, and it looks like the embedded name of the members in those archives sometimes have slahes in the name (e.g. `foo/bar/baz.obj`). Currently the compiler chokes on these paths as it assumes that each file in the archive is only the filename (which is what unix does). This commit interprets the name of each file in all archives as a path and then only uses the `file_name` portion of the path to extract the file to a separate location and then reassemble it back into a new archive later. Note that duplicate filenames are already handled, so this won't introduce any conflicts.
|
Hi @XuefengWu, thanks for the PR and sorry it took so long for me to get to it - I was on vacation last week. A high level thing is that this PR needs a test to check that we get the right error messages. You should add a test to the compile-fail directory which checks the message. More comments inline. |
| maybe_qself.is_none() && | ||
| path.segments[0].identifier.name == self_type_name; | ||
| let msg = if is_invalid_self_type_name { | ||
| "use of Self outside of an impl".to_string() |
There was a problem hiding this comment.
Self can also be used in a trait, so the message should include that. Also, you could add backticks around "Self".
We don't have any pending snapshot-requiring changes. Tests which continue to be ignored are those that are broken by codegen changes.
Also change several error messages to refer to "items" rather than "methods", since associated items that require resolution during type checking are not always methods.
This commit is an implementation of [RFC 1040][rfc] which is a redesign of the currently-unstable `Duration` type. The API of the type has been scaled back to be more conservative and it also no longer supports negative durations. [rfc]: https://github.com/rust-lang/rfcs/blob/master/text/1040-duration-reform.md The inner `duration` module of the `time` module has now been hidden (as `Duration` is reexported) and the feature name for this type has changed from `std_misc` to `duration`. All APIs accepting durations have also been audited to take a more flavorful feature name instead of `std_misc`. Closes rust-lang#24874
This also updates the error messages for both. For E0066, it removes mention of "managed heap", which was removed in 8a91d33. For E0069, I just tweaked the wording to make it a bit more explicit.
See: https://sourceware.org/bugzilla/show_bug.cgi?id=4887#c9 https://bugs.freedesktop.org/show_bug.cgi?id=65681 I just noticed this while talking to someone who was using `os.environ['FOO'] = 'BAR'` in Python and since I'm learning Rust, I was curious if it did anything special here. It looks like Rust has an internal mutex, which helps for apps that are pure Rust, but it will be an evil trap for someone later adding in native code (apps like Servo and games will be at risk). Java got this right by disallowing `setenv()` from the start. I suggest Rust program authors only use `setenv()` early in main.
…uity_message, r=nikomatsakis This fixes rust-lang#24922 and rust-lang#25017, and reduces the number of error messages that talk about "methods" when associated constants rather than methods are involved. I will admit that I haven't thought very carefully about the error messages. My goal has been to make more of the messages technically correct in all situations, and to avoid ICEs. But in some cases we could probably talk specifically about "methods" rather than "items".
…, r=brson I've been working with some archives generated by MSVC's `lib.exe` tool lately, and it looks like the embedded name of the members in those archives sometimes have slahes in the name (e.g. `foo/bar/baz.obj`). Currently the compiler chokes on these paths as it assumes that each file in the archive is only the filename (which is what unix does). This commit interprets the name of each file in all archives as a path and then only uses the `file_name` portion of the path to extract the file to a separate location and then reassemble it back into a new archive later. Note that duplicate filenames are already handled, so this won't introduce any conflicts.
…e-not-threadsafe, r=alexcrichton See: https://sourceware.org/bugzilla/show_bug.cgi?id=4887#c9 https://bugs.freedesktop.org/show_bug.cgi?id=65681 I just noticed this while talking to someone who was using `os.environ['FOO'] = 'BAR'` in Python and since I'm learning Rust, I was curious if it did anything special here (and the answer appears to be no). Java got this right by disallowing `setenv()` from the start.
…ichton We don't have any pending snapshot-requiring changes. Closes rust-lang#20184. Works toward rust-lang#3965.
rustbook throws errors if the `_book` folder exists already. Common if you build twice in a row. Identical to https://github.com/steveklabnik/rustbook/issues/20
…-typo, r=steveklabnik I fixed the typo of the value of e in the memory tables. It is a reference to d, and so it should contain the memory location of d. I also fixed the incorrectly formatted tables so they display properly in html pages.
Every time I profile my code I find something new to add #[inline] to. (:
It seems to refer to something that used to exist, but got moved, and then not everything got cleaned up.
The assume intrinsic has a strong, negative impact on compile times, so we're currently only using it in places where LLVM can simplify it to nonnull metadata on a load intruction. Unfortunately a recent change that fixed invalid assume calls introduce new assume calls for which this simplification can not happen, leading to a massive regression in compile times in certain cases. Moving the assumptions from the middle of the function to the beginning allows the simplification to happen again, bringing compile times back to their old levels. Fixes rust-lang#25393
- Successful merges: rust-lang#25404, rust-lang#25405, rust-lang#25407, rust-lang#25408, rust-lang#25410, rust-lang#25412, rust-lang#25413, rust-lang#25414, rust-lang#25418, rust-lang#25420 - Failed merges:
Also start factoring out an API for compiler tools to use and fix a bug that was preventing DXR indexing Rust properly. r? @huonw
The assume intrinsic has a strong, negative impact on compile times, so we're currently only using it in places where LLVM can simplify it to nonnull metadata on a load intruction. Unfortunately a recent change that fixed invalid assume calls introduce new assume calls for which this simplification can not happen, leading to a massive regression in compile times in certain cases. Moving the assumptions from the middle of the function to the beginning allows the simplification to happen again, bringing compile times back to their old levels. Fixes rust-lang#25393
…rust into 24968_err_msg_parse_self_type
|
@nrc The change commit is: XuefengWu@eac661c |
|
@XuefengWu something has gone wrong with the Git history here. I'm afraid we can't merge this as is. On local branches, it is usually better to use |
|
r=me with the git history sorted and the two nits fixed. |
|
Closing in favour of #25485 |
fix #24968
report more friendly error message for
Selfwhen fn args