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

during the lookup for a base class name, non-type names should be ignored #16855

Closed
llvmbot opened this issue Jun 28, 2013 · 2 comments · Fixed by #112166
Closed

during the lookup for a base class name, non-type names should be ignored #16855

llvmbot opened this issue Jun 28, 2013 · 2 comments · Fixed by #112166
Labels
bugzilla Issues migrated from bugzilla c++ clang:frontend Language frontend issues, e.g. anything involving "Sema"

Comments

@llvmbot
Copy link
Member

llvmbot commented Jun 28, 2013

Bugzilla Link 16481
Version 3.2
OS Windows NT
Reporter LLVM Bugzilla Contributor
CC @DougGregor

Extended Description

[class.derived]p2 says:

"During the lookup for a base class name, non-type names are ignored."

So clang should compile this program:

struct x
{};

namespace
{
    namespace x
    {
        struct y : x
        {};
    }
}
@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 9, 2021
@Endilll Endilll added the clang:frontend Language frontend issues, e.g. anything involving "Sema" label Nov 3, 2023
@llvmbot
Copy link
Member Author

llvmbot commented Nov 3, 2023

@llvm/issue-subscribers-clang-frontend

Author: None (llvmbot)

| | | | --- | --- | | Bugzilla Link | [16481](https://llvm.org/bz16481) | | Version | 3.2 | | OS | Windows NT | | Reporter | LLVM Bugzilla Contributor | | CC | @DougGregor |

Extended Description

[class.derived]p2 says:

"During the lookup for a base class name, non-type names are ignored."

So clang should compile this program:

struct x
{};

namespace
{
namespace x
{
struct y : x
{};
}
}

@shafik
Copy link
Collaborator

shafik commented Nov 4, 2023

It looks like we have a FIXME for this:

// FIXME: LookupNestedNameSpecifierName isn't the right kind of
// lookup for class-names.
LookupNameKind Kind = isClassName ? LookupNestedNameSpecifierName :
LookupOrdinaryName;
LookupResult Result(*this, &II, NameLoc, Kind);

from 9025ec2

CC @zygoloid who might know of how to fix this correctly

Note:

During the lookup for a base class name, non-type names are ignored.

is not in the standard anymore but it is not clear what replaced it.

spaits added a commit to spaits/llvm-project that referenced this issue Oct 14, 2024
This PR would fix llvm#16855 .

I think the correct lookup to use for class names is Tag name lookup,
because it does not take namespaces into account. The current lookup
does and because of this some valid programs are not accepted.

If you think that Tag name lookup is not correct for all cases when
we are looking up types based on class names then we can only
do tag name lookup when looking up class names for inheritance.
In case of inheritance:
```
[class.derived]p2 says:

"During the lookup for a base class name, non-type names are ignored."
```
spaits added a commit to spaits/llvm-project that referenced this issue Oct 14, 2024
This PR would fix llvm#16855 .

I think the correct lookup to use for class names is Tag name lookup,
because it does not take namespaces into account. The current lookup
does and because of this some valid programs are not accepted.

If you think that Tag name lookup is not correct for all cases when
we are looking up types based on class names then we can only
do tag name lookup when looking up class names for inheritance.
In case of inheritance:
```
[class.derived]p2 says:

"During the lookup for a base class name, non-type names are ignored."
```
spaits added a commit to spaits/llvm-project that referenced this issue Oct 14, 2024
This PR would fix llvm#16855 .

I think the correct lookup to use for class names is Tag name lookup,
because it does not take namespaces into account. The current lookup
does and because of this some valid programs are not accepted.

If you think that Tag name lookup is not correct for all cases when
we are looking up types based on class names then we can only
do tag name lookup when looking up class names for inheritance.
In case of inheritance:
```
[class.derived]p2 says:

"During the lookup for a base class name, non-type names are ignored."
```
spaits added a commit to spaits/llvm-project that referenced this issue Oct 15, 2024
This PR would fix llvm#16855 .

I think the correct lookup to use for class names is Tag name lookup,
because it does not take namespaces into account. The current lookup
does and because of this some valid programs are not accepted.

If you think that Tag name lookup is not correct for all cases when
we are looking up types based on class names then we can only
do tag name lookup when looking up class names for inheritance.
In case of inheritance:
```
[class.derived]p2 says:

"During the lookup for a base class name, non-type names are ignored."
```
@spaits spaits closed this as completed in 4852120 Oct 15, 2024
DanielCChen pushed a commit to DanielCChen/llvm-project that referenced this issue Oct 16, 2024
This PR would fix llvm#16855 .

The correct lookup to use for class names is Tag name lookup,
because it does not take namespaces into account. The lookup before
does and because of this some valid programs are not accepted.

An example scenario of a valid program being declined is when you have a struct (let's call it `y`) inheriting from another struct with a name `x` but the struct `y` is in a namespace that is also called `x`:
```
struct x
{};

namespace
{
    namespace x
    {
        struct y : x
        {};
    }
}
```

This shall be accepted because: 
```
C++ [class.derived]p2 (wrt lookup in a base-specifier): The lookup for
  // the component name of the type-name or simple-template-id is type-only.
```
bricknerb pushed a commit to bricknerb/llvm-project that referenced this issue Oct 17, 2024
This PR would fix llvm#16855 .

The correct lookup to use for class names is Tag name lookup,
because it does not take namespaces into account. The lookup before
does and because of this some valid programs are not accepted.

An example scenario of a valid program being declined is when you have a struct (let's call it `y`) inheriting from another struct with a name `x` but the struct `y` is in a namespace that is also called `x`:
```
struct x
{};

namespace
{
    namespace x
    {
        struct y : x
        {};
    }
}
```

This shall be accepted because: 
```
C++ [class.derived]p2 (wrt lookup in a base-specifier): The lookup for
  // the component name of the type-name or simple-template-id is type-only.
```
EricWF pushed a commit to efcs/llvm-project that referenced this issue Oct 22, 2024
This PR would fix llvm#16855 .

The correct lookup to use for class names is Tag name lookup,
because it does not take namespaces into account. The lookup before
does and because of this some valid programs are not accepted.

An example scenario of a valid program being declined is when you have a struct (let's call it `y`) inheriting from another struct with a name `x` but the struct `y` is in a namespace that is also called `x`:
```
struct x
{};

namespace
{
    namespace x
    {
        struct y : x
        {};
    }
}
```

This shall be accepted because: 
```
C++ [class.derived]p2 (wrt lookup in a base-specifier): The lookup for
  // the component name of the type-name or simple-template-id is type-only.
```
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bugzilla Issues migrated from bugzilla c++ clang:frontend Language frontend issues, e.g. anything involving "Sema"
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants