2014-08-07 18:04:21 +00:00
|
|
|
// Copyright (c) 2014, the Dart project authors. Please see the AUTHORS file
|
|
|
|
// for details. All rights reserved. Use of this source code is governed by a
|
|
|
|
// BSD-style license that can be found in the LICENSE file.
|
|
|
|
|
|
|
|
library test.context.directory.manager;
|
|
|
|
|
2015-02-17 22:47:34 +00:00
|
|
|
import 'dart:collection';
|
|
|
|
|
2014-08-07 18:04:21 +00:00
|
|
|
import 'package:analysis_server/src/context_manager.dart';
|
|
|
|
import 'package:analyzer/file_system/file_system.dart';
|
|
|
|
import 'package:analyzer/file_system/memory_file_system.dart';
|
2015-02-26 19:54:36 +00:00
|
|
|
import 'package:analyzer/instrumentation/instrumentation.dart';
|
2014-08-07 18:04:21 +00:00
|
|
|
import 'package:analyzer/src/generated/engine.dart';
|
2015-10-28 16:59:05 +00:00
|
|
|
import 'package:analyzer/src/generated/error.dart';
|
2014-08-07 18:04:21 +00:00
|
|
|
import 'package:analyzer/src/generated/source.dart';
|
2014-10-24 20:29:24 +00:00
|
|
|
import 'package:analyzer/src/generated/source_io.dart';
|
2015-07-19 05:18:30 +00:00
|
|
|
import 'package:package_config/packages.dart';
|
2014-08-07 18:04:21 +00:00
|
|
|
import 'package:path/path.dart';
|
2015-04-22 20:54:29 +00:00
|
|
|
import 'package:test_reflective_loader/test_reflective_loader.dart';
|
2014-08-07 18:04:21 +00:00
|
|
|
import 'package:unittest/unittest.dart';
|
|
|
|
|
|
|
|
import 'mocks.dart';
|
2015-08-05 15:13:28 +00:00
|
|
|
import 'utils.dart';
|
2014-08-07 18:04:21 +00:00
|
|
|
|
|
|
|
main() {
|
2015-08-05 15:13:28 +00:00
|
|
|
initializeTestEnvironment();
|
2015-07-13 17:20:13 +00:00
|
|
|
defineReflectiveTests(AbstractContextManagerTest);
|
2014-08-07 18:04:21 +00:00
|
|
|
}
|
|
|
|
|
2015-01-13 17:11:24 +00:00
|
|
|
@reflectiveTest
|
2015-07-13 17:20:13 +00:00
|
|
|
class AbstractContextManagerTest {
|
2015-02-17 22:47:34 +00:00
|
|
|
/**
|
|
|
|
* The name of the 'bin' directory.
|
|
|
|
*/
|
|
|
|
static const String BIN_NAME = 'bin';
|
2015-03-30 16:01:03 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* The name of the 'example' directory.
|
|
|
|
*/
|
|
|
|
static const String EXAMPLE_NAME = 'example';
|
|
|
|
|
2015-02-17 22:47:34 +00:00
|
|
|
/**
|
|
|
|
* The name of the 'lib' directory.
|
|
|
|
*/
|
|
|
|
static const String LIB_NAME = 'lib';
|
2015-03-30 16:01:03 +00:00
|
|
|
|
2015-02-17 22:47:34 +00:00
|
|
|
/**
|
|
|
|
* The name of the 'src' directory.
|
|
|
|
*/
|
|
|
|
static const String SRC_NAME = 'src';
|
|
|
|
|
|
|
|
/**
|
|
|
|
* The name of the 'test' directory.
|
|
|
|
*/
|
|
|
|
static const String TEST_NAME = 'test';
|
|
|
|
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
ContextManagerImpl manager;
|
|
|
|
|
|
|
|
TestContextManagerCallbacks callbacks;
|
2015-02-17 22:47:34 +00:00
|
|
|
|
2014-08-07 18:04:21 +00:00
|
|
|
MemoryResourceProvider resourceProvider;
|
2015-02-17 22:47:34 +00:00
|
|
|
|
2014-08-07 18:04:21 +00:00
|
|
|
MockPackageMapProvider packageMapProvider;
|
|
|
|
|
2015-07-06 20:06:33 +00:00
|
|
|
UriResolver packageResolver = null;
|
|
|
|
|
2014-08-07 18:04:21 +00:00
|
|
|
String projPath = '/my/proj';
|
|
|
|
|
2015-02-17 22:47:34 +00:00
|
|
|
String newFile(List<String> pathComponents, [String content = '']) {
|
|
|
|
String filePath = posix.joinAll(pathComponents);
|
|
|
|
resourceProvider.newFile(filePath, content);
|
|
|
|
return filePath;
|
|
|
|
}
|
|
|
|
|
|
|
|
String newFolder(List<String> pathComponents) {
|
|
|
|
String folderPath = posix.joinAll(pathComponents);
|
|
|
|
resourceProvider.newFolder(folderPath);
|
|
|
|
return folderPath;
|
|
|
|
}
|
|
|
|
|
2015-07-06 20:06:33 +00:00
|
|
|
UriResolver providePackageResolver(Folder folder) {
|
|
|
|
return packageResolver;
|
|
|
|
}
|
|
|
|
|
2014-08-07 18:04:21 +00:00
|
|
|
void setUp() {
|
|
|
|
resourceProvider = new MemoryResourceProvider();
|
|
|
|
packageMapProvider = new MockPackageMapProvider();
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
manager = new ContextManagerImpl(resourceProvider, providePackageResolver,
|
|
|
|
packageMapProvider, InstrumentationService.NULL_SERVICE);
|
2015-07-24 13:42:54 +00:00
|
|
|
callbacks = new TestContextManagerCallbacks(resourceProvider);
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
manager.callbacks = callbacks;
|
2014-08-07 18:04:21 +00:00
|
|
|
resourceProvider.newFolder(projPath);
|
2015-07-19 05:18:30 +00:00
|
|
|
}
|
|
|
|
|
2015-09-23 20:27:19 +00:00
|
|
|
test_analysis_options_parse_failure() async {
|
|
|
|
// Create files.
|
|
|
|
String libPath = newFolder([projPath, LIB_NAME]);
|
|
|
|
newFile([libPath, 'main.dart']);
|
|
|
|
String sdkExtPath = newFolder([projPath, 'sdk_ext']);
|
|
|
|
newFile([sdkExtPath, 'entry.dart']);
|
|
|
|
String sdkExtSrcPath = newFolder([projPath, 'sdk_ext', 'src']);
|
|
|
|
newFile([sdkExtSrcPath, 'part.dart']);
|
|
|
|
// Setup analysis options file with ignore list.
|
|
|
|
newFile(
|
|
|
|
[projPath, '.analysis_options'],
|
|
|
|
r'''
|
|
|
|
;
|
|
|
|
''');
|
|
|
|
// Setup context.
|
|
|
|
manager.setRoots(<String>[projPath], <String>[], <String, String>{});
|
|
|
|
|
|
|
|
// No error means success.
|
|
|
|
}
|
|
|
|
|
2015-07-23 18:03:44 +00:00
|
|
|
void test_contextsInAnalysisRoot_nestedContext() {
|
2015-08-05 15:13:28 +00:00
|
|
|
String subProjPath = posix.join(projPath, 'subproj');
|
2015-07-23 18:03:44 +00:00
|
|
|
Folder subProjFolder = resourceProvider.newFolder(subProjPath);
|
2015-08-05 15:13:28 +00:00
|
|
|
resourceProvider.newFile(
|
|
|
|
posix.join(subProjPath, 'pubspec.yaml'), 'contents');
|
|
|
|
String subProjFilePath = posix.join(subProjPath, 'file.dart');
|
2015-07-23 18:03:44 +00:00
|
|
|
resourceProvider.newFile(subProjFilePath, 'contents');
|
|
|
|
manager.setRoots(<String>[projPath], <String>[], <String, String>{});
|
|
|
|
// Make sure that there really are contexts for both the main project and
|
|
|
|
// the subproject.
|
|
|
|
Folder projFolder = resourceProvider.getFolder(projPath);
|
|
|
|
ContextInfo projContextInfo = manager.getContextInfoFor(projFolder);
|
|
|
|
expect(projContextInfo, isNotNull);
|
|
|
|
expect(projContextInfo.folder, projFolder);
|
|
|
|
ContextInfo subProjContextInfo = manager.getContextInfoFor(subProjFolder);
|
|
|
|
expect(subProjContextInfo, isNotNull);
|
|
|
|
expect(subProjContextInfo.folder, subProjFolder);
|
|
|
|
expect(projContextInfo.context != subProjContextInfo.context, isTrue);
|
|
|
|
// Check that contextsInAnalysisRoot() works.
|
|
|
|
List<AnalysisContext> contexts = manager.contextsInAnalysisRoot(projFolder);
|
|
|
|
expect(contexts, hasLength(2));
|
|
|
|
expect(contexts, contains(projContextInfo.context));
|
|
|
|
expect(contexts, contains(subProjContextInfo.context));
|
|
|
|
}
|
|
|
|
|
2015-10-28 16:59:05 +00:00
|
|
|
test_error_filter_analysis_option() async {
|
|
|
|
// Create files.
|
|
|
|
newFile(
|
|
|
|
[projPath, AnalysisEngine.ANALYSIS_OPTIONS_FILE],
|
|
|
|
r'''
|
|
|
|
analyzer:
|
|
|
|
errors:
|
|
|
|
unused_local_variable: ignore
|
|
|
|
''');
|
|
|
|
// Setup context.
|
|
|
|
manager.setRoots(<String>[projPath], <String>[], <String, String>{});
|
|
|
|
|
|
|
|
// Verify filter setup.
|
|
|
|
List<ErrorFilter> filters =
|
|
|
|
callbacks.currentContext.getConfigurationData(CONFIGURED_ERROR_FILTERS);
|
|
|
|
expect(filters, isNotNull);
|
|
|
|
expect(filters, hasLength(1));
|
|
|
|
expect(
|
|
|
|
filters.first(new AnalysisError(
|
|
|
|
new TestSource(), 0, 1, HintCode.UNUSED_LOCAL_VARIABLE, [
|
|
|
|
['x']
|
|
|
|
])),
|
|
|
|
isTrue);
|
|
|
|
}
|
|
|
|
|
|
|
|
test_error_filter_analysis_option_synonyms() async {
|
|
|
|
// Create files.
|
|
|
|
newFile(
|
|
|
|
[projPath, AnalysisEngine.ANALYSIS_OPTIONS_FILE],
|
|
|
|
r'''
|
|
|
|
analyzer:
|
|
|
|
errors:
|
|
|
|
unused_local_variable: ignore
|
|
|
|
ambiguous_import: false
|
|
|
|
''');
|
|
|
|
// Setup context.
|
|
|
|
manager.setRoots(<String>[projPath], <String>[], <String, String>{});
|
|
|
|
|
|
|
|
// Verify filter setup.
|
|
|
|
List<ErrorFilter> filters =
|
|
|
|
callbacks.currentContext.getConfigurationData(CONFIGURED_ERROR_FILTERS);
|
|
|
|
expect(filters, isNotNull);
|
|
|
|
expect(filters, hasLength(2));
|
|
|
|
}
|
|
|
|
|
|
|
|
test_error_filter_analysis_option_unpsecified() async {
|
|
|
|
// Create files.
|
|
|
|
newFile(
|
|
|
|
[projPath, AnalysisEngine.ANALYSIS_OPTIONS_FILE],
|
|
|
|
r'''
|
|
|
|
analyzer:
|
|
|
|
# errors:
|
|
|
|
# unused_local_variable: ignore
|
|
|
|
''');
|
|
|
|
// Setup context.
|
|
|
|
manager.setRoots(<String>[projPath], <String>[], <String, String>{});
|
|
|
|
|
|
|
|
// Verify filter setup.
|
|
|
|
List<ErrorFilter> filters =
|
|
|
|
callbacks.currentContext.getConfigurationData(CONFIGURED_ERROR_FILTERS);
|
|
|
|
expect(filters, isEmpty);
|
|
|
|
}
|
|
|
|
|
2014-08-07 18:04:21 +00:00
|
|
|
test_ignoreFilesInPackagesFolder() {
|
|
|
|
// create a context with a pubspec.yaml file
|
|
|
|
String pubspecPath = posix.join(projPath, 'pubspec.yaml');
|
|
|
|
resourceProvider.newFile(pubspecPath, 'pubspec');
|
|
|
|
// create a file in the "packages" folder
|
|
|
|
String filePath1 = posix.join(projPath, 'packages', 'file1.dart');
|
|
|
|
resourceProvider.newFile(filePath1, 'contents');
|
|
|
|
// "packages" files are ignored initially
|
2014-10-23 00:11:36 +00:00
|
|
|
manager.setRoots(<String>[projPath], <String>[], <String, String>{});
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
expect(callbacks.currentContextFilePaths[projPath], isEmpty);
|
2014-08-07 18:04:21 +00:00
|
|
|
// "packages" files are ignored during watch
|
|
|
|
String filePath2 = posix.join(projPath, 'packages', 'file2.dart');
|
|
|
|
resourceProvider.newFile(filePath2, 'contents');
|
|
|
|
return pumpEventQueue().then((_) {
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
expect(callbacks.currentContextFilePaths[projPath], isEmpty);
|
2014-08-07 18:04:21 +00:00
|
|
|
});
|
|
|
|
}
|
|
|
|
|
2014-08-08 19:42:07 +00:00
|
|
|
void test_isInAnalysisRoot_excluded() {
|
|
|
|
// prepare paths
|
|
|
|
String project = '/project';
|
|
|
|
String excludedFolder = '$project/excluded';
|
|
|
|
// set roots
|
|
|
|
resourceProvider.newFolder(project);
|
|
|
|
resourceProvider.newFolder(excludedFolder);
|
2014-11-17 22:23:53 +00:00
|
|
|
manager.setRoots(
|
2015-03-02 22:43:12 +00:00
|
|
|
<String>[project], <String>[excludedFolder], <String, String>{});
|
2014-08-08 19:42:07 +00:00
|
|
|
// verify
|
|
|
|
expect(manager.isInAnalysisRoot('$excludedFolder/test.dart'), isFalse);
|
|
|
|
}
|
|
|
|
|
2015-07-23 18:03:44 +00:00
|
|
|
void test_isInAnalysisRoot_inNestedContext() {
|
2015-08-05 15:13:28 +00:00
|
|
|
String subProjPath = posix.join(projPath, 'subproj');
|
2015-07-23 18:03:44 +00:00
|
|
|
Folder subProjFolder = resourceProvider.newFolder(subProjPath);
|
2015-08-05 15:13:28 +00:00
|
|
|
resourceProvider.newFile(
|
|
|
|
posix.join(subProjPath, 'pubspec.yaml'), 'contents');
|
|
|
|
String subProjFilePath = posix.join(subProjPath, 'file.dart');
|
2015-07-23 18:03:44 +00:00
|
|
|
resourceProvider.newFile(subProjFilePath, 'contents');
|
|
|
|
manager.setRoots(<String>[projPath], <String>[], <String, String>{});
|
|
|
|
// Make sure that there really is a context for the subproject.
|
|
|
|
ContextInfo subProjContextInfo = manager.getContextInfoFor(subProjFolder);
|
|
|
|
expect(subProjContextInfo, isNotNull);
|
|
|
|
expect(subProjContextInfo.folder, subProjFolder);
|
|
|
|
// Check that isInAnalysisRoot() works.
|
|
|
|
expect(manager.isInAnalysisRoot(subProjFilePath), isTrue);
|
|
|
|
}
|
|
|
|
|
2014-08-07 18:04:21 +00:00
|
|
|
void test_isInAnalysisRoot_inRoot() {
|
2014-10-23 00:11:36 +00:00
|
|
|
manager.setRoots(<String>[projPath], <String>[], <String, String>{});
|
2014-08-07 18:04:21 +00:00
|
|
|
expect(manager.isInAnalysisRoot('$projPath/test.dart'), isTrue);
|
|
|
|
}
|
|
|
|
|
|
|
|
void test_isInAnalysisRoot_notInRoot() {
|
2014-10-23 00:11:36 +00:00
|
|
|
manager.setRoots(<String>[projPath], <String>[], <String, String>{});
|
2014-08-07 18:04:21 +00:00
|
|
|
expect(manager.isInAnalysisRoot('/test.dart'), isFalse);
|
|
|
|
}
|
|
|
|
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
test_path_filter() async {
|
|
|
|
// Setup context.
|
|
|
|
Folder root = resourceProvider.newFolder(projPath);
|
|
|
|
manager.setRoots(<String>[projPath], <String>[], <String, String>{});
|
|
|
|
expect(callbacks.currentContextFilePaths[projPath], isEmpty);
|
|
|
|
// Set ignore patterns for context.
|
2015-07-21 22:06:11 +00:00
|
|
|
ContextInfo rootInfo = manager.getContextInfoFor(root);
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
manager.setIgnorePatternsForContext(
|
2015-07-21 22:06:11 +00:00
|
|
|
rootInfo, ['sdk_ext/**', 'lib/ignoreme.dart']);
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
// Start creating files.
|
|
|
|
newFile([projPath, ContextManagerImpl.PUBSPEC_NAME]);
|
|
|
|
String libPath = newFolder([projPath, LIB_NAME]);
|
|
|
|
newFile([libPath, 'main.dart']);
|
|
|
|
newFile([libPath, 'ignoreme.dart']);
|
|
|
|
String sdkExtPath = newFolder([projPath, 'sdk_ext']);
|
|
|
|
newFile([sdkExtPath, 'entry.dart']);
|
|
|
|
String sdkExtSrcPath = newFolder([projPath, 'sdk_ext', 'src']);
|
|
|
|
newFile([sdkExtSrcPath, 'part.dart']);
|
|
|
|
// Pump event loop so new files are discovered and added to context.
|
|
|
|
await pumpEventQueue();
|
|
|
|
// Verify that ignored files were ignored.
|
|
|
|
Map<String, int> fileTimestamps =
|
|
|
|
callbacks.currentContextFilePaths[projPath];
|
|
|
|
expect(fileTimestamps, isNotEmpty);
|
|
|
|
List<String> files = fileTimestamps.keys.toList();
|
|
|
|
expect(files.length, equals(1));
|
|
|
|
expect(files[0], equals('/my/proj/lib/main.dart'));
|
|
|
|
}
|
|
|
|
|
|
|
|
test_path_filter_analysis_option() async {
|
|
|
|
// Create files.
|
|
|
|
String libPath = newFolder([projPath, LIB_NAME]);
|
|
|
|
newFile([libPath, 'main.dart']);
|
|
|
|
newFile([libPath, 'nope.dart']);
|
|
|
|
String sdkExtPath = newFolder([projPath, 'sdk_ext']);
|
|
|
|
newFile([sdkExtPath, 'entry.dart']);
|
|
|
|
String sdkExtSrcPath = newFolder([projPath, 'sdk_ext', 'src']);
|
|
|
|
newFile([sdkExtSrcPath, 'part.dart']);
|
|
|
|
// Setup analysis options file with ignore list.
|
2015-08-05 15:13:28 +00:00
|
|
|
newFile(
|
2015-10-28 16:59:05 +00:00
|
|
|
[projPath, AnalysisEngine.ANALYSIS_OPTIONS_FILE],
|
2015-08-05 15:13:28 +00:00
|
|
|
r'''
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
analyzer:
|
|
|
|
exclude:
|
|
|
|
- lib/nope.dart
|
|
|
|
- 'sdk_ext/**'
|
|
|
|
''');
|
|
|
|
// Setup context.
|
|
|
|
manager.setRoots(<String>[projPath], <String>[], <String, String>{});
|
|
|
|
// Verify that analysis options was parsed and the ignore patterns applied.
|
|
|
|
Map<String, int> fileTimestamps =
|
|
|
|
callbacks.currentContextFilePaths[projPath];
|
|
|
|
expect(fileTimestamps, isNotEmpty);
|
|
|
|
List<String> files = fileTimestamps.keys.toList();
|
|
|
|
expect(files.length, equals(1));
|
|
|
|
expect(files[0], equals('/my/proj/lib/main.dart'));
|
|
|
|
}
|
|
|
|
|
2015-08-03 20:54:17 +00:00
|
|
|
test_path_filter_child_contexts_option() async {
|
|
|
|
// Create files.
|
|
|
|
String libPath = newFolder([projPath, LIB_NAME]);
|
|
|
|
newFile([libPath, 'main.dart']);
|
2015-08-05 15:13:28 +00:00
|
|
|
newFile(
|
|
|
|
[libPath, 'pubspec.yaml'],
|
|
|
|
r'''
|
2015-08-03 20:54:17 +00:00
|
|
|
name: foobar
|
|
|
|
''');
|
|
|
|
String otherLibPath = newFolder([projPath, 'other_lib']);
|
|
|
|
newFile([otherLibPath, 'entry.dart']);
|
2015-08-05 15:13:28 +00:00
|
|
|
newFile(
|
|
|
|
[otherLibPath, 'pubspec.yaml'],
|
|
|
|
r'''
|
2015-08-03 20:54:17 +00:00
|
|
|
name: other_lib
|
|
|
|
''');
|
|
|
|
// Setup analysis options file with ignore list that ignores the 'other_lib'
|
|
|
|
// directory by name.
|
2015-08-05 15:13:28 +00:00
|
|
|
newFile(
|
2015-10-28 16:59:05 +00:00
|
|
|
[projPath, AnalysisEngine.ANALYSIS_OPTIONS_FILE],
|
2015-08-05 15:13:28 +00:00
|
|
|
r'''
|
2015-08-03 20:54:17 +00:00
|
|
|
analyzer:
|
|
|
|
exclude:
|
|
|
|
- 'other_lib'
|
|
|
|
''');
|
|
|
|
// Setup context.
|
|
|
|
manager.setRoots(<String>[projPath], <String>[], <String, String>{});
|
|
|
|
// Verify that the context in other_lib wasn't created and that the
|
|
|
|
// context in lib was created.
|
2015-08-05 15:13:28 +00:00
|
|
|
var contexts =
|
|
|
|
manager.contextsInAnalysisRoot(resourceProvider.newFolder(projPath));
|
2015-08-03 20:54:17 +00:00
|
|
|
expect(contexts.length, 2);
|
|
|
|
expect(contexts[0].name, equals('/my/proj'));
|
|
|
|
expect(contexts[1].name, equals('/my/proj/lib'));
|
|
|
|
}
|
|
|
|
|
2015-08-05 15:13:28 +00:00
|
|
|
test_path_filter_recursive_wildcard_child_contexts_option() async {
|
2015-08-03 20:54:17 +00:00
|
|
|
// Create files.
|
|
|
|
String libPath = newFolder([projPath, LIB_NAME]);
|
|
|
|
newFile([libPath, 'main.dart']);
|
2015-08-05 15:13:28 +00:00
|
|
|
newFile(
|
|
|
|
[libPath, 'pubspec.yaml'],
|
|
|
|
r'''
|
|
|
|
name: foobar
|
|
|
|
''');
|
2015-08-03 20:54:17 +00:00
|
|
|
String otherLibPath = newFolder([projPath, 'other_lib']);
|
|
|
|
newFile([otherLibPath, 'entry.dart']);
|
2015-08-05 15:13:28 +00:00
|
|
|
newFile(
|
|
|
|
[otherLibPath, 'pubspec.yaml'],
|
|
|
|
r'''
|
|
|
|
name: other_lib
|
|
|
|
''');
|
2015-08-03 20:54:17 +00:00
|
|
|
// Setup analysis options file with ignore list that ignores 'other_lib'
|
2015-08-05 15:13:28 +00:00
|
|
|
// and all descendants.
|
|
|
|
newFile(
|
2015-10-28 16:59:05 +00:00
|
|
|
[projPath, AnalysisEngine.ANALYSIS_OPTIONS_FILE],
|
2015-08-05 15:13:28 +00:00
|
|
|
r'''
|
2015-08-03 20:54:17 +00:00
|
|
|
analyzer:
|
|
|
|
exclude:
|
2015-08-05 15:13:28 +00:00
|
|
|
- 'other_lib/**'
|
|
|
|
''');
|
2015-08-03 20:54:17 +00:00
|
|
|
// Setup context.
|
|
|
|
manager.setRoots(<String>[projPath], <String>[], <String, String>{});
|
|
|
|
// Verify that the context in other_lib wasn't created and that the
|
|
|
|
// context in lib was created.
|
2015-08-05 15:13:28 +00:00
|
|
|
var contexts =
|
|
|
|
manager.contextsInAnalysisRoot(resourceProvider.newFolder(projPath));
|
2015-08-03 20:54:17 +00:00
|
|
|
expect(contexts.length, 2);
|
|
|
|
expect(contexts[0].name, equals('/my/proj'));
|
|
|
|
expect(contexts[1].name, equals('/my/proj/lib'));
|
|
|
|
}
|
|
|
|
|
2015-08-05 15:13:28 +00:00
|
|
|
test_path_filter_wildcard_child_contexts_option() async {
|
2015-08-03 20:54:17 +00:00
|
|
|
// Create files.
|
|
|
|
String libPath = newFolder([projPath, LIB_NAME]);
|
|
|
|
newFile([libPath, 'main.dart']);
|
2015-08-05 15:13:28 +00:00
|
|
|
newFile(
|
|
|
|
[libPath, 'pubspec.yaml'],
|
|
|
|
r'''
|
|
|
|
name: foobar
|
|
|
|
''');
|
2015-08-03 20:54:17 +00:00
|
|
|
String otherLibPath = newFolder([projPath, 'other_lib']);
|
|
|
|
newFile([otherLibPath, 'entry.dart']);
|
2015-08-05 15:13:28 +00:00
|
|
|
newFile(
|
|
|
|
[otherLibPath, 'pubspec.yaml'],
|
|
|
|
r'''
|
|
|
|
name: other_lib
|
|
|
|
''');
|
2015-08-03 20:54:17 +00:00
|
|
|
// Setup analysis options file with ignore list that ignores 'other_lib'
|
2015-08-05 15:13:28 +00:00
|
|
|
// and all immediate children.
|
|
|
|
newFile(
|
2015-10-28 16:59:05 +00:00
|
|
|
[projPath, AnalysisEngine.ANALYSIS_OPTIONS_FILE],
|
2015-08-05 15:13:28 +00:00
|
|
|
r'''
|
2015-08-03 20:54:17 +00:00
|
|
|
analyzer:
|
|
|
|
exclude:
|
2015-08-05 15:13:28 +00:00
|
|
|
- 'other_lib/*'
|
|
|
|
''');
|
2015-08-03 20:54:17 +00:00
|
|
|
// Setup context.
|
|
|
|
manager.setRoots(<String>[projPath], <String>[], <String, String>{});
|
|
|
|
// Verify that the context in other_lib wasn't created and that the
|
|
|
|
// context in lib was created.
|
2015-08-05 15:13:28 +00:00
|
|
|
var contexts =
|
|
|
|
manager.contextsInAnalysisRoot(resourceProvider.newFolder(projPath));
|
2015-08-03 20:54:17 +00:00
|
|
|
expect(contexts.length, 2);
|
|
|
|
expect(contexts[0].name, equals('/my/proj'));
|
|
|
|
expect(contexts[1].name, equals('/my/proj/lib'));
|
|
|
|
}
|
|
|
|
|
2015-07-19 05:18:30 +00:00
|
|
|
test_refresh_folder_with_packagespec() {
|
|
|
|
// create a context with a .packages file
|
|
|
|
String packagespecFile = posix.join(projPath, '.packages');
|
|
|
|
resourceProvider.newFile(packagespecFile, '');
|
|
|
|
manager.setRoots(<String>[projPath], <String>[], <String, String>{});
|
|
|
|
return pumpEventQueue().then((_) {
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
expect(callbacks.currentContextPaths.toList(), [projPath]);
|
|
|
|
callbacks.now++;
|
2015-07-19 05:18:30 +00:00
|
|
|
manager.refresh(null);
|
|
|
|
return pumpEventQueue().then((_) {
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
expect(callbacks.currentContextPaths.toList(), [projPath]);
|
|
|
|
expect(callbacks.currentContextTimestamps[projPath], callbacks.now);
|
2015-07-19 05:18:30 +00:00
|
|
|
});
|
|
|
|
});
|
|
|
|
}
|
|
|
|
|
2015-10-13 20:22:49 +00:00
|
|
|
// TODO(paulberry): This test only tests PackagesFileDisposition.
|
|
|
|
// Once http://dartbug.com/23909 is fixed, add a test for sdk extensions
|
|
|
|
// and PackageMapDisposition.
|
2015-07-19 05:18:30 +00:00
|
|
|
test_refresh_folder_with_packagespec_subfolders() {
|
|
|
|
// Create a folder with no .packages file, containing two subfolders with
|
|
|
|
// .packages files.
|
|
|
|
String subdir1Path = posix.join(projPath, 'subdir1');
|
|
|
|
String subdir2Path = posix.join(projPath, 'subdir2');
|
|
|
|
String packagespec1Path = posix.join(subdir1Path, '.packages');
|
|
|
|
String packagespec2Path = posix.join(subdir2Path, '.packages');
|
|
|
|
resourceProvider.newFile(packagespec1Path, '');
|
|
|
|
resourceProvider.newFile(packagespec2Path, '');
|
|
|
|
manager.setRoots(<String>[projPath], <String>[], <String, String>{});
|
|
|
|
return pumpEventQueue().then((_) {
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
expect(callbacks.currentContextPaths.toSet(),
|
2015-07-19 05:18:30 +00:00
|
|
|
[subdir1Path, subdir2Path, projPath].toSet());
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
callbacks.now++;
|
2015-07-19 05:18:30 +00:00
|
|
|
manager.refresh(null);
|
|
|
|
return pumpEventQueue().then((_) {
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
expect(callbacks.currentContextPaths.toSet(),
|
2015-07-19 05:18:30 +00:00
|
|
|
[subdir1Path, subdir2Path, projPath].toSet());
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
expect(callbacks.currentContextTimestamps[projPath], callbacks.now);
|
|
|
|
expect(callbacks.currentContextTimestamps[subdir1Path], callbacks.now);
|
|
|
|
expect(callbacks.currentContextTimestamps[subdir2Path], callbacks.now);
|
2015-07-19 05:18:30 +00:00
|
|
|
});
|
|
|
|
});
|
|
|
|
}
|
|
|
|
|
2014-09-10 19:20:09 +00:00
|
|
|
test_refresh_folder_with_pubspec() {
|
|
|
|
// create a context with a pubspec.yaml file
|
|
|
|
String pubspecPath = posix.join(projPath, 'pubspec.yaml');
|
|
|
|
resourceProvider.newFile(pubspecPath, 'pubspec');
|
2014-10-23 00:11:36 +00:00
|
|
|
manager.setRoots(<String>[projPath], <String>[], <String, String>{});
|
2014-09-10 19:20:09 +00:00
|
|
|
return pumpEventQueue().then((_) {
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
expect(callbacks.currentContextPaths.toList(), [projPath]);
|
|
|
|
callbacks.now++;
|
2015-03-30 21:07:23 +00:00
|
|
|
manager.refresh(null);
|
2014-09-10 19:20:09 +00:00
|
|
|
return pumpEventQueue().then((_) {
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
expect(callbacks.currentContextPaths.toList(), [projPath]);
|
|
|
|
expect(callbacks.currentContextTimestamps[projPath], callbacks.now);
|
2014-09-10 19:20:09 +00:00
|
|
|
});
|
|
|
|
});
|
|
|
|
}
|
|
|
|
|
|
|
|
test_refresh_folder_with_pubspec_subfolders() {
|
|
|
|
// Create a folder with no pubspec.yaml, containing two subfolders with
|
|
|
|
// pubspec.yaml files.
|
|
|
|
String subdir1Path = posix.join(projPath, 'subdir1');
|
|
|
|
String subdir2Path = posix.join(projPath, 'subdir2');
|
|
|
|
String pubspec1Path = posix.join(subdir1Path, 'pubspec.yaml');
|
|
|
|
String pubspec2Path = posix.join(subdir2Path, 'pubspec.yaml');
|
|
|
|
resourceProvider.newFile(pubspec1Path, 'pubspec');
|
|
|
|
resourceProvider.newFile(pubspec2Path, 'pubspec');
|
2014-10-23 00:11:36 +00:00
|
|
|
manager.setRoots(<String>[projPath], <String>[], <String, String>{});
|
2014-09-10 19:20:09 +00:00
|
|
|
return pumpEventQueue().then((_) {
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
expect(callbacks.currentContextPaths.toSet(),
|
2014-09-17 03:50:46 +00:00
|
|
|
[subdir1Path, subdir2Path, projPath].toSet());
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
callbacks.now++;
|
2015-03-30 21:07:23 +00:00
|
|
|
manager.refresh(null);
|
2014-09-10 19:20:09 +00:00
|
|
|
return pumpEventQueue().then((_) {
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
expect(callbacks.currentContextPaths.toSet(),
|
2014-11-17 22:23:53 +00:00
|
|
|
[subdir1Path, subdir2Path, projPath].toSet());
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
expect(callbacks.currentContextTimestamps[projPath], callbacks.now);
|
|
|
|
expect(callbacks.currentContextTimestamps[subdir1Path], callbacks.now);
|
|
|
|
expect(callbacks.currentContextTimestamps[subdir2Path], callbacks.now);
|
2014-09-10 19:20:09 +00:00
|
|
|
});
|
|
|
|
});
|
|
|
|
}
|
|
|
|
|
2015-03-30 21:07:23 +00:00
|
|
|
test_refresh_oneContext() {
|
|
|
|
// create two contexts with pubspec.yaml files
|
|
|
|
String pubspecPath = posix.join(projPath, 'pubspec.yaml');
|
|
|
|
resourceProvider.newFile(pubspecPath, 'pubspec1');
|
|
|
|
|
|
|
|
String proj2Path = '/my/proj2';
|
|
|
|
resourceProvider.newFolder(proj2Path);
|
|
|
|
String pubspec2Path = posix.join(proj2Path, 'pubspec.yaml');
|
|
|
|
resourceProvider.newFile(pubspec2Path, 'pubspec2');
|
|
|
|
|
|
|
|
List<String> roots = <String>[projPath, proj2Path];
|
|
|
|
manager.setRoots(roots, <String>[], <String, String>{});
|
|
|
|
return pumpEventQueue().then((_) {
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
expect(callbacks.currentContextPaths.toList(), unorderedEquals(roots));
|
|
|
|
int then = callbacks.now;
|
|
|
|
callbacks.now++;
|
2015-03-30 21:07:23 +00:00
|
|
|
manager.refresh([resourceProvider.getResource(proj2Path)]);
|
|
|
|
return pumpEventQueue().then((_) {
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
expect(callbacks.currentContextPaths.toList(), unorderedEquals(roots));
|
|
|
|
expect(callbacks.currentContextTimestamps[projPath], then);
|
|
|
|
expect(callbacks.currentContextTimestamps[proj2Path], callbacks.now);
|
2015-03-30 21:07:23 +00:00
|
|
|
});
|
|
|
|
});
|
|
|
|
}
|
|
|
|
|
2015-09-23 20:27:19 +00:00
|
|
|
test_sdk_ext_packagespec() async {
|
|
|
|
// Create files.
|
|
|
|
String libPath = newFolder([projPath, LIB_NAME]);
|
|
|
|
newFile([libPath, 'main.dart']);
|
|
|
|
newFile([libPath, 'nope.dart']);
|
|
|
|
String sdkExtPath = newFolder([projPath, 'sdk_ext']);
|
|
|
|
newFile([sdkExtPath, 'entry.dart']);
|
|
|
|
String sdkExtSrcPath = newFolder([projPath, 'sdk_ext', 'src']);
|
|
|
|
newFile([sdkExtSrcPath, 'part.dart']);
|
|
|
|
// Setup sdk extension mapping.
|
|
|
|
newFile(
|
|
|
|
[libPath, '_sdkext'],
|
|
|
|
r'''
|
|
|
|
{
|
|
|
|
"dart:foobar": "../sdk_ext/entry.dart"
|
|
|
|
}
|
|
|
|
''');
|
|
|
|
// Setup .packages file
|
|
|
|
newFile(
|
|
|
|
[projPath, '.packages'],
|
|
|
|
r'''
|
|
|
|
test_pack:lib/
|
|
|
|
''');
|
|
|
|
// Setup context.
|
|
|
|
manager.setRoots(<String>[projPath], <String>[], <String, String>{});
|
|
|
|
// Confirm that one context was created.
|
|
|
|
var contexts =
|
|
|
|
manager.contextsInAnalysisRoot(resourceProvider.newFolder(projPath));
|
|
|
|
expect(contexts, isNotNull);
|
|
|
|
expect(contexts.length, equals(1));
|
|
|
|
var context = contexts[0];
|
|
|
|
var source = context.sourceFactory.forUri('dart:foobar');
|
|
|
|
expect(source.fullName, equals('/my/proj/sdk_ext/entry.dart'));
|
|
|
|
}
|
|
|
|
|
2014-08-07 18:04:21 +00:00
|
|
|
void test_setRoots_addFolderWithDartFile() {
|
|
|
|
String filePath = posix.join(projPath, 'foo.dart');
|
|
|
|
resourceProvider.newFile(filePath, 'contents');
|
2014-10-23 00:11:36 +00:00
|
|
|
manager.setRoots(<String>[projPath], <String>[], <String, String>{});
|
2014-08-07 18:04:21 +00:00
|
|
|
// verify
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
var filePaths = callbacks.currentContextFilePaths[projPath];
|
2014-08-07 18:04:21 +00:00
|
|
|
expect(filePaths, hasLength(1));
|
|
|
|
expect(filePaths, contains(filePath));
|
2015-07-13 17:20:13 +00:00
|
|
|
List<AnalysisContext> contextsInAnalysisRoot =
|
|
|
|
manager.contextsInAnalysisRoot(resourceProvider.newFolder(projPath));
|
2015-07-06 20:06:33 +00:00
|
|
|
expect(contextsInAnalysisRoot, hasLength(1));
|
|
|
|
AnalysisContext context = contextsInAnalysisRoot[0];
|
|
|
|
expect(context, isNotNull);
|
|
|
|
Source result = context.sourceFactory.forUri('package:foo/foo.dart');
|
|
|
|
expect(result, isNotNull);
|
|
|
|
expect(result.exists(), isFalse);
|
|
|
|
}
|
|
|
|
|
2014-08-07 18:04:21 +00:00
|
|
|
void test_setRoots_addFolderWithDartFileInSubfolder() {
|
|
|
|
String filePath = posix.join(projPath, 'foo', 'bar.dart');
|
|
|
|
resourceProvider.newFile(filePath, 'contents');
|
2014-10-23 00:11:36 +00:00
|
|
|
manager.setRoots(<String>[projPath], <String>[], <String, String>{});
|
2014-08-07 18:04:21 +00:00
|
|
|
// verify
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
var filePaths = callbacks.currentContextFilePaths[projPath];
|
2014-08-07 18:04:21 +00:00
|
|
|
expect(filePaths, hasLength(1));
|
|
|
|
expect(filePaths, contains(filePath));
|
|
|
|
}
|
|
|
|
|
|
|
|
void test_setRoots_addFolderWithDummyLink() {
|
|
|
|
String filePath = posix.join(projPath, 'foo.dart');
|
|
|
|
resourceProvider.newDummyLink(filePath);
|
2014-10-23 00:11:36 +00:00
|
|
|
manager.setRoots(<String>[projPath], <String>[], <String, String>{});
|
2014-08-07 18:04:21 +00:00
|
|
|
// verify
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
var filePaths = callbacks.currentContextFilePaths[projPath];
|
2014-08-07 18:04:21 +00:00
|
|
|
expect(filePaths, isEmpty);
|
|
|
|
}
|
|
|
|
|
2015-07-19 05:18:30 +00:00
|
|
|
void test_setRoots_addFolderWithNestedPackageSpec() {
|
|
|
|
String examplePath = newFolder([projPath, EXAMPLE_NAME]);
|
|
|
|
String libPath = newFolder([projPath, LIB_NAME]);
|
|
|
|
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
newFile([projPath, ContextManagerImpl.PACKAGE_SPEC_NAME]);
|
2015-07-19 05:18:30 +00:00
|
|
|
newFile([libPath, 'main.dart']);
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
newFile([examplePath, ContextManagerImpl.PACKAGE_SPEC_NAME]);
|
2015-07-19 05:18:30 +00:00
|
|
|
newFile([examplePath, 'example.dart']);
|
|
|
|
|
2015-08-05 15:13:28 +00:00
|
|
|
packageMapProvider.packageMap['proj'] = [
|
|
|
|
resourceProvider.getResource(libPath)
|
|
|
|
];
|
2015-07-19 05:18:30 +00:00
|
|
|
|
|
|
|
manager.setRoots(<String>[projPath], <String>[], <String, String>{});
|
|
|
|
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
expect(callbacks.currentContextPaths, hasLength(2));
|
2015-07-19 05:18:30 +00:00
|
|
|
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
expect(callbacks.currentContextPaths, contains(projPath));
|
|
|
|
Set<Source> projSources = callbacks.currentContextSources[projPath];
|
2015-07-19 05:18:30 +00:00
|
|
|
expect(projSources, hasLength(1));
|
|
|
|
expect(projSources.first.uri.toString(), 'file:///my/proj/lib/main.dart');
|
|
|
|
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
expect(callbacks.currentContextPaths, contains(examplePath));
|
|
|
|
Set<Source> exampleSources = callbacks.currentContextSources[examplePath];
|
2015-07-19 05:18:30 +00:00
|
|
|
expect(exampleSources, hasLength(1));
|
|
|
|
expect(exampleSources.first.uri.toString(),
|
|
|
|
'file:///my/proj/example/example.dart');
|
|
|
|
}
|
|
|
|
|
2015-03-30 16:01:03 +00:00
|
|
|
void test_setRoots_addFolderWithNestedPubspec() {
|
|
|
|
String examplePath = newFolder([projPath, EXAMPLE_NAME]);
|
|
|
|
String libPath = newFolder([projPath, LIB_NAME]);
|
|
|
|
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
newFile([projPath, ContextManagerImpl.PUBSPEC_NAME]);
|
2015-03-30 16:01:03 +00:00
|
|
|
newFile([libPath, 'main.dart']);
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
newFile([examplePath, ContextManagerImpl.PUBSPEC_NAME]);
|
2015-03-30 16:01:03 +00:00
|
|
|
newFile([examplePath, 'example.dart']);
|
|
|
|
|
2015-08-05 15:13:28 +00:00
|
|
|
packageMapProvider.packageMap['proj'] = [
|
|
|
|
resourceProvider.getResource(libPath)
|
|
|
|
];
|
2015-03-30 16:01:03 +00:00
|
|
|
|
|
|
|
manager.setRoots(<String>[projPath], <String>[], <String, String>{});
|
|
|
|
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
expect(callbacks.currentContextPaths, hasLength(2));
|
2015-03-30 16:01:03 +00:00
|
|
|
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
expect(callbacks.currentContextPaths, contains(projPath));
|
|
|
|
Set<Source> projSources = callbacks.currentContextSources[projPath];
|
2015-03-30 16:01:03 +00:00
|
|
|
expect(projSources, hasLength(1));
|
|
|
|
expect(projSources.first.uri.toString(), 'package:proj/main.dart');
|
|
|
|
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
expect(callbacks.currentContextPaths, contains(examplePath));
|
|
|
|
Set<Source> exampleSources = callbacks.currentContextSources[examplePath];
|
2015-03-30 16:01:03 +00:00
|
|
|
expect(exampleSources, hasLength(1));
|
|
|
|
expect(exampleSources.first.uri.toString(),
|
|
|
|
'file:///my/proj/example/example.dart');
|
|
|
|
}
|
|
|
|
|
2015-02-26 17:24:08 +00:00
|
|
|
void test_setRoots_addFolderWithoutPubspec() {
|
|
|
|
packageMapProvider.packageMap = null;
|
|
|
|
manager.setRoots(<String>[projPath], <String>[], <String, String>{});
|
|
|
|
// verify
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
expect(callbacks.currentContextPaths, hasLength(1));
|
|
|
|
expect(callbacks.currentContextPaths, contains(projPath));
|
|
|
|
expect(callbacks.currentContextFilePaths[projPath], hasLength(0));
|
2015-02-26 17:24:08 +00:00
|
|
|
}
|
|
|
|
|
2015-07-19 05:18:30 +00:00
|
|
|
void test_setRoots_addFolderWithPackagespec() {
|
|
|
|
String packagespecPath = posix.join(projPath, '.packages');
|
|
|
|
resourceProvider.newFile(packagespecPath,
|
|
|
|
'unittest:file:///home/somebody/.pub/cache/unittest-0.9.9/lib/');
|
|
|
|
String libPath = newFolder([projPath, LIB_NAME]);
|
|
|
|
File mainFile =
|
|
|
|
resourceProvider.newFile(posix.join(libPath, 'main.dart'), '');
|
|
|
|
Source source = mainFile.createSource();
|
|
|
|
|
|
|
|
manager.setRoots(<String>[projPath], <String>[], <String, String>{});
|
|
|
|
|
|
|
|
// verify
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
expect(callbacks.currentContextPaths, hasLength(1));
|
|
|
|
expect(callbacks.currentContextPaths, contains(projPath));
|
|
|
|
expect(callbacks.currentContextFilePaths[projPath], hasLength(1));
|
2015-07-19 05:18:30 +00:00
|
|
|
|
|
|
|
// smoketest resolution
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
SourceFactory sourceFactory = callbacks.currentContext.sourceFactory;
|
2015-07-19 05:18:30 +00:00
|
|
|
Source resolvedSource =
|
|
|
|
sourceFactory.resolveUri(source, 'package:unittest/unittest.dart');
|
|
|
|
expect(resolvedSource, isNotNull);
|
|
|
|
expect(resolvedSource.fullName,
|
|
|
|
equals('/home/somebody/.pub/cache/unittest-0.9.9/lib/unittest.dart'));
|
|
|
|
}
|
|
|
|
|
2015-08-07 16:23:53 +00:00
|
|
|
void test_setRoots_addFolderWithPackagespecAndPackageRoot() {
|
|
|
|
// The package root should take priority.
|
|
|
|
String packagespecPath = posix.join(projPath, '.packages');
|
|
|
|
resourceProvider.newFile(packagespecPath,
|
|
|
|
'unittest:file:///home/somebody/.pub/cache/unittest-0.9.9/lib/');
|
|
|
|
String packageRootPath = '/package/root/';
|
|
|
|
manager.setRoots(<String>[projPath], <String>[],
|
|
|
|
<String, String>{projPath: packageRootPath});
|
|
|
|
expect(callbacks.currentContextPaths, hasLength(1));
|
|
|
|
expect(callbacks.currentContextPaths, contains(projPath));
|
|
|
|
expect(callbacks.currentContextDispositions[projPath].packageRoot,
|
|
|
|
packageRootPath);
|
|
|
|
}
|
|
|
|
|
2014-08-07 18:04:21 +00:00
|
|
|
void test_setRoots_addFolderWithPubspec() {
|
|
|
|
String pubspecPath = posix.join(projPath, 'pubspec.yaml');
|
|
|
|
resourceProvider.newFile(pubspecPath, 'pubspec');
|
2014-10-23 00:11:36 +00:00
|
|
|
manager.setRoots(<String>[projPath], <String>[], <String, String>{});
|
2014-08-07 18:04:21 +00:00
|
|
|
// verify
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
expect(callbacks.currentContextPaths, hasLength(1));
|
|
|
|
expect(callbacks.currentContextPaths, contains(projPath));
|
|
|
|
expect(callbacks.currentContextFilePaths[projPath], hasLength(0));
|
2014-08-07 18:04:21 +00:00
|
|
|
}
|
|
|
|
|
2015-07-19 05:18:30 +00:00
|
|
|
void test_setRoots_addFolderWithPubspec_andPackagespec() {
|
|
|
|
String pubspecPath = posix.join(projPath, 'pubspec.yaml');
|
|
|
|
String packagespecPath = posix.join(projPath, '.packages');
|
|
|
|
resourceProvider.newFile(pubspecPath, 'pubspec');
|
|
|
|
resourceProvider.newFile(packagespecPath, '');
|
|
|
|
manager.setRoots(<String>[projPath], <String>[], <String, String>{});
|
|
|
|
// verify
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
callbacks.assertContextPaths([projPath]);
|
2015-07-19 05:18:30 +00:00
|
|
|
}
|
|
|
|
|
2015-02-17 22:47:34 +00:00
|
|
|
void test_setRoots_addFolderWithPubspecAndLib() {
|
|
|
|
String binPath = newFolder([projPath, BIN_NAME]);
|
|
|
|
String libPath = newFolder([projPath, LIB_NAME]);
|
|
|
|
String srcPath = newFolder([libPath, SRC_NAME]);
|
|
|
|
String testPath = newFolder([projPath, TEST_NAME]);
|
|
|
|
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
newFile([projPath, ContextManagerImpl.PUBSPEC_NAME]);
|
2015-02-17 22:47:34 +00:00
|
|
|
String appPath = newFile([binPath, 'app.dart']);
|
|
|
|
newFile([libPath, 'main.dart']);
|
|
|
|
newFile([srcPath, 'internal.dart']);
|
|
|
|
String testFilePath = newFile([testPath, 'main_test.dart']);
|
|
|
|
|
2015-08-05 15:13:28 +00:00
|
|
|
packageMapProvider.packageMap['proj'] = [
|
|
|
|
resourceProvider.getResource(libPath)
|
|
|
|
];
|
2015-02-23 17:34:12 +00:00
|
|
|
|
2015-02-17 22:47:34 +00:00
|
|
|
manager.setRoots(<String>[projPath], <String>[], <String, String>{});
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
Set<Source> sources = callbacks.currentContextSources[projPath];
|
2015-02-17 22:47:34 +00:00
|
|
|
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
expect(callbacks.currentContextPaths, hasLength(1));
|
|
|
|
expect(callbacks.currentContextPaths, contains(projPath));
|
2015-02-17 22:47:34 +00:00
|
|
|
expect(sources, hasLength(4));
|
|
|
|
List<String> uris =
|
|
|
|
sources.map((Source source) => source.uri.toString()).toList();
|
|
|
|
expect(uris, contains('file://$appPath'));
|
|
|
|
expect(uris, contains('package:proj/main.dart'));
|
|
|
|
expect(uris, contains('package:proj/src/internal.dart'));
|
|
|
|
expect(uris, contains('file://$testFilePath'));
|
|
|
|
}
|
|
|
|
|
2015-07-19 05:18:30 +00:00
|
|
|
void test_setRoots_addFolderWithPubspecAndPackagespecFolders() {
|
|
|
|
// prepare paths
|
|
|
|
String root = '/root';
|
|
|
|
String rootFile = '$root/root.dart';
|
|
|
|
String subProjectA = '$root/sub/aaa';
|
|
|
|
String subProjectB = '$root/sub/sub2/bbb';
|
|
|
|
String subProjectA_file = '$subProjectA/bin/a.dart';
|
|
|
|
String subProjectB_file = '$subProjectB/bin/b.dart';
|
|
|
|
// create files
|
|
|
|
resourceProvider.newFile('$subProjectA/pubspec.yaml', 'pubspec');
|
|
|
|
resourceProvider.newFile('$subProjectB/pubspec.yaml', 'pubspec');
|
|
|
|
resourceProvider.newFile('$subProjectA/.packages', '');
|
|
|
|
resourceProvider.newFile('$subProjectB/.packages', '');
|
|
|
|
|
|
|
|
resourceProvider.newFile(rootFile, 'library root;');
|
|
|
|
resourceProvider.newFile(subProjectA_file, 'library a;');
|
|
|
|
resourceProvider.newFile(subProjectB_file, 'library b;');
|
|
|
|
|
|
|
|
// set roots
|
|
|
|
manager.setRoots(<String>[root], <String>[], <String, String>{});
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
callbacks.assertContextPaths([root, subProjectA, subProjectB]);
|
2015-07-19 05:18:30 +00:00
|
|
|
// verify files
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
callbacks.assertContextFiles(root, [rootFile]);
|
|
|
|
callbacks.assertContextFiles(subProjectA, [subProjectA_file]);
|
|
|
|
callbacks.assertContextFiles(subProjectB, [subProjectB_file]);
|
2015-07-19 05:18:30 +00:00
|
|
|
}
|
|
|
|
|
2014-08-08 15:55:06 +00:00
|
|
|
void test_setRoots_addFolderWithPubspecFolders() {
|
|
|
|
// prepare paths
|
|
|
|
String root = '/root';
|
|
|
|
String rootFile = '$root/root.dart';
|
|
|
|
String subProjectA = '$root/sub/aaa';
|
|
|
|
String subProjectB = '$root/sub/sub2/bbb';
|
|
|
|
String subProjectA_file = '$subProjectA/bin/a.dart';
|
|
|
|
String subProjectB_file = '$subProjectB/bin/b.dart';
|
|
|
|
// create files
|
|
|
|
resourceProvider.newFile('$subProjectA/pubspec.yaml', 'pubspec');
|
|
|
|
resourceProvider.newFile('$subProjectB/pubspec.yaml', 'pubspec');
|
|
|
|
resourceProvider.newFile(rootFile, 'library root;');
|
|
|
|
resourceProvider.newFile(subProjectA_file, 'library a;');
|
|
|
|
resourceProvider.newFile(subProjectB_file, 'library b;');
|
|
|
|
// configure package maps
|
|
|
|
packageMapProvider.packageMaps = {
|
2015-08-05 15:13:28 +00:00
|
|
|
subProjectA: {
|
|
|
|
'foo': [resourceProvider.newFolder('/package/foo')]
|
|
|
|
},
|
|
|
|
subProjectB: {
|
|
|
|
'bar': [resourceProvider.newFolder('/package/bar')]
|
|
|
|
},
|
2014-08-08 15:55:06 +00:00
|
|
|
};
|
|
|
|
// set roots
|
2014-10-23 00:11:36 +00:00
|
|
|
manager.setRoots(<String>[root], <String>[], <String, String>{});
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
callbacks.assertContextPaths([root, subProjectA, subProjectB]);
|
2014-08-08 15:55:06 +00:00
|
|
|
// verify files
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
callbacks.assertContextFiles(root, [rootFile]);
|
|
|
|
callbacks.assertContextFiles(subProjectA, [subProjectA_file]);
|
|
|
|
callbacks.assertContextFiles(subProjectB, [subProjectB_file]);
|
2014-08-08 15:55:06 +00:00
|
|
|
// verify package maps
|
2015-02-03 16:06:25 +00:00
|
|
|
_checkPackageMap(root, isNull);
|
2014-11-17 22:23:53 +00:00
|
|
|
_checkPackageMap(
|
2015-03-02 22:43:12 +00:00
|
|
|
subProjectA, equals(packageMapProvider.packageMaps[subProjectA]));
|
2014-11-17 22:23:53 +00:00
|
|
|
_checkPackageMap(
|
2015-03-02 22:43:12 +00:00
|
|
|
subProjectB, equals(packageMapProvider.packageMaps[subProjectB]));
|
2014-08-08 15:55:06 +00:00
|
|
|
}
|
|
|
|
|
2015-07-26 22:08:58 +00:00
|
|
|
void test_setRoots_addPackageRoot() {
|
|
|
|
String packagePathFoo = '/package1/foo';
|
|
|
|
String packageRootPath = '/package2/foo';
|
|
|
|
Folder packageFolder = resourceProvider.newFolder(packagePathFoo);
|
2015-08-05 15:13:28 +00:00
|
|
|
packageMapProvider.packageMap = {
|
|
|
|
'foo': [packageFolder]
|
|
|
|
};
|
2015-07-26 22:08:58 +00:00
|
|
|
List<String> includedPaths = <String>[projPath];
|
|
|
|
List<String> excludedPaths = <String>[];
|
|
|
|
manager.setRoots(includedPaths, excludedPaths, <String, String>{});
|
|
|
|
_checkPackageMap(projPath, equals(packageMapProvider.packageMap));
|
2015-08-05 15:13:28 +00:00
|
|
|
manager.setRoots(includedPaths, excludedPaths,
|
|
|
|
<String, String>{projPath: packageRootPath});
|
2015-07-26 22:08:58 +00:00
|
|
|
_checkPackageRoot(projPath, equals(packageRootPath));
|
|
|
|
}
|
|
|
|
|
|
|
|
void test_setRoots_changePackageRoot() {
|
|
|
|
String packageRootPath1 = '/package1';
|
|
|
|
String packageRootPath2 = '/package2';
|
|
|
|
List<String> includedPaths = <String>[projPath];
|
|
|
|
List<String> excludedPaths = <String>[];
|
2015-08-05 15:13:28 +00:00
|
|
|
manager.setRoots(includedPaths, excludedPaths,
|
|
|
|
<String, String>{projPath: packageRootPath1});
|
2015-07-26 22:08:58 +00:00
|
|
|
_checkPackageRoot(projPath, equals(packageRootPath1));
|
2015-08-05 15:13:28 +00:00
|
|
|
manager.setRoots(includedPaths, excludedPaths,
|
|
|
|
<String, String>{projPath: packageRootPath2});
|
2015-07-26 22:08:58 +00:00
|
|
|
_checkPackageRoot(projPath, equals(packageRootPath2));
|
|
|
|
}
|
|
|
|
|
2014-08-08 19:42:07 +00:00
|
|
|
void test_setRoots_exclude_newRoot_withExcludedFile() {
|
|
|
|
// prepare paths
|
|
|
|
String project = '/project';
|
|
|
|
String file1 = '$project/file1.dart';
|
|
|
|
String file2 = '$project/file2.dart';
|
|
|
|
// create files
|
|
|
|
resourceProvider.newFile(file1, '// 1');
|
|
|
|
resourceProvider.newFile(file2, '// 2');
|
|
|
|
// set roots
|
2014-10-23 00:11:36 +00:00
|
|
|
manager.setRoots(<String>[project], <String>[file1], <String, String>{});
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
callbacks.assertContextPaths([project]);
|
|
|
|
callbacks.assertContextFiles(project, [file2]);
|
2014-08-08 19:42:07 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void test_setRoots_exclude_newRoot_withExcludedFolder() {
|
|
|
|
// prepare paths
|
|
|
|
String project = '/project';
|
|
|
|
String folderA = '$project/aaa';
|
|
|
|
String folderB = '$project/bbb';
|
|
|
|
String fileA = '$folderA/a.dart';
|
|
|
|
String fileB = '$folderB/b.dart';
|
|
|
|
// create files
|
|
|
|
resourceProvider.newFile(fileA, 'library a;');
|
|
|
|
resourceProvider.newFile(fileB, 'library b;');
|
|
|
|
// set roots
|
2014-10-23 00:11:36 +00:00
|
|
|
manager.setRoots(<String>[project], <String>[folderB], <String, String>{});
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
callbacks.assertContextPaths([project]);
|
|
|
|
callbacks.assertContextFiles(project, [fileA]);
|
2014-08-08 19:42:07 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void test_setRoots_exclude_sameRoot_addExcludedFile() {
|
|
|
|
// prepare paths
|
|
|
|
String project = '/project';
|
|
|
|
String file1 = '$project/file1.dart';
|
|
|
|
String file2 = '$project/file2.dart';
|
|
|
|
// create files
|
|
|
|
resourceProvider.newFile(file1, '// 1');
|
|
|
|
resourceProvider.newFile(file2, '// 2');
|
|
|
|
// set roots
|
2014-10-23 00:11:36 +00:00
|
|
|
manager.setRoots(<String>[project], <String>[], <String, String>{});
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
callbacks.assertContextPaths([project]);
|
|
|
|
callbacks.assertContextFiles(project, [file1, file2]);
|
2014-08-08 19:42:07 +00:00
|
|
|
// exclude "2"
|
2014-10-23 00:11:36 +00:00
|
|
|
manager.setRoots(<String>[project], <String>[file2], <String, String>{});
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
callbacks.assertContextPaths([project]);
|
|
|
|
callbacks.assertContextFiles(project, [file1]);
|
2014-08-08 19:42:07 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void test_setRoots_exclude_sameRoot_addExcludedFolder() {
|
|
|
|
// prepare paths
|
|
|
|
String project = '/project';
|
|
|
|
String folderA = '$project/aaa';
|
|
|
|
String folderB = '$project/bbb';
|
|
|
|
String fileA = '$folderA/a.dart';
|
|
|
|
String fileB = '$folderB/b.dart';
|
|
|
|
// create files
|
|
|
|
resourceProvider.newFile(fileA, 'library a;');
|
|
|
|
resourceProvider.newFile(fileB, 'library b;');
|
|
|
|
// initially both "aaa/a" and "bbb/b" are included
|
2014-10-23 00:11:36 +00:00
|
|
|
manager.setRoots(<String>[project], <String>[], <String, String>{});
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
callbacks.assertContextPaths([project]);
|
|
|
|
callbacks.assertContextFiles(project, [fileA, fileB]);
|
2014-08-08 19:42:07 +00:00
|
|
|
// exclude "bbb/"
|
2014-10-23 00:11:36 +00:00
|
|
|
manager.setRoots(<String>[project], <String>[folderB], <String, String>{});
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
callbacks.assertContextPaths([project]);
|
|
|
|
callbacks.assertContextFiles(project, [fileA]);
|
2014-08-08 19:42:07 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void test_setRoots_exclude_sameRoot_removeExcludedFile() {
|
|
|
|
// prepare paths
|
|
|
|
String project = '/project';
|
|
|
|
String file1 = '$project/file1.dart';
|
|
|
|
String file2 = '$project/file2.dart';
|
|
|
|
// create files
|
|
|
|
resourceProvider.newFile(file1, '// 1');
|
|
|
|
resourceProvider.newFile(file2, '// 2');
|
|
|
|
// set roots
|
2014-10-23 00:11:36 +00:00
|
|
|
manager.setRoots(<String>[project], <String>[file2], <String, String>{});
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
callbacks.assertContextPaths([project]);
|
|
|
|
callbacks.assertContextFiles(project, [file1]);
|
2014-08-08 19:42:07 +00:00
|
|
|
// stop excluding "2"
|
2014-10-23 00:11:36 +00:00
|
|
|
manager.setRoots(<String>[project], <String>[], <String, String>{});
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
callbacks.assertContextPaths([project]);
|
|
|
|
callbacks.assertContextFiles(project, [file1, file2]);
|
2014-08-08 19:42:07 +00:00
|
|
|
}
|
|
|
|
|
2014-11-04 18:47:14 +00:00
|
|
|
void test_setRoots_exclude_sameRoot_removeExcludedFile_inFolder() {
|
|
|
|
// prepare paths
|
|
|
|
String project = '/project';
|
|
|
|
String file1 = '$project/bin/file1.dart';
|
|
|
|
String file2 = '$project/bin/file2.dart';
|
|
|
|
// create files
|
|
|
|
resourceProvider.newFile(file1, '// 1');
|
|
|
|
resourceProvider.newFile(file2, '// 2');
|
|
|
|
// set roots
|
|
|
|
manager.setRoots(<String>[project], <String>[file2], <String, String>{});
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
callbacks.assertContextPaths([project]);
|
|
|
|
callbacks.assertContextFiles(project, [file1]);
|
2014-11-04 18:47:14 +00:00
|
|
|
// stop excluding "2"
|
|
|
|
manager.setRoots(<String>[project], <String>[], <String, String>{});
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
callbacks.assertContextPaths([project]);
|
|
|
|
callbacks.assertContextFiles(project, [file1, file2]);
|
2014-11-04 18:47:14 +00:00
|
|
|
}
|
|
|
|
|
2014-08-08 19:42:07 +00:00
|
|
|
void test_setRoots_exclude_sameRoot_removeExcludedFolder() {
|
|
|
|
// prepare paths
|
|
|
|
String project = '/project';
|
|
|
|
String folderA = '$project/aaa';
|
|
|
|
String folderB = '$project/bbb';
|
|
|
|
String fileA = '$folderA/a.dart';
|
|
|
|
String fileB = '$folderB/b.dart';
|
|
|
|
// create files
|
|
|
|
resourceProvider.newFile(fileA, 'library a;');
|
|
|
|
resourceProvider.newFile(fileB, 'library b;');
|
|
|
|
// exclude "bbb/"
|
2014-10-23 00:11:36 +00:00
|
|
|
manager.setRoots(<String>[project], <String>[folderB], <String, String>{});
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
callbacks.assertContextPaths([project]);
|
|
|
|
callbacks.assertContextFiles(project, [fileA]);
|
2014-08-08 19:42:07 +00:00
|
|
|
// stop excluding "bbb/"
|
2014-10-23 00:11:36 +00:00
|
|
|
manager.setRoots(<String>[project], <String>[], <String, String>{});
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
callbacks.assertContextPaths([project]);
|
|
|
|
callbacks.assertContextFiles(project, [fileA, fileB]);
|
2014-08-08 19:42:07 +00:00
|
|
|
}
|
|
|
|
|
2015-07-26 22:08:58 +00:00
|
|
|
void test_setRoots_newFolderWithPackageRoot() {
|
|
|
|
String packageRootPath = '/package';
|
2015-08-05 15:13:28 +00:00
|
|
|
manager.setRoots(<String>[projPath], <String>[],
|
|
|
|
<String, String>{projPath: packageRootPath});
|
2015-07-26 22:08:58 +00:00
|
|
|
_checkPackageRoot(projPath, equals(packageRootPath));
|
|
|
|
}
|
|
|
|
|
2014-08-07 18:04:21 +00:00
|
|
|
void test_setRoots_newlyAddedFoldersGetProperPackageMap() {
|
|
|
|
String packagePath = '/package/foo';
|
|
|
|
Folder packageFolder = resourceProvider.newFolder(packagePath);
|
2015-08-05 15:13:28 +00:00
|
|
|
packageMapProvider.packageMap = {
|
|
|
|
'foo': [packageFolder]
|
|
|
|
};
|
2014-10-23 00:11:36 +00:00
|
|
|
manager.setRoots(<String>[projPath], <String>[], <String, String>{});
|
2014-10-24 20:29:24 +00:00
|
|
|
_checkPackageMap(projPath, equals(packageMapProvider.packageMap));
|
|
|
|
}
|
|
|
|
|
2015-10-19 20:17:11 +00:00
|
|
|
void test_setRoots_noContext_excludedFolder() {
|
|
|
|
// prepare paths
|
|
|
|
String project = '/project';
|
|
|
|
String excludedFolder = '$project/excluded';
|
|
|
|
String excludedPubspec = '$excludedFolder/pubspec.yaml';
|
|
|
|
// create files
|
|
|
|
resourceProvider.newFile(excludedPubspec, 'name: ignore-me');
|
|
|
|
// set "/project", and exclude "/project/excluded"
|
|
|
|
manager.setRoots(
|
|
|
|
<String>[project], <String>[excludedFolder], <String, String>{});
|
|
|
|
callbacks.assertContextPaths([project]);
|
|
|
|
}
|
|
|
|
|
2015-10-19 18:59:11 +00:00
|
|
|
void test_setRoots_noContext_inDotFolder() {
|
|
|
|
String pubspecPath = posix.join(projPath, '.pub', 'pubspec.yaml');
|
|
|
|
resourceProvider.newFile(pubspecPath, 'name: test');
|
|
|
|
manager.setRoots(<String>[projPath], <String>[], <String, String>{});
|
|
|
|
// verify
|
|
|
|
expect(callbacks.currentContextPaths, hasLength(1));
|
|
|
|
expect(callbacks.currentContextPaths, contains(projPath));
|
|
|
|
expect(callbacks.currentContextFilePaths[projPath], hasLength(0));
|
|
|
|
}
|
|
|
|
|
|
|
|
void test_setRoots_noContext_inPackagesFolder() {
|
|
|
|
String pubspecPath = posix.join(projPath, 'packages', 'pubspec.yaml');
|
|
|
|
resourceProvider.newFile(pubspecPath, 'name: test');
|
|
|
|
manager.setRoots(<String>[projPath], <String>[], <String, String>{});
|
|
|
|
// verify
|
|
|
|
expect(callbacks.currentContextPaths, hasLength(1));
|
|
|
|
expect(callbacks.currentContextPaths, contains(projPath));
|
|
|
|
expect(callbacks.currentContextFilePaths[projPath], hasLength(0));
|
|
|
|
}
|
|
|
|
|
2015-07-13 17:20:13 +00:00
|
|
|
void test_setRoots_packageResolver() {
|
|
|
|
Uri uri = Uri.parse('package:foo/foo.dart');
|
|
|
|
Source source = new TestSource();
|
|
|
|
packageResolver = new TestUriResolver({uri: source});
|
|
|
|
String filePath = posix.join(projPath, 'foo.dart');
|
|
|
|
resourceProvider.newFile(filePath, 'contents');
|
|
|
|
manager.setRoots(<String>[projPath], <String>[], <String, String>{});
|
|
|
|
|
|
|
|
List<AnalysisContext> contextsInAnalysisRoot =
|
|
|
|
manager.contextsInAnalysisRoot(resourceProvider.newFolder(projPath));
|
|
|
|
expect(contextsInAnalysisRoot, hasLength(1));
|
|
|
|
AnalysisContext context = contextsInAnalysisRoot[0];
|
|
|
|
expect(context, isNotNull);
|
|
|
|
Source result = context.sourceFactory.forUri2(uri);
|
|
|
|
expect(result, same(source));
|
|
|
|
}
|
|
|
|
|
2015-09-28 21:10:32 +00:00
|
|
|
void test_setRoots_pathContainsDotFile() {
|
|
|
|
// If the path to a file (relative to the context root) contains a folder
|
|
|
|
// whose name begins with '.', then the file is ignored.
|
|
|
|
String project = '/project';
|
|
|
|
String fileA = '$project/foo.dart';
|
|
|
|
String fileB = '$project/.pub/bar.dart';
|
|
|
|
resourceProvider.newFile(fileA, '');
|
|
|
|
resourceProvider.newFile(fileB, '');
|
|
|
|
manager.setRoots(<String>[project], <String>[], <String, String>{});
|
|
|
|
callbacks.assertContextPaths([project]);
|
|
|
|
callbacks.assertContextFiles(project, [fileA]);
|
|
|
|
}
|
|
|
|
|
2015-02-26 17:24:08 +00:00
|
|
|
void test_setRoots_removeFolderWithoutPubspec() {
|
|
|
|
packageMapProvider.packageMap = null;
|
|
|
|
// add one root - there is a context
|
|
|
|
manager.setRoots(<String>[projPath], <String>[], <String, String>{});
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
expect(callbacks.currentContextPaths, hasLength(1));
|
2015-02-26 17:24:08 +00:00
|
|
|
// set empty roots - no contexts
|
|
|
|
manager.setRoots(<String>[], <String>[], <String, String>{});
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
expect(callbacks.currentContextPaths, hasLength(0));
|
|
|
|
expect(callbacks.currentContextFilePaths, hasLength(0));
|
2015-02-26 17:24:08 +00:00
|
|
|
}
|
|
|
|
|
2015-07-19 05:18:30 +00:00
|
|
|
void test_setRoots_removeFolderWithPackagespec() {
|
|
|
|
// create a pubspec
|
|
|
|
String pubspecPath = posix.join(projPath, '.packages');
|
|
|
|
resourceProvider.newFile(pubspecPath, '');
|
|
|
|
// add one root - there is a context
|
|
|
|
manager.setRoots(<String>[projPath], <String>[], <String, String>{});
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
expect(callbacks.currentContextPaths, hasLength(1));
|
2015-07-19 05:18:30 +00:00
|
|
|
// set empty roots - no contexts
|
|
|
|
manager.setRoots(<String>[], <String>[], <String, String>{});
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
expect(callbacks.currentContextPaths, hasLength(0));
|
|
|
|
expect(callbacks.currentContextFilePaths, hasLength(0));
|
2015-07-19 05:18:30 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void test_setRoots_removeFolderWithPackagespecFolder() {
|
|
|
|
// prepare paths
|
|
|
|
String projectA = '/projectA';
|
|
|
|
String projectB = '/projectB';
|
|
|
|
String subProjectA = '$projectA/sub';
|
|
|
|
String subProjectB = '$projectB/sub';
|
|
|
|
String projectA_file = '$projectA/a.dart';
|
|
|
|
String projectB_file = '$projectB/a.dart';
|
|
|
|
String subProjectA_pubspec = '$subProjectA/.packages';
|
|
|
|
String subProjectB_pubspec = '$subProjectB/.packages';
|
|
|
|
String subProjectA_file = '$subProjectA/bin/sub_a.dart';
|
|
|
|
String subProjectB_file = '$subProjectB/bin/sub_b.dart';
|
|
|
|
// create files
|
|
|
|
resourceProvider.newFile(projectA_file, '// a');
|
|
|
|
resourceProvider.newFile(projectB_file, '// b');
|
|
|
|
resourceProvider.newFile(subProjectA_pubspec, '');
|
|
|
|
resourceProvider.newFile(subProjectB_pubspec, '');
|
|
|
|
resourceProvider.newFile(subProjectA_file, '// sub-a');
|
|
|
|
resourceProvider.newFile(subProjectB_file, '// sub-b');
|
|
|
|
// set roots
|
|
|
|
manager.setRoots(
|
|
|
|
<String>[projectA, projectB], <String>[], <String, String>{});
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
callbacks
|
|
|
|
.assertContextPaths([projectA, subProjectA, projectB, subProjectB]);
|
|
|
|
callbacks.assertContextFiles(projectA, [projectA_file]);
|
|
|
|
callbacks.assertContextFiles(projectB, [projectB_file]);
|
|
|
|
callbacks.assertContextFiles(subProjectA, [subProjectA_file]);
|
|
|
|
callbacks.assertContextFiles(subProjectB, [subProjectB_file]);
|
2015-07-19 05:18:30 +00:00
|
|
|
// remove "projectB"
|
|
|
|
manager.setRoots(<String>[projectA], <String>[], <String, String>{});
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
callbacks.assertContextPaths([projectA, subProjectA]);
|
|
|
|
callbacks.assertContextFiles(projectA, [projectA_file]);
|
|
|
|
callbacks.assertContextFiles(subProjectA, [subProjectA_file]);
|
2015-07-19 05:18:30 +00:00
|
|
|
}
|
|
|
|
|
2014-08-07 18:04:21 +00:00
|
|
|
void test_setRoots_removeFolderWithPubspec() {
|
|
|
|
// create a pubspec
|
|
|
|
String pubspecPath = posix.join(projPath, 'pubspec.yaml');
|
|
|
|
resourceProvider.newFile(pubspecPath, 'pubspec');
|
|
|
|
// add one root - there is a context
|
2014-10-23 00:11:36 +00:00
|
|
|
manager.setRoots(<String>[projPath], <String>[], <String, String>{});
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
expect(callbacks.currentContextPaths, hasLength(1));
|
2014-08-07 18:04:21 +00:00
|
|
|
// set empty roots - no contexts
|
2014-10-23 00:11:36 +00:00
|
|
|
manager.setRoots(<String>[], <String>[], <String, String>{});
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
expect(callbacks.currentContextPaths, hasLength(0));
|
|
|
|
expect(callbacks.currentContextFilePaths, hasLength(0));
|
2014-08-07 18:04:21 +00:00
|
|
|
}
|
|
|
|
|
2014-08-08 15:55:06 +00:00
|
|
|
void test_setRoots_removeFolderWithPubspecFolder() {
|
|
|
|
// prepare paths
|
|
|
|
String projectA = '/projectA';
|
|
|
|
String projectB = '/projectB';
|
|
|
|
String subProjectA = '$projectA/sub';
|
|
|
|
String subProjectB = '$projectB/sub';
|
|
|
|
String projectA_file = '$projectA/a.dart';
|
|
|
|
String projectB_file = '$projectB/a.dart';
|
|
|
|
String subProjectA_pubspec = '$subProjectA/pubspec.yaml';
|
|
|
|
String subProjectB_pubspec = '$subProjectB/pubspec.yaml';
|
|
|
|
String subProjectA_file = '$subProjectA/bin/sub_a.dart';
|
|
|
|
String subProjectB_file = '$subProjectB/bin/sub_b.dart';
|
|
|
|
// create files
|
|
|
|
resourceProvider.newFile(projectA_file, '// a');
|
|
|
|
resourceProvider.newFile(projectB_file, '// b');
|
|
|
|
resourceProvider.newFile(subProjectA_pubspec, 'pubspec');
|
|
|
|
resourceProvider.newFile(subProjectB_pubspec, 'pubspec');
|
|
|
|
resourceProvider.newFile(subProjectA_file, '// sub-a');
|
|
|
|
resourceProvider.newFile(subProjectB_file, '// sub-b');
|
|
|
|
// set roots
|
2014-11-17 22:23:53 +00:00
|
|
|
manager.setRoots(
|
2015-03-02 22:43:12 +00:00
|
|
|
<String>[projectA, projectB], <String>[], <String, String>{});
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
callbacks
|
|
|
|
.assertContextPaths([projectA, subProjectA, projectB, subProjectB]);
|
|
|
|
callbacks.assertContextFiles(projectA, [projectA_file]);
|
|
|
|
callbacks.assertContextFiles(projectB, [projectB_file]);
|
|
|
|
callbacks.assertContextFiles(subProjectA, [subProjectA_file]);
|
|
|
|
callbacks.assertContextFiles(subProjectB, [subProjectB_file]);
|
2014-08-08 15:55:06 +00:00
|
|
|
// remove "projectB"
|
2014-10-23 00:11:36 +00:00
|
|
|
manager.setRoots(<String>[projectA], <String>[], <String, String>{});
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
callbacks.assertContextPaths([projectA, subProjectA]);
|
|
|
|
callbacks.assertContextFiles(projectA, [projectA_file]);
|
|
|
|
callbacks.assertContextFiles(subProjectA, [subProjectA_file]);
|
2014-10-24 20:29:24 +00:00
|
|
|
}
|
|
|
|
|
2015-07-26 22:08:58 +00:00
|
|
|
void test_setRoots_removePackageRoot() {
|
|
|
|
String packagePathFoo = '/package1/foo';
|
|
|
|
String packageRootPath = '/package2/foo';
|
|
|
|
Folder packageFolder = resourceProvider.newFolder(packagePathFoo);
|
2015-08-05 15:13:28 +00:00
|
|
|
packageMapProvider.packageMap = {
|
|
|
|
'foo': [packageFolder]
|
|
|
|
};
|
2015-07-26 22:08:58 +00:00
|
|
|
List<String> includedPaths = <String>[projPath];
|
|
|
|
List<String> excludedPaths = <String>[];
|
2015-08-05 15:13:28 +00:00
|
|
|
manager.setRoots(includedPaths, excludedPaths,
|
|
|
|
<String, String>{projPath: packageRootPath});
|
2015-07-26 22:08:58 +00:00
|
|
|
_checkPackageRoot(projPath, equals(packageRootPath));
|
|
|
|
manager.setRoots(includedPaths, excludedPaths, <String, String>{});
|
|
|
|
_checkPackageMap(projPath, equals(packageMapProvider.packageMap));
|
|
|
|
}
|
|
|
|
|
2015-09-28 21:10:32 +00:00
|
|
|
void test_setRoots_rootPathContainsDotFile() {
|
|
|
|
// If the path to the context root itself contains a folder whose name
|
|
|
|
// begins with '.', then that is not sufficient to cause any files in the
|
|
|
|
// context to be ignored.
|
|
|
|
String project = '/.pub/project';
|
|
|
|
String fileA = '$project/foo.dart';
|
|
|
|
resourceProvider.newFile(fileA, '');
|
|
|
|
manager.setRoots(<String>[project], <String>[], <String, String>{});
|
|
|
|
callbacks.assertContextPaths([project]);
|
|
|
|
callbacks.assertContextFiles(project, [fileA]);
|
|
|
|
}
|
|
|
|
|
2015-10-13 20:22:49 +00:00
|
|
|
test_strong_mode_analysis_option() async {
|
|
|
|
// Create files.
|
|
|
|
newFile(
|
2015-10-28 16:59:05 +00:00
|
|
|
[projPath, AnalysisEngine.ANALYSIS_OPTIONS_FILE],
|
2015-10-13 20:22:49 +00:00
|
|
|
r'''
|
|
|
|
analyzer:
|
|
|
|
strong-mode: true
|
|
|
|
''');
|
|
|
|
String libPath = newFolder([projPath, LIB_NAME]);
|
|
|
|
newFile([libPath, 'main.dart']);
|
|
|
|
// Setup context.
|
|
|
|
manager.setRoots(<String>[projPath], <String>[], <String, String>{});
|
|
|
|
// Verify that analysis options was parsed and strong-mode set.
|
|
|
|
Map<String, int> fileTimestamps =
|
|
|
|
callbacks.currentContextFilePaths[projPath];
|
|
|
|
expect(fileTimestamps, isNotEmpty);
|
|
|
|
expect(callbacks.currentContext.analysisOptions.strongMode, true);
|
|
|
|
}
|
|
|
|
|
2014-08-07 18:04:21 +00:00
|
|
|
test_watch_addDummyLink() {
|
2014-10-23 00:11:36 +00:00
|
|
|
manager.setRoots(<String>[projPath], <String>[], <String, String>{});
|
2014-08-07 18:04:21 +00:00
|
|
|
// empty folder initially
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
Map<String, int> filePaths = callbacks.currentContextFilePaths[projPath];
|
2014-08-07 18:04:21 +00:00
|
|
|
expect(filePaths, isEmpty);
|
|
|
|
// add link
|
|
|
|
String filePath = posix.join(projPath, 'foo.dart');
|
|
|
|
resourceProvider.newDummyLink(filePath);
|
|
|
|
// the link was ignored
|
|
|
|
return pumpEventQueue().then((_) {
|
|
|
|
expect(filePaths, isEmpty);
|
|
|
|
});
|
|
|
|
}
|
|
|
|
|
|
|
|
test_watch_addFile() {
|
2014-10-23 00:11:36 +00:00
|
|
|
manager.setRoots(<String>[projPath], <String>[], <String, String>{});
|
2014-08-07 18:04:21 +00:00
|
|
|
// empty folder initially
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
Map<String, int> filePaths = callbacks.currentContextFilePaths[projPath];
|
2014-08-07 18:04:21 +00:00
|
|
|
expect(filePaths, hasLength(0));
|
|
|
|
// add file
|
|
|
|
String filePath = posix.join(projPath, 'foo.dart');
|
|
|
|
resourceProvider.newFile(filePath, 'contents');
|
|
|
|
// the file was added
|
|
|
|
return pumpEventQueue().then((_) {
|
|
|
|
expect(filePaths, hasLength(1));
|
|
|
|
expect(filePaths, contains(filePath));
|
|
|
|
});
|
|
|
|
}
|
|
|
|
|
2014-08-08 19:42:07 +00:00
|
|
|
test_watch_addFile_excluded() {
|
|
|
|
// prepare paths
|
|
|
|
String project = '/project';
|
|
|
|
String folderA = '$project/aaa';
|
|
|
|
String folderB = '$project/bbb';
|
|
|
|
String fileA = '$folderA/a.dart';
|
|
|
|
String fileB = '$folderB/b.dart';
|
|
|
|
// create files
|
|
|
|
resourceProvider.newFile(fileA, 'library a;');
|
|
|
|
// set roots
|
2014-10-23 00:11:36 +00:00
|
|
|
manager.setRoots(<String>[project], <String>[folderB], <String, String>{});
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
callbacks.assertContextPaths([project]);
|
|
|
|
callbacks.assertContextFiles(project, [fileA]);
|
2014-08-08 19:42:07 +00:00
|
|
|
// add a file, ignored as excluded
|
|
|
|
resourceProvider.newFile(fileB, 'library b;');
|
|
|
|
return pumpEventQueue().then((_) {
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
callbacks.assertContextPaths([project]);
|
|
|
|
callbacks.assertContextFiles(project, [fileA]);
|
2014-08-08 19:42:07 +00:00
|
|
|
});
|
|
|
|
}
|
|
|
|
|
2015-09-28 21:10:32 +00:00
|
|
|
test_watch_addFile_pathContainsDotFile() async {
|
|
|
|
// If a file is added and the path to it (relative to the context root)
|
|
|
|
// contains a folder whose name begins with '.', then the file is ignored.
|
|
|
|
String project = '/project';
|
|
|
|
String fileA = '$project/foo.dart';
|
|
|
|
String fileB = '$project/.pub/bar.dart';
|
|
|
|
resourceProvider.newFile(fileA, '');
|
|
|
|
manager.setRoots(<String>[project], <String>[], <String, String>{});
|
|
|
|
callbacks.assertContextPaths([project]);
|
|
|
|
callbacks.assertContextFiles(project, [fileA]);
|
|
|
|
resourceProvider.newFile(fileB, '');
|
|
|
|
await pumpEventQueue();
|
|
|
|
callbacks.assertContextPaths([project]);
|
|
|
|
callbacks.assertContextFiles(project, [fileA]);
|
|
|
|
}
|
|
|
|
|
|
|
|
test_watch_addFile_rootPathContainsDotFile() async {
|
|
|
|
// If a file is added and the path to the context contains a folder whose
|
|
|
|
// name begins with '.', then the file is not ignored.
|
|
|
|
String project = '/.pub/project';
|
|
|
|
String fileA = '$project/foo.dart';
|
|
|
|
String fileB = '$project/bar/baz.dart';
|
|
|
|
resourceProvider.newFile(fileA, '');
|
|
|
|
manager.setRoots(<String>[project], <String>[], <String, String>{});
|
|
|
|
callbacks.assertContextPaths([project]);
|
|
|
|
callbacks.assertContextFiles(project, [fileA]);
|
|
|
|
resourceProvider.newFile(fileB, '');
|
|
|
|
await pumpEventQueue();
|
|
|
|
callbacks.assertContextPaths([project]);
|
|
|
|
callbacks.assertContextFiles(project, [fileA, fileB]);
|
|
|
|
}
|
|
|
|
|
2015-02-26 17:24:08 +00:00
|
|
|
test_watch_addFileInSubfolder() {
|
|
|
|
manager.setRoots(<String>[projPath], <String>[], <String, String>{});
|
|
|
|
// empty folder initially
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
Map<String, int> filePaths = callbacks.currentContextFilePaths[projPath];
|
2015-02-26 17:24:08 +00:00
|
|
|
expect(filePaths, hasLength(0));
|
|
|
|
// add file in subfolder
|
|
|
|
String filePath = posix.join(projPath, 'foo', 'bar.dart');
|
|
|
|
resourceProvider.newFile(filePath, 'contents');
|
|
|
|
// the file was added
|
|
|
|
return pumpEventQueue().then((_) {
|
|
|
|
expect(filePaths, hasLength(1));
|
|
|
|
expect(filePaths, contains(filePath));
|
|
|
|
});
|
|
|
|
}
|
|
|
|
|
2015-07-19 05:18:30 +00:00
|
|
|
test_watch_addPackagespec_toRoot() {
|
|
|
|
// prepare paths
|
|
|
|
String root = '/root';
|
|
|
|
String rootFile = '$root/root.dart';
|
|
|
|
String rootPackagespec = '$root/.packages';
|
|
|
|
// create files
|
|
|
|
resourceProvider.newFile(rootFile, 'library root;');
|
|
|
|
// set roots
|
|
|
|
manager.setRoots(<String>[root], <String>[], <String, String>{});
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
callbacks.assertContextPaths([root]);
|
2015-07-19 05:18:30 +00:00
|
|
|
// verify files
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
callbacks.assertContextFiles(root, [rootFile]);
|
2015-07-19 05:18:30 +00:00
|
|
|
// add packagespec - still just one root
|
|
|
|
resourceProvider.newFile(rootPackagespec, '');
|
|
|
|
return pumpEventQueue().then((_) {
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
callbacks.assertContextPaths([root]);
|
|
|
|
callbacks.assertContextFiles(root, [rootFile]);
|
2015-07-19 05:18:30 +00:00
|
|
|
// TODO(pquitslund): verify that a new source factory is created --
|
|
|
|
// likely this will need to happen in a corresponding ServerContextManagerTest.
|
|
|
|
});
|
|
|
|
}
|
|
|
|
|
|
|
|
test_watch_addPackagespec_toSubFolder() {
|
|
|
|
// prepare paths
|
|
|
|
String root = '/root';
|
|
|
|
String rootFile = '$root/root.dart';
|
|
|
|
String subProject = '$root/sub/aaa';
|
|
|
|
String subPubspec = '$subProject/.packages';
|
|
|
|
String subFile = '$subProject/bin/a.dart';
|
|
|
|
// create files
|
|
|
|
resourceProvider.newFile(rootFile, 'library root;');
|
|
|
|
resourceProvider.newFile(subFile, 'library a;');
|
|
|
|
// set roots
|
|
|
|
manager.setRoots(<String>[root], <String>[], <String, String>{});
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
callbacks.assertContextPaths([root]);
|
2015-07-19 05:18:30 +00:00
|
|
|
// verify files
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
callbacks.assertContextFiles(root, [rootFile, subFile]);
|
2015-07-19 05:18:30 +00:00
|
|
|
// add .packages
|
|
|
|
resourceProvider.newFile(subPubspec, '');
|
|
|
|
return pumpEventQueue().then((_) {
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
callbacks.assertContextPaths([root, subProject]);
|
|
|
|
callbacks.assertContextFiles(root, [rootFile]);
|
|
|
|
callbacks.assertContextFiles(subProject, [subFile]);
|
2015-07-19 05:18:30 +00:00
|
|
|
});
|
|
|
|
}
|
|
|
|
|
|
|
|
test_watch_addPackagespec_toSubFolder_ofSubFolder() {
|
|
|
|
// prepare paths
|
|
|
|
String root = '/root';
|
|
|
|
String rootFile = '$root/root.dart';
|
|
|
|
String subProject = '$root/sub';
|
|
|
|
String subPubspec = '$subProject/.packages';
|
|
|
|
String subFile = '$subProject/bin/sub.dart';
|
|
|
|
String subSubPubspec = '$subProject/subsub/.packages';
|
|
|
|
// create files
|
|
|
|
resourceProvider.newFile(rootFile, 'library root;');
|
|
|
|
resourceProvider.newFile(subPubspec, '');
|
|
|
|
resourceProvider.newFile(subFile, 'library sub;');
|
|
|
|
// set roots
|
|
|
|
manager.setRoots(<String>[root], <String>[], <String, String>{});
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
callbacks.assertContextPaths([root, subProject]);
|
|
|
|
callbacks.assertContextFiles(root, [rootFile]);
|
|
|
|
callbacks.assertContextFiles(subProject, [subFile]);
|
2015-07-19 05:18:30 +00:00
|
|
|
// add pubspec - ignore, because is already in a packagespec-based context
|
|
|
|
resourceProvider.newFile(subSubPubspec, '');
|
|
|
|
return pumpEventQueue().then((_) {
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
callbacks.assertContextPaths([root, subProject]);
|
|
|
|
callbacks.assertContextFiles(root, [rootFile]);
|
|
|
|
callbacks.assertContextFiles(subProject, [subFile]);
|
2015-07-19 05:18:30 +00:00
|
|
|
});
|
|
|
|
}
|
|
|
|
|
|
|
|
test_watch_addPackagespec_toSubFolder_withPubspec() {
|
|
|
|
// prepare paths
|
|
|
|
String root = '/root';
|
|
|
|
String rootFile = '$root/root.dart';
|
|
|
|
String subProject = '$root/sub/aaa';
|
|
|
|
String subPackagespec = '$subProject/.packages';
|
|
|
|
String subPubspec = '$subProject/pubspec.yaml';
|
|
|
|
String subFile = '$subProject/bin/a.dart';
|
|
|
|
// create files
|
|
|
|
resourceProvider.newFile(subPubspec, 'pubspec');
|
|
|
|
resourceProvider.newFile(rootFile, 'library root;');
|
|
|
|
resourceProvider.newFile(subFile, 'library a;');
|
|
|
|
// set roots
|
|
|
|
manager.setRoots(<String>[root], <String>[], <String, String>{});
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
callbacks.assertContextPaths([root, subProject]);
|
2015-07-19 05:18:30 +00:00
|
|
|
// verify files
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
callbacks.assertContextFiles(root, [rootFile]);
|
|
|
|
callbacks.assertContextFiles(subProject, [subFile]);
|
2015-07-19 05:18:30 +00:00
|
|
|
|
|
|
|
// add .packages
|
|
|
|
resourceProvider.newFile(subPackagespec, '');
|
|
|
|
return pumpEventQueue().then((_) {
|
|
|
|
// Should NOT create another context.
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
callbacks.assertContextPaths([root, subProject]);
|
|
|
|
callbacks.assertContextFiles(root, [rootFile]);
|
|
|
|
callbacks.assertContextFiles(subProject, [subFile]);
|
2015-07-19 05:18:30 +00:00
|
|
|
});
|
|
|
|
}
|
|
|
|
|
2014-08-08 17:19:46 +00:00
|
|
|
test_watch_addPubspec_toRoot() {
|
|
|
|
// prepare paths
|
|
|
|
String root = '/root';
|
|
|
|
String rootFile = '$root/root.dart';
|
|
|
|
String rootPubspec = '$root/pubspec.yaml';
|
|
|
|
// create files
|
|
|
|
resourceProvider.newFile(rootFile, 'library root;');
|
|
|
|
// set roots
|
2014-10-23 00:11:36 +00:00
|
|
|
manager.setRoots(<String>[root], <String>[], <String, String>{});
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
callbacks.assertContextPaths([root]);
|
2014-08-08 17:19:46 +00:00
|
|
|
// verify files
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
callbacks.assertContextFiles(root, [rootFile]);
|
2014-08-08 17:19:46 +00:00
|
|
|
// add pubspec - still just one root
|
|
|
|
resourceProvider.newFile(rootPubspec, 'pubspec');
|
|
|
|
return pumpEventQueue().then((_) {
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
callbacks.assertContextPaths([root]);
|
|
|
|
callbacks.assertContextFiles(root, [rootFile]);
|
2014-08-08 17:19:46 +00:00
|
|
|
});
|
|
|
|
}
|
|
|
|
|
|
|
|
test_watch_addPubspec_toSubFolder() {
|
2014-08-08 15:55:06 +00:00
|
|
|
// prepare paths
|
|
|
|
String root = '/root';
|
|
|
|
String rootFile = '$root/root.dart';
|
|
|
|
String subProject = '$root/sub/aaa';
|
|
|
|
String subPubspec = '$subProject/pubspec.yaml';
|
|
|
|
String subFile = '$subProject/bin/a.dart';
|
|
|
|
// create files
|
|
|
|
resourceProvider.newFile(rootFile, 'library root;');
|
|
|
|
resourceProvider.newFile(subFile, 'library a;');
|
|
|
|
// set roots
|
2014-10-23 00:11:36 +00:00
|
|
|
manager.setRoots(<String>[root], <String>[], <String, String>{});
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
callbacks.assertContextPaths([root]);
|
2014-08-08 15:55:06 +00:00
|
|
|
// verify files
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
callbacks.assertContextFiles(root, [rootFile, subFile]);
|
2014-08-08 15:55:06 +00:00
|
|
|
// add pubspec
|
|
|
|
resourceProvider.newFile(subPubspec, 'pubspec');
|
|
|
|
return pumpEventQueue().then((_) {
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
callbacks.assertContextPaths([root, subProject]);
|
|
|
|
callbacks.assertContextFiles(root, [rootFile]);
|
|
|
|
callbacks.assertContextFiles(subProject, [subFile]);
|
2014-08-08 15:55:06 +00:00
|
|
|
});
|
|
|
|
}
|
|
|
|
|
2014-08-08 17:19:46 +00:00
|
|
|
test_watch_addPubspec_toSubFolder_ofSubFolder() {
|
|
|
|
// prepare paths
|
|
|
|
String root = '/root';
|
|
|
|
String rootFile = '$root/root.dart';
|
|
|
|
String subProject = '$root/sub';
|
|
|
|
String subPubspec = '$subProject/pubspec.yaml';
|
|
|
|
String subFile = '$subProject/bin/sub.dart';
|
|
|
|
String subSubPubspec = '$subProject/subsub/pubspec.yaml';
|
|
|
|
// create files
|
|
|
|
resourceProvider.newFile(rootFile, 'library root;');
|
|
|
|
resourceProvider.newFile(subPubspec, 'pubspec');
|
|
|
|
resourceProvider.newFile(subFile, 'library sub;');
|
|
|
|
// set roots
|
2014-10-23 00:11:36 +00:00
|
|
|
manager.setRoots(<String>[root], <String>[], <String, String>{});
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
callbacks.assertContextPaths([root, subProject]);
|
|
|
|
callbacks.assertContextFiles(root, [rootFile]);
|
|
|
|
callbacks.assertContextFiles(subProject, [subFile]);
|
2014-08-08 17:19:46 +00:00
|
|
|
// add pubspec - ignore, because is already in a pubspec-based context
|
|
|
|
resourceProvider.newFile(subSubPubspec, 'pubspec');
|
|
|
|
return pumpEventQueue().then((_) {
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
callbacks.assertContextPaths([root, subProject]);
|
|
|
|
callbacks.assertContextFiles(root, [rootFile]);
|
|
|
|
callbacks.assertContextFiles(subProject, [subFile]);
|
2014-08-08 17:19:46 +00:00
|
|
|
});
|
|
|
|
}
|
|
|
|
|
2014-08-07 18:04:21 +00:00
|
|
|
test_watch_deleteFile() {
|
|
|
|
String filePath = posix.join(projPath, 'foo.dart');
|
|
|
|
// add root with a file
|
2015-02-26 17:24:08 +00:00
|
|
|
File file = resourceProvider.newFile(filePath, 'contents');
|
|
|
|
Folder projFolder = file.parent;
|
2014-10-23 00:11:36 +00:00
|
|
|
manager.setRoots(<String>[projPath], <String>[], <String, String>{});
|
2014-08-07 18:04:21 +00:00
|
|
|
// the file was added
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
Map<String, int> filePaths = callbacks.currentContextFilePaths[projPath];
|
2014-08-07 18:04:21 +00:00
|
|
|
expect(filePaths, hasLength(1));
|
|
|
|
expect(filePaths, contains(filePath));
|
2015-02-26 17:24:08 +00:00
|
|
|
expect(file.exists, isTrue);
|
|
|
|
expect(projFolder.exists, isTrue);
|
2014-08-07 18:04:21 +00:00
|
|
|
// delete the file
|
|
|
|
resourceProvider.deleteFile(filePath);
|
|
|
|
return pumpEventQueue().then((_) {
|
2015-02-26 17:24:08 +00:00
|
|
|
expect(file.exists, isFalse);
|
|
|
|
expect(projFolder.exists, isTrue);
|
|
|
|
return expect(filePaths, hasLength(0));
|
|
|
|
});
|
|
|
|
}
|
|
|
|
|
|
|
|
test_watch_deleteFolder() {
|
|
|
|
String filePath = posix.join(projPath, 'foo.dart');
|
|
|
|
// add root with a file
|
|
|
|
File file = resourceProvider.newFile(filePath, 'contents');
|
|
|
|
Folder projFolder = file.parent;
|
|
|
|
manager.setRoots(<String>[projPath], <String>[], <String, String>{});
|
|
|
|
// the file was added
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
Map<String, int> filePaths = callbacks.currentContextFilePaths[projPath];
|
2015-02-26 17:24:08 +00:00
|
|
|
expect(filePaths, hasLength(1));
|
|
|
|
expect(filePaths, contains(filePath));
|
|
|
|
expect(file.exists, isTrue);
|
|
|
|
expect(projFolder.exists, isTrue);
|
|
|
|
// delete the folder
|
|
|
|
resourceProvider.deleteFolder(projPath);
|
|
|
|
return pumpEventQueue().then((_) {
|
|
|
|
expect(file.exists, isFalse);
|
|
|
|
expect(projFolder.exists, isFalse);
|
2014-08-07 18:04:21 +00:00
|
|
|
return expect(filePaths, hasLength(0));
|
|
|
|
});
|
|
|
|
}
|
|
|
|
|
2015-07-19 05:18:30 +00:00
|
|
|
test_watch_deletePackagespec_fromRoot() {
|
|
|
|
// prepare paths
|
|
|
|
String root = '/root';
|
|
|
|
String rootPubspec = '$root/.packages';
|
|
|
|
String rootFile = '$root/root.dart';
|
|
|
|
// create files
|
|
|
|
resourceProvider.newFile(rootPubspec, '');
|
|
|
|
resourceProvider.newFile(rootFile, 'library root;');
|
|
|
|
// set roots
|
|
|
|
manager.setRoots(<String>[root], <String>[], <String, String>{});
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
callbacks.assertContextPaths([root]);
|
|
|
|
callbacks.assertContextFiles(root, [rootFile]);
|
2015-07-19 05:18:30 +00:00
|
|
|
// delete the pubspec
|
|
|
|
resourceProvider.deleteFile(rootPubspec);
|
|
|
|
return pumpEventQueue().then((_) {
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
callbacks.assertContextPaths([root]);
|
|
|
|
callbacks.assertContextFiles(root, [rootFile]);
|
2015-07-19 05:18:30 +00:00
|
|
|
});
|
|
|
|
}
|
|
|
|
|
|
|
|
test_watch_deletePackagespec_fromSubFolder() {
|
|
|
|
// prepare paths
|
|
|
|
String root = '/root';
|
|
|
|
String rootFile = '$root/root.dart';
|
|
|
|
String subProject = '$root/sub/aaa';
|
|
|
|
String subPubspec = '$subProject/.packages';
|
|
|
|
String subFile = '$subProject/bin/a.dart';
|
|
|
|
// create files
|
|
|
|
resourceProvider.newFile(subPubspec, '');
|
|
|
|
resourceProvider.newFile(rootFile, 'library root;');
|
|
|
|
resourceProvider.newFile(subFile, 'library a;');
|
|
|
|
// set roots
|
|
|
|
manager.setRoots(<String>[root], <String>[], <String, String>{});
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
callbacks.assertContextPaths([root, subProject]);
|
2015-07-19 05:18:30 +00:00
|
|
|
// verify files
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
callbacks.assertContextFiles(root, [rootFile]);
|
|
|
|
callbacks.assertContextFiles(subProject, [subFile]);
|
2015-07-19 05:18:30 +00:00
|
|
|
// delete the pubspec
|
|
|
|
resourceProvider.deleteFile(subPubspec);
|
|
|
|
return pumpEventQueue().then((_) {
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
callbacks.assertContextPaths([root]);
|
|
|
|
callbacks.assertContextFiles(root, [rootFile, subFile]);
|
2015-07-19 05:18:30 +00:00
|
|
|
});
|
|
|
|
}
|
|
|
|
|
|
|
|
test_watch_deletePackagespec_fromSubFolder_withPubspec() {
|
2015-08-10 20:10:08 +00:00
|
|
|
// prepare paths:
|
|
|
|
//
|
|
|
|
// root
|
|
|
|
// root.dart
|
|
|
|
// sub
|
|
|
|
// aaa
|
|
|
|
// .packages
|
|
|
|
// pubspec.yaml
|
|
|
|
// bin
|
|
|
|
// a.dart
|
|
|
|
//
|
2015-07-19 05:18:30 +00:00
|
|
|
String root = '/root';
|
|
|
|
String rootFile = '$root/root.dart';
|
|
|
|
String subProject = '$root/sub/aaa';
|
|
|
|
String subPackagespec = '$subProject/.packages';
|
|
|
|
String subPubspec = '$subProject/pubspec.yaml';
|
|
|
|
String subFile = '$subProject/bin/a.dart';
|
|
|
|
// create files
|
|
|
|
resourceProvider.newFile(subPackagespec, '');
|
|
|
|
resourceProvider.newFile(subPubspec, 'pubspec');
|
|
|
|
resourceProvider.newFile(rootFile, 'library root;');
|
|
|
|
resourceProvider.newFile(subFile, 'library a;');
|
|
|
|
// set roots
|
|
|
|
manager.setRoots(<String>[root], <String>[], <String, String>{});
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
callbacks.assertContextPaths([root, subProject]);
|
2015-07-19 05:18:30 +00:00
|
|
|
// verify files
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
callbacks.assertContextFiles(root, [rootFile]);
|
|
|
|
callbacks.assertContextFiles(subProject, [subFile]);
|
2015-07-19 05:18:30 +00:00
|
|
|
// delete the packagespec
|
|
|
|
resourceProvider.deleteFile(subPackagespec);
|
|
|
|
return pumpEventQueue().then((_) {
|
|
|
|
// Should NOT merge
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
callbacks.assertContextPaths([root, subProject]);
|
|
|
|
callbacks.assertContextFiles(subProject, [subFile]);
|
2015-07-19 05:18:30 +00:00
|
|
|
});
|
|
|
|
}
|
|
|
|
|
2014-08-08 17:19:46 +00:00
|
|
|
test_watch_deletePubspec_fromRoot() {
|
|
|
|
// prepare paths
|
|
|
|
String root = '/root';
|
|
|
|
String rootPubspec = '$root/pubspec.yaml';
|
|
|
|
String rootFile = '$root/root.dart';
|
|
|
|
// create files
|
|
|
|
resourceProvider.newFile(rootPubspec, 'pubspec');
|
|
|
|
resourceProvider.newFile(rootFile, 'library root;');
|
|
|
|
// set roots
|
2014-10-23 00:11:36 +00:00
|
|
|
manager.setRoots(<String>[root], <String>[], <String, String>{});
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
callbacks.assertContextPaths([root]);
|
|
|
|
callbacks.assertContextFiles(root, [rootFile]);
|
2014-08-08 17:19:46 +00:00
|
|
|
// delete the pubspec
|
|
|
|
resourceProvider.deleteFile(rootPubspec);
|
|
|
|
return pumpEventQueue().then((_) {
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
callbacks.assertContextPaths([root]);
|
|
|
|
callbacks.assertContextFiles(root, [rootFile]);
|
2014-08-08 17:19:46 +00:00
|
|
|
});
|
|
|
|
}
|
|
|
|
|
|
|
|
test_watch_deletePubspec_fromSubFolder() {
|
2014-08-08 15:55:06 +00:00
|
|
|
// prepare paths
|
|
|
|
String root = '/root';
|
|
|
|
String rootFile = '$root/root.dart';
|
|
|
|
String subProject = '$root/sub/aaa';
|
|
|
|
String subPubspec = '$subProject/pubspec.yaml';
|
|
|
|
String subFile = '$subProject/bin/a.dart';
|
|
|
|
// create files
|
|
|
|
resourceProvider.newFile(subPubspec, 'pubspec');
|
|
|
|
resourceProvider.newFile(rootFile, 'library root;');
|
|
|
|
resourceProvider.newFile(subFile, 'library a;');
|
|
|
|
// set roots
|
2014-10-23 00:11:36 +00:00
|
|
|
manager.setRoots(<String>[root], <String>[], <String, String>{});
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
callbacks.assertContextPaths([root, subProject]);
|
2014-08-08 15:55:06 +00:00
|
|
|
// verify files
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
callbacks.assertContextFiles(root, [rootFile]);
|
|
|
|
callbacks.assertContextFiles(subProject, [subFile]);
|
2014-08-08 15:55:06 +00:00
|
|
|
// delete the pubspec
|
|
|
|
resourceProvider.deleteFile(subPubspec);
|
|
|
|
return pumpEventQueue().then((_) {
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
callbacks.assertContextPaths([root]);
|
|
|
|
callbacks.assertContextFiles(root, [rootFile, subFile]);
|
2014-08-08 15:55:06 +00:00
|
|
|
});
|
|
|
|
}
|
|
|
|
|
2014-08-07 18:04:21 +00:00
|
|
|
test_watch_modifyFile() {
|
|
|
|
String filePath = posix.join(projPath, 'foo.dart');
|
|
|
|
// add root with a file
|
|
|
|
resourceProvider.newFile(filePath, 'contents');
|
2014-10-23 00:11:36 +00:00
|
|
|
manager.setRoots(<String>[projPath], <String>[], <String, String>{});
|
2014-08-07 18:04:21 +00:00
|
|
|
// the file was added
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
Map<String, int> filePaths = callbacks.currentContextFilePaths[projPath];
|
2014-08-07 18:04:21 +00:00
|
|
|
expect(filePaths, hasLength(1));
|
|
|
|
expect(filePaths, contains(filePath));
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
expect(filePaths[filePath], equals(callbacks.now));
|
2014-08-07 18:04:21 +00:00
|
|
|
// update the file
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
callbacks.now++;
|
2014-08-07 18:04:21 +00:00
|
|
|
resourceProvider.modifyFile(filePath, 'new contents');
|
|
|
|
return pumpEventQueue().then((_) {
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
return expect(filePaths[filePath], equals(callbacks.now));
|
2014-08-07 18:04:21 +00:00
|
|
|
});
|
|
|
|
}
|
|
|
|
|
|
|
|
test_watch_modifyPackageMapDependency() {
|
|
|
|
// create a dependency file
|
|
|
|
String dependencyPath = posix.join(projPath, 'dep');
|
|
|
|
resourceProvider.newFile(dependencyPath, 'contents');
|
|
|
|
packageMapProvider.dependencies.add(dependencyPath);
|
|
|
|
// create a Dart file
|
|
|
|
String dartFilePath = posix.join(projPath, 'main.dart');
|
|
|
|
resourceProvider.newFile(dartFilePath, 'contents');
|
|
|
|
// the created context has the expected empty package map
|
2014-10-23 00:11:36 +00:00
|
|
|
manager.setRoots(<String>[projPath], <String>[], <String, String>{});
|
2014-10-24 20:29:24 +00:00
|
|
|
_checkPackageMap(projPath, isEmpty);
|
2014-08-07 18:04:21 +00:00
|
|
|
// configure package map
|
|
|
|
String packagePath = '/package/foo';
|
|
|
|
resourceProvider.newFolder(packagePath);
|
2015-03-02 22:43:12 +00:00
|
|
|
packageMapProvider.packageMap = {'foo': projPath};
|
2014-08-07 18:04:21 +00:00
|
|
|
// Changing a .dart file in the project shouldn't cause a new
|
|
|
|
// package map to be picked up.
|
|
|
|
resourceProvider.modifyFile(dartFilePath, 'new contents');
|
|
|
|
return pumpEventQueue().then((_) {
|
2014-10-24 20:29:24 +00:00
|
|
|
_checkPackageMap(projPath, isEmpty);
|
2014-08-07 18:04:21 +00:00
|
|
|
// However, changing the package map dependency should.
|
|
|
|
resourceProvider.modifyFile(dependencyPath, 'new contents');
|
|
|
|
return pumpEventQueue().then((_) {
|
2014-10-24 20:29:24 +00:00
|
|
|
_checkPackageMap(projPath, equals(packageMapProvider.packageMap));
|
2014-08-07 18:04:21 +00:00
|
|
|
});
|
|
|
|
});
|
|
|
|
}
|
|
|
|
|
|
|
|
test_watch_modifyPackageMapDependency_fail() {
|
|
|
|
// create a dependency file
|
|
|
|
String dependencyPath = posix.join(projPath, 'dep');
|
|
|
|
resourceProvider.newFile(dependencyPath, 'contents');
|
|
|
|
packageMapProvider.dependencies.add(dependencyPath);
|
|
|
|
// create a Dart file
|
|
|
|
String dartFilePath = posix.join(projPath, 'main.dart');
|
|
|
|
resourceProvider.newFile(dartFilePath, 'contents');
|
|
|
|
// the created context has the expected empty package map
|
2014-10-23 00:11:36 +00:00
|
|
|
manager.setRoots(<String>[projPath], <String>[], <String, String>{});
|
2014-10-24 20:29:24 +00:00
|
|
|
_checkPackageMap(projPath, isEmpty);
|
2014-08-07 18:04:21 +00:00
|
|
|
// Change the package map dependency so that the packageMapProvider is
|
|
|
|
// re-run, and arrange for it to return null from computePackageMap().
|
|
|
|
packageMapProvider.packageMap = null;
|
|
|
|
resourceProvider.modifyFile(dependencyPath, 'new contents');
|
|
|
|
return pumpEventQueue().then((_) {
|
|
|
|
// The package map should have been changed to null.
|
2014-10-24 20:29:24 +00:00
|
|
|
_checkPackageMap(projPath, isNull);
|
2014-08-07 18:04:21 +00:00
|
|
|
});
|
|
|
|
}
|
2014-10-24 20:29:24 +00:00
|
|
|
|
2015-07-19 05:18:30 +00:00
|
|
|
test_watch_modifyPackagespec() {
|
|
|
|
String packagesPath = '$projPath/.packages';
|
|
|
|
String filePath = '$projPath/bin/main.dart';
|
|
|
|
|
|
|
|
resourceProvider.newFile(packagesPath, '');
|
|
|
|
resourceProvider.newFile(filePath, 'library main;');
|
|
|
|
|
|
|
|
manager.setRoots(<String>[projPath], <String>[], <String, String>{});
|
|
|
|
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
Map<String, int> filePaths = callbacks.currentContextFilePaths[projPath];
|
2015-07-19 05:18:30 +00:00
|
|
|
expect(filePaths, hasLength(1));
|
|
|
|
expect(filePaths, contains(filePath));
|
2015-07-24 13:42:54 +00:00
|
|
|
Packages packages = callbacks.currentContextDispositions[projPath].packages;
|
2015-07-19 05:18:30 +00:00
|
|
|
expect(packages.packages, isEmpty);
|
|
|
|
|
|
|
|
// update .packages
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
callbacks.now++;
|
2015-07-19 05:18:30 +00:00
|
|
|
resourceProvider.modifyFile(packagesPath, 'main:./lib/');
|
|
|
|
return pumpEventQueue().then((_) {
|
|
|
|
// verify new package info
|
2015-07-24 13:42:54 +00:00
|
|
|
packages = callbacks.currentContextDispositions[projPath].packages;
|
2015-07-19 05:18:30 +00:00
|
|
|
expect(packages.packages, unorderedEquals(['main']));
|
|
|
|
});
|
|
|
|
}
|
|
|
|
|
2014-10-24 20:29:24 +00:00
|
|
|
/**
|
|
|
|
* Verify that package URI's for source files in [path] will be resolved
|
|
|
|
* using a package map matching [expectation].
|
|
|
|
*/
|
|
|
|
void _checkPackageMap(String path, expectation) {
|
2015-07-24 13:42:54 +00:00
|
|
|
FolderDisposition disposition = callbacks.currentContextDispositions[path];
|
2015-02-03 16:06:25 +00:00
|
|
|
Map<String, List<Folder>> packageMap =
|
2015-07-24 13:42:54 +00:00
|
|
|
disposition is PackageMapDisposition ? disposition.packageMap : null;
|
2015-02-03 16:06:25 +00:00
|
|
|
expect(packageMap, expectation);
|
2014-10-24 20:29:24 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Verify that package URI's for source files in [path] will be resolved
|
|
|
|
* using a package root maching [expectation].
|
|
|
|
*/
|
|
|
|
void _checkPackageRoot(String path, expectation) {
|
2015-07-26 22:08:58 +00:00
|
|
|
FolderDisposition disposition = callbacks.currentContextDispositions[path];
|
|
|
|
expect(disposition.packageRoot, expectation);
|
|
|
|
// TODO(paulberry): we should also verify that the package map itself is
|
|
|
|
// correct. See dartbug.com/23909.
|
2014-10-24 20:29:24 +00:00
|
|
|
}
|
2014-08-07 18:04:21 +00:00
|
|
|
}
|
|
|
|
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
class TestContextManagerCallbacks extends ContextManagerCallbacks {
|
2014-08-07 18:04:21 +00:00
|
|
|
/**
|
|
|
|
* Source of timestamps stored in [currentContextFilePaths].
|
|
|
|
*/
|
|
|
|
int now = 0;
|
|
|
|
|
2015-03-09 18:28:21 +00:00
|
|
|
/**
|
|
|
|
* The analysis context that was created.
|
|
|
|
*/
|
2015-06-06 15:30:38 +00:00
|
|
|
AnalysisContext currentContext;
|
2015-03-09 18:28:21 +00:00
|
|
|
|
2014-09-10 19:20:09 +00:00
|
|
|
/**
|
|
|
|
* Map from context to the timestamp when the context was created.
|
|
|
|
*/
|
|
|
|
Map<String, int> currentContextTimestamps = <String, int>{};
|
|
|
|
|
2014-08-07 18:04:21 +00:00
|
|
|
/**
|
|
|
|
* Map from context to (map from file path to timestamp of last event).
|
|
|
|
*/
|
2015-03-02 22:43:12 +00:00
|
|
|
final Map<String, Map<String, int>> currentContextFilePaths =
|
|
|
|
<String, Map<String, int>>{};
|
2014-08-07 18:04:21 +00:00
|
|
|
|
2015-02-17 22:47:34 +00:00
|
|
|
/**
|
|
|
|
* A map from the paths of contexts to a set of the sources that should be
|
|
|
|
* explicitly analyzed in those contexts.
|
|
|
|
*/
|
2015-08-05 15:13:28 +00:00
|
|
|
final Map<String, Set<Source>> currentContextSources =
|
|
|
|
<String, Set<Source>>{};
|
2015-02-17 22:47:34 +00:00
|
|
|
|
2014-08-07 18:04:21 +00:00
|
|
|
/**
|
2015-07-24 13:42:54 +00:00
|
|
|
* Map from context to folder disposition.
|
2014-08-07 18:04:21 +00:00
|
|
|
*/
|
2015-07-24 13:42:54 +00:00
|
|
|
final Map<String, FolderDisposition> currentContextDispositions =
|
|
|
|
<String, FolderDisposition>{};
|
2014-08-07 18:04:21 +00:00
|
|
|
|
2015-07-19 05:18:30 +00:00
|
|
|
/**
|
2015-07-24 13:42:54 +00:00
|
|
|
* Resource provider used for this test.
|
2015-07-19 05:18:30 +00:00
|
|
|
*/
|
2015-07-24 13:42:54 +00:00
|
|
|
final ResourceProvider resourceProvider;
|
|
|
|
|
|
|
|
TestContextManagerCallbacks(this.resourceProvider);
|
2015-07-19 05:18:30 +00:00
|
|
|
|
2014-11-17 22:23:53 +00:00
|
|
|
/**
|
|
|
|
* Iterable of the paths to contexts that currently exist.
|
|
|
|
*/
|
|
|
|
Iterable<String> get currentContextPaths => currentContextTimestamps.keys;
|
|
|
|
|
2014-08-07 18:04:21 +00:00
|
|
|
@override
|
2015-07-24 13:42:54 +00:00
|
|
|
AnalysisContext addContext(Folder folder, FolderDisposition disposition) {
|
2014-08-07 18:04:21 +00:00
|
|
|
String path = folder.path;
|
2014-09-10 19:20:09 +00:00
|
|
|
expect(currentContextPaths, isNot(contains(path)));
|
|
|
|
currentContextTimestamps[path] = now;
|
2014-08-07 18:04:21 +00:00
|
|
|
currentContextFilePaths[path] = <String, int>{};
|
2015-02-17 22:47:34 +00:00
|
|
|
currentContextSources[path] = new HashSet<Source>();
|
2015-07-24 13:42:54 +00:00
|
|
|
currentContextDispositions[path] = disposition;
|
2015-06-06 15:30:38 +00:00
|
|
|
currentContext = AnalysisEngine.instance.createAnalysisContext();
|
2015-08-18 18:32:15 +00:00
|
|
|
List<UriResolver> resolvers = [];
|
2015-07-24 13:42:54 +00:00
|
|
|
resolvers.addAll(disposition.createPackageUriResolvers(resourceProvider));
|
2015-08-18 18:32:15 +00:00
|
|
|
resolvers.add(new FileUriResolver());
|
2015-07-24 13:42:54 +00:00
|
|
|
currentContext.sourceFactory =
|
|
|
|
new SourceFactory(resolvers, disposition.packages);
|
2015-03-09 18:28:21 +00:00
|
|
|
return currentContext;
|
2014-08-07 18:04:21 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
@override
|
|
|
|
void applyChangesToContext(Folder contextFolder, ChangeSet changeSet) {
|
|
|
|
Map<String, int> filePaths = currentContextFilePaths[contextFolder.path];
|
2015-02-17 22:47:34 +00:00
|
|
|
Set<Source> sources = currentContextSources[contextFolder.path];
|
|
|
|
|
2014-08-07 18:04:21 +00:00
|
|
|
for (Source source in changeSet.addedSources) {
|
|
|
|
expect(filePaths, isNot(contains(source.fullName)));
|
|
|
|
filePaths[source.fullName] = now;
|
2015-02-17 22:47:34 +00:00
|
|
|
sources.add(source);
|
2014-08-07 18:04:21 +00:00
|
|
|
}
|
|
|
|
for (Source source in changeSet.removedSources) {
|
|
|
|
expect(filePaths, contains(source.fullName));
|
|
|
|
filePaths.remove(source.fullName);
|
2015-02-17 22:47:34 +00:00
|
|
|
sources.remove(source);
|
2014-08-07 18:04:21 +00:00
|
|
|
}
|
|
|
|
for (Source source in changeSet.changedSources) {
|
|
|
|
expect(filePaths, contains(source.fullName));
|
|
|
|
filePaths[source.fullName] = now;
|
|
|
|
}
|
2015-03-09 18:28:21 +00:00
|
|
|
|
|
|
|
currentContext.applyChanges(changeSet);
|
2014-08-07 18:04:21 +00:00
|
|
|
}
|
|
|
|
|
2014-08-08 15:55:06 +00:00
|
|
|
void assertContextFiles(String contextPath, List<String> expectedFiles) {
|
|
|
|
var actualFiles = currentContextFilePaths[contextPath].keys;
|
|
|
|
expect(actualFiles, unorderedEquals(expectedFiles));
|
|
|
|
}
|
|
|
|
|
|
|
|
void assertContextPaths(List<String> expected) {
|
|
|
|
expect(currentContextPaths, unorderedEquals(expected));
|
|
|
|
}
|
|
|
|
|
2014-08-07 18:04:21 +00:00
|
|
|
@override
|
Separate the API's used by ContextManager.
Previously, ContextManager had two API's: one used by analysis server
to tell the ContextManager what to do, and one used by the
ContextManager to make callbacks to analysis server in response to its
requests. The first API was implemented in the class
AbstractContextManager, which derived from ContextManager, and the
second API was implemented in ServerContextManager, which derived from
AbstractContextManager.
In addition to causing confusion, this made it impossible to provide
an alternate implementation of ContextManager as a plug-in, since the
plug in would have had to re-implement the second API, and that would
have required accessing private implementation details of the
ContextManager.
This CL separates the API's: the first API is specified in
ContextManager and implemented in ContextManagerImpl, and the second
API is specified in ContextManagerCallbacks and implemented in
ServerContextManagerCallbacks.
In the long run I hope to eliminate the ContextManagerCallbacks class
entirely, by having the ContextManager tell its client what to do
using return values rather than callbacks.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1243893002 .
2015-07-21 17:40:57 +00:00
|
|
|
void removeContext(Folder folder, List<String> flushedFiles) {
|
2014-08-07 18:04:21 +00:00
|
|
|
String path = folder.path;
|
2014-09-10 19:20:09 +00:00
|
|
|
expect(currentContextPaths, contains(path));
|
|
|
|
currentContextTimestamps.remove(path);
|
2014-08-07 18:04:21 +00:00
|
|
|
currentContextFilePaths.remove(path);
|
2015-02-17 22:47:34 +00:00
|
|
|
currentContextSources.remove(path);
|
2015-07-24 13:42:54 +00:00
|
|
|
currentContextDispositions.remove(path);
|
2014-08-07 18:04:21 +00:00
|
|
|
}
|
|
|
|
|
2015-05-21 21:34:04 +00:00
|
|
|
@override
|
|
|
|
bool shouldFileBeAnalyzed(File file) {
|
|
|
|
if (!(AnalysisEngine.isDartFileName(file.path) ||
|
|
|
|
AnalysisEngine.isHtmlFileName(file.path))) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
// Emacs creates dummy links to track the fact that a file is open for
|
|
|
|
// editing and has unsaved changes (e.g. having unsaved changes to
|
|
|
|
// 'foo.dart' causes a link '.#foo.dart' to be created, which points to the
|
|
|
|
// non-existent file 'username@hostname.pid'. To avoid these dummy links
|
|
|
|
// causing the analyzer to thrash, just ignore links to non-existent files.
|
|
|
|
return file.exists;
|
|
|
|
}
|
|
|
|
|
2014-08-07 18:04:21 +00:00
|
|
|
@override
|
2015-03-02 22:43:12 +00:00
|
|
|
void updateContextPackageUriResolver(
|
2015-07-24 13:42:54 +00:00
|
|
|
Folder contextFolder, FolderDisposition disposition) {
|
|
|
|
currentContextDispositions[contextFolder.path] = disposition;
|
2014-08-07 18:04:21 +00:00
|
|
|
}
|
|
|
|
}
|
2015-07-06 20:06:33 +00:00
|
|
|
|
2015-07-13 17:20:13 +00:00
|
|
|
/**
|
|
|
|
* A [Source] that knows it's [fullName].
|
|
|
|
*/
|
|
|
|
class TestSource implements Source {
|
|
|
|
TestSource();
|
|
|
|
|
|
|
|
@override
|
|
|
|
noSuchMethod(Invocation invocation) => super.noSuchMethod(invocation);
|
|
|
|
}
|
|
|
|
|
2015-07-06 20:06:33 +00:00
|
|
|
class TestUriResolver extends UriResolver {
|
|
|
|
Map<Uri, Source> uriMap;
|
|
|
|
|
|
|
|
TestUriResolver(this.uriMap);
|
|
|
|
|
|
|
|
@override
|
2015-07-21 22:53:56 +00:00
|
|
|
Source resolveAbsolute(Uri uri, [Uri actualUri]) {
|
2015-07-06 20:06:33 +00:00
|
|
|
return uriMap[uri];
|
|
|
|
}
|
|
|
|
}
|