-
Notifications
You must be signed in to change notification settings - Fork 13k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Compiler panic: "Path not fully resolved" when passing reference to impl function #22933
Comments
I'm also getting this error, but with an enum that depends on previous enum values, if the named value doesn't exist. Note that
Compiling it:
UPDATE: |
Same issue, when calling
|
I am also getting 'path not fully resolved', with this code: //use std::u8;
const FOO: [u32; u8::MIN as usize] = [];
fn main() {} Backtrace:
|
I think I have the same problem with the code in the gist: |
This issue mixes the expr_is_lval issue (#23173) with several associated const issues (which I think are duplicates - cc @quantheory for that). |
At least @nham's example is another case of #25145, i.e. we can't evaluated associated constants in array sizes in The example from @ahwatts is actually new to me. Without delving too deeply yet, I think that there must be a missing check for test_argl.rs:10:44: 10:58 error: no associated item named `PIE` found for type `Delicious` in the current scope
test_argl.rs:10 ApplePie = Delicious::Apple as isize | Delicious::PIE as isize, But then we end up panicking during @diogovk's issue is #23173 (@arielb1 got it right, but made a typo). Note also #25757 and #24322 for the function pointer issues. |
Isn't it nice when several distinct errors get the same issue? |
I created #26483 for the C-like enum variant issue. The others already have open issues, so perhaps this should just be closed as a duplicate now? |
Some more pattern cleanup and bugfixing The next part of #34095 The most significant fixed mistake is definitions for partially resolved associated types not being updated after full resolution. ``` fn f<T: Fn()>(arg: T::Output) { .... } // <- the definition of T::Output was not updated in def_map ``` For this reason unstable associated types of stable traits, like `FnOnce::Output`, could be used in stable code when written in unqualified form. Now they are properly checked, this is a **[breaking-change]** (pretty minor one, but a crater run would be nice). The fix is not to use unstable library features in stable code, alternatively `FnOnce::Output` can be stabilized. Besides that, paths in struct patterns and expressions `S::A { .. }` are now fully resolved as associated types. Such types cannot be identified as structs at the moment, i.e. the change doesn't make previously invalid code valid, but it improves error diagnostics. Other changes: `Def::Err` is supported better (less chances for ICEs for erroneous code), some incorrect error messages are corrected, some duplicated error messages are not reported, ADT definitions are now available through constructor IDs, everything else is cleanup and code audit. Fixes #34209 Closes #22933 (adds tests) r? @eddyb
I'm getting a compiler error about a "path not fully resolved":
I tried this code:
I expected to see this happen:
the code should compile, it did somewhere after 1.0 alpha and stopped in the last week (I think)
Instead, this happened:
I got this unexpected panic. It has something to do with passing the reference to
CNFParser::is_whitespace
Meta
rustc --version --verbose
:Backtrace:
The text was updated successfully, but these errors were encountered: