Skip to content

New shadowing rule, part 2 #26864

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

Merged
merged 3 commits into from
Aug 29, 2019

Conversation

slavapestov
Copy link
Contributor

Builds on #26791 by adding more shadowing rules to removeShadowedDecls() with the goal of eventually supplanting the shadowing done in ModuleNameLookup.

@slavapestov
Copy link
Contributor Author

@swift-ci Please smoke test

@slavapestov
Copy link
Contributor Author

@swift-ci Please test source compatibility

DeclName name, SmallVectorImpl<ValueDecl *> &decls,
NLKind lookupKind, ResolutionKind resolutionKind,
const DeclContext *moduleScopeContext,
ArrayRef<ModuleDecl::ImportedModule> extraImports = {});
const DeclContext *moduleScopeContext);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is moduleScopeContext ever different from moduleOrFile? Is the top level access path ever non-empty? Seems like there's still a simpler public interface here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, moduleScopeContext can be different. Eg when we do a qualified lookup into a module, we do sourceFile->lookupQualified(mod, ...) which passes sourceFile as moduleScopeContext, but mod as moduleOrFile.

As for the access path, it's used in one place to find a declaration but we use the declaration's name as the access path. I believe that's equivalent to having no access path.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, whoops, of course. I forgot this is for qualified lookup too, not just unqualified lookup. The access path thing does seem equivalent though.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another fun parameter here is lookupKind, which appears to be only used to implement the "hide weird Carbon symbols from Darwin module" thing.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also Builtin, but yeah.

This simulates the shadowing done by ModuleNameLookup, which is about to be
removed.

The basic idea is that top-level declarations found via scoped imports
take precedence over unscoped imports.
…e and extra imports

Also get rid of the 'accessPath' parameter.
@slavapestov slavapestov force-pushed the new-shadowing-rule-part-2 branch from 3d2d40b to 37f308b Compare August 29, 2019 01:12
@slavapestov
Copy link
Contributor Author

@swift-ci Please smoke test

@slavapestov
Copy link
Contributor Author

@swift-ci Please test source compatibility

@slavapestov slavapestov merged commit 016acf3 into swiftlang:master Aug 29, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants