Skip to content
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

ICE on resolve error inside impl block #14254

Closed
alexcrichton opened this issue May 17, 2014 · 4 comments
Closed

ICE on resolve error inside impl block #14254

alexcrichton opened this issue May 17, 2014 · 4 comments
Labels
A-resolve Area: Path resolution I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️

Comments

@alexcrichton
Copy link
Member

trait Foo {}        
impl Foo for *int { 
    fn foo() {      
        try_finally 
    }               
}                  
error: internal compiler error: unexpected failure
note: the compiler hit an unexpected failure path. this is a bug.
note: we would appreciate a bug report: http://static.rust-lang.org/doc/master/complement-bugreport.html
note: run with `RUST_BACKTRACE=1` for a backtrace
task 'rustc' failed at 'internal error: entered unreachable code', /Users/rustbuild/src/rust-buildbot/slave/nightly-mac/build/src/librustc/middle/resolve.rs:4937
stack backtrace:
   1:        0x103faac8b - rt::backtrace::imp::write::h6bf09e1ae0cfa18aoBz::v0.11.0.pre
   2:        0x103f2deb1 - rt::unwind::begin_unwind_inner::he3bc737d2c39ab1cwbz::v0.11.0.pre
   3:        0x101127aed - rt::unwind::begin_unwind::h7336716533461090442::v0.11.0.pre
   4:        0x10130c086 - middle::resolve::Resolver<'a>::resolve_expr::hfb7d6b3fa4ebd679nqY::v0.11.0.pre
   5:        0x101363fe0 - visit::walk_expr_opt::h4994540791083417155::v0.11.0.pre
   6:        0x101309a07 - middle::resolve::Resolver<'a>::resolve_block::hc32272e12cab421fP6W::v0.11.0.pre
   7:        0x10135a4f0 - middle::resolve::Resolver<'a>::resolve_function::closure.67175
   8:        0x10132e4a2 - middle::resolve::Resolver<'a>::with_type_parameter_rib::h9764680d6cf0a5cfEsW::v0.11.0.pre
   9:        0x101358981 - middle::resolve::Resolver<'a>::resolve_function::he939ff208f5c8b222xW::v0.11.0.pre
  10:        0x101361648 - middle::resolve::Resolver<'a>::resolve_implementation::closure.67235
  11:        0x10136050b - middle::resolve::Resolver<'a>::with_current_self_type::h3499330292536224027::v0.11.0.pre
  12:        0x10135f5c0 - middle::resolve::Resolver<'a>::resolve_implementation::closure.67222
  13:        0x10132e4a2 - middle::resolve::Resolver<'a>::with_type_parameter_rib::h9764680d6cf0a5cfEsW::v0.11.0.pre
  14:        0x1013079f5 - middle::resolve::Resolver<'a>.Visitor<(*>::visit_item::h8b1e7ccb2dd9f731wnR::v0.11.0.pre
  15:        0x10135304f - visit::Visitor::visit_mod::h2842851125407229744::v0.11.0.pre
  16:        0x10137408f - middle::resolve::resolve_crate::h647ea4130a3795acMnZ::v0.11.0.pre
  17:        0x10192a229 - driver::driver::phase_3_run_analysis_passes::ha0ab5f4b406c3845eGi::v0.11.0.pre
  18:        0x101924a2c - driver::driver::compile_input::haef4dbe816a3a3b5Ovi::v0.11.0.pre
  19:        0x1019c9f22 - driver::run_compiler::h4ac009c6e4455c14y7k::v0.11.0.pre
  20:        0x1019c7f1d - driver::main_args::closure.93216
  21:        0x1019de4d7 - driver::monitor::closure.94392
  22:        0x1019d8c4b - task::TaskBuilder::try::closure.94159
  23:        0x1010dcadc - task::spawn_opts::closure.8022
  24:        0x103fa12a8 - rt::task::Task::run::closure.25589
  25:        0x103fd3c7c - rust_try
  26:        0x103fa1211 - rt::task::Task::run::h66725e9dd8f1993fq1w::v0.11.0.pre
  27:        0x1010dc93f - task::spawn_opts::closure.7994
  28:        0x103fa90c6 - rt::thread::thread_start::h14fb024f55211441TKx::v0.11.0.pre
  29:     0x7fff92309899 - _pthread_body
  30:     0x7fff9230972a - _pthread_struct_init

cc @Ryman, this is in the new resolve code for better error suggestions.

@alexcrichton alexcrichton added A-ARM and removed A-ARM labels May 17, 2014
@Ryman
Copy link
Contributor

Ryman commented May 17, 2014

@alexcrichton thanks, I expected some unhandled cases just didn't really know what would trigger them :)

I think additional tests are needed for resolve errors inside impls of:

  • *T -- TyPtr
  • &T -- TyRPtr?
  • Box<T> -TyBox (/ TyUniq?)
    These should be trivial to add.

I'm less sure about how to manage resolve suggestions for these, but having examples of impls for them would be neat to test with:

  • Vec<T> - TyVec? or is this covering &[...]? I would expect Vec<T> to be a TyPath?
  • [T,.. N] - TyFixedLenthVec?
  • (T, U) - TyTup?
  • TyBareFn/Proc/Closure

I'm assuming that we can't ever have an impl for TyNil, TyBot, TyTypeOf, TyInfer, or if we have, it's extremely specialised code that can probably do without specialised resolve errors.

@alexcrichton
Copy link
Member Author

It's probably fine to just bail out early on, adding methods to a non-enum or non-struct is pretty rare

@Ryman
Copy link
Contributor

Ryman commented May 17, 2014

Agreed, I'll test & fix the first three tomorrow or Sunday, and probably leave a note about the rest for the future.

@alexcrichton
Copy link
Member Author

Awesome, thanks!

@bors bors closed this as completed in ffe2686 May 20, 2014
bors added a commit to rust-lang-ci/rust that referenced this issue Jun 5, 2023
…=Veykril

Introduce macro sub-namespaces and `macro_use` prelude

This PR implements two mechanisms needed for correct macro name resolution: macro sub-namespace and `macro_use` prelude.

- [macro sub-namespaces][subns-ref]

  Macros have two sub-namespaces: one for function-like macro and the other for those in attributes (including custom derive macros). When we're resolving a macro name for function-like macro, we should ignore non-function-like macros, and vice versa.

  This helps resolve single-segment macro names because we can (and should, as rustc does) fallback to names in preludes when the name in the current module scope is in different sub-namespace.

- [`macro_use` prelude][prelude-ref]

  `#[macro_use]`'d extern crate declarations (including the standard library) bring their macros into scope, but they should not be prioritized over local macros (those defined in place and those explicitly imported).

  We have been bringing them into legacy (textual) macro scope, which has the highest precedence in name resolution. This PR introduces the `macro_use` prelude in crate-level `DefMap`s, whose precedence is lower than local macros but higher than the standard library prelude.

The first 3 commits are drive-by fixes/refactors.

Fixes rust-lang#8828 (prelude)
Fixes rust-lang#12505 (prelude)
Fixes rust-lang#12734 (prelude)
Fixes rust-lang#13683 (prelude)
Fixes rust-lang#13821 (prelude)
Fixes rust-lang#13974 (prelude)
Fixes rust-lang#14254 (namespace)

[subns-ref]: https://doc.rust-lang.org/reference/names/namespaces.html#sub-namespaces
[prelude-ref]: https://doc.rust-lang.org/reference/names/preludes.html#macro_use-prelude
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-resolve Area: Path resolution I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants