tests/language/src/Library2NegativeTest.dart - Issue 8431016: fix some tests

Side by Side Diff: tests/language/src/Library2NegativeTest.dart

Issue 8431016: fix some tests (Closed) Base URL: https://dart.googlecode.com/svn/branches/bleeding_edge/dart

Patch Set: Created 9 years, 1 month ago

Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.

Jump to:

View unified diff | Download patch | Annotate | Revision Log

« no previous file with comments | « tests/language/src/ConstructorRedirect5NegativeTest.dart ('k') | tests/language/src/Library3NegativeTest.dart » ('j') | tests/language/src/Library3NegativeTest.dart » ('J')
Toggle Intra-line Diffs ('i') | Expand Comments ('e') | Collapse Comments ('c') | Hide Comments ('s')

OLD	NEW
1 // Copyright (c) 2011, the Dart project authors. Please see the AUTHORS file	1 // Copyright (c) 2011, the Dart project authors. Please see the AUTHORS file

2 // for details. All rights reserved. Use of this source code is governed by a	2 // for details. All rights reserved. Use of this source code is governed by a

3 // BSD-style license that can be found in the LICENSE file.	3 // BSD-style license that can be found in the LICENSE file.

4	4

5 // This test should fail to load because we are importing two libraries	5 // This test should fail to load because we are importing two libraries

6 // which define the same top level name.	6 // which define the same top level name.

7	7

8 #library("Library2NegativeTest.dart");	8 #library("Library2NegativeTest.dart");

9 #import("library3.dart"); // imports library2.dart which defines foo/foo1.	9 #import("library3.dart"); // imports library2.dart which defines foo/foo1.

10 #import("library4.dart"); // imports library2.dart and defines foo/foo1.	10 #import("library4.dart"); // imports library2.dart and defines foo/foo1.

	11 #import("library2.dart");
	jimhug 2011/10/31 23:36:31 This seems totally broken to me without this line. This seems totally broken to me without this line. Imports are not transitive so members that are imported by library3 or library4 should not be exposed to classes that import them. If anything, I think it could be valuable to keep the old version of this test around as a positive test since both dartc and the vm appear to be generating an error here. ngeoffray 2011/11/01 08:17:34 The problem is that the libraries are not imported Show quoted text On 2011/10/31 23:36:31, jimhug wrote: > This seems totally broken to me without this line. Imports are not transitive > so members that are imported by library3 or library4 should not be exposed to > classes that import them. If anything, I think it could be valuable to keep the > old version of this test around as a positive test since both dartc and the vm > appear to be generating an error here. The problem is that the libraries are not imported with a prefix. So if you do a full analysis of what is in the scope of that file, you'll end up with two definitions of 'foo'. kasperl 2011/11/01 11:11:29 To me it looks like importing library4 alone is en Show quoted text On 2011/10/31 23:36:31, jimhug wrote: > This seems totally broken to me without this line. Imports are not transitive > so members that are imported by library3 or library4 should not be exposed to > classes that import them. If anything, I think it could be valuable to keep the > old version of this test around as a positive test since both dartc and the vm > appear to be generating an error here. To me it looks like importing library4 alone is enough to give us the issue (library4 defines foo and imports foo from library2). Shouldn't this fail the same way if you remove the library3 importing? jimhug 2011/11/01 15:07:11 Here's my take: Importing just library4 and then Here's my take: Importing just library4 and then accessing foo from within library4 would be an error. However, just importing library4 and then accessing foo from this file should work correctly and return the foo defined in library4. Am I missing something? Related: The library3 import in this file is not needed and I just left it in in order to keep my changes minimal (hi, Nicolas <smile>) the change would be better if that was removed too. On 2011/11/01 11:11:29, kasperl wrote: Show quoted text > On 2011/10/31 23:36:31, jimhug wrote: > > This seems totally broken to me without this line. Imports are not transitive > > so members that are imported by library3 or library4 should not be exposed to > > classes that import them. If anything, I think it could be valuable to keep > the > > old version of this test around as a positive test since both dartc and the vm > > appear to be generating an error here. > > To me it looks like importing library4 alone is enough to give us the issue > (library4 defines foo and imports foo from library2). Shouldn't this fail the > same way if you remove the library3 importing? ngeoffray 2011/11/01 15:18:31 OK, I re-checked the source files. I think Kasper' Show quoted text On 2011/11/01 15:07:11, jimhug wrote: > Here's my take: > > Importing just library4 and then accessing foo from within library4 would be an > error. However, just importing library4 and then accessing foo from this file > should work correctly and return the foo defined in library4. Am I missing > something? Related: The library3 import in this file is not needed and I just > left it in in order to keep my changes minimal (hi, Nicolas <smile>) the change > would be better if that was removed too. > > On 2011/11/01 11:11:29, kasperl wrote: > > On 2011/10/31 23:36:31, jimhug wrote: > > > This seems totally broken to me without this line. Imports are not > transitive > > > so members that are imported by library3 or library4 should not be exposed > to > > > classes that import them. If anything, I think it could be valuable to keep > > the > > > old version of this test around as a positive test since both dartc and the > vm > > > appear to be generating an error here. > > > > To me it looks like importing library4 alone is enough to give us the issue > > (library4 defines foo and imports foo from library2). Shouldn't this fail the > > same way if you remove the library3 importing? > OK, I re-checked the source files. I think Kasper's right. library4 can not be compiled properly because of duplicate definition of 'foo' and 'foo1'. I don't know wrt the spec if we can delay the error reporting.
11	12

12 main() {	13 main() {

13 Expect.equals(0, foo1);	14 Expect.equals(0, foo1);

14 }	15 }

OLD	NEW