Bug 263154 - Class instance members are resolved inside static methods
Summary: Class instance members are resolved inside static methods
Status: NEW
Alias: None
Product: CDT
Classification: Tools
Component: cdt-parser (show other bugs)
Version: 5.0.1   Edit
Hardware: PC Linux
: P3 normal with 1 vote (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact: Jonah Graham CLA
URL:
Whiteboard:
Keywords:
: 318599 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-01-31 18:48 EST by Sergey Prigogin CLA
Modified: 2020-09-04 15:23 EDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sergey Prigogin CLA 2009-01-31 18:48:00 EST
struct A {
  int a;
  static void m() {
    a = 0; // a is resolved, but it shouldn't be.
  }
};
Comment 1 Sergey Prigogin CLA 2010-07-01 12:33:28 EDT
*** Bug 318599 has been marked as a duplicate of this bug. ***
Comment 2 Markus Schorn CLA 2010-07-02 03:15:39 EDT
The name look-up itself is correct, 'a' does resolve to the non-static field although the use in this context is illegal. Similar to the accessibility, we can ignore the illegal usage for the purpose of creating the correct AST. 

From a tooling perspective the resolved variable adds value, because you can navigate it. This is for instance necessary if you want to make it static. (It also helps if you want to implement a quick-fix).

--> I'd argue the illegal usage should be detected by codan, rather than the parser.
Comment 3 Sergey Prigogin CLA 2010-07-02 12:53:08 EDT
(In reply to comment #2)
> --> I'd argue the illegal usage should be detected by codan, rather than the
> parser.

I agree that deferring the check to codan and context assist is the best solution. This is the approach that is already taken for visibility checks. It works there pretty well. We just have to make sure that the actual code that implements the check is shared between context assist and codan.
Comment 4 Markus Schorn CLA 2010-07-05 04:19:46 EDT
(In reply to comment #3)
> ... We just have to make sure that the actual code that
> implements the check is shared between context assist and codan.

It'd make sense to me to have the implementation for checkers that require semantics somewhere in the parser packages. It's likely that we can provide better implementations there. There should probably be a parser mechanism to detect all constructs that are illegal by the standard. (e.g.: this bug, accessibility, illegal assignments, illegal combination of decl specifiers, ...).

This could be a single operation on the AST, something like:
IASTProblem[] IASTTranslationUnit.computeProblems(EnumSet whichProblems, IProgressMonitor monitor);