Dart_Snapshot conflicting uses #3
Comments
|
This comment was originally written by [email protected] Also getting this. I have GCC 4.5.2 installed. |
|
This comment was originally written by [email protected] FYI, successful build with gcc 4.4.3 |
|
This comment was originally written by [email protected] I'm also using GCC 4.5.2 |
|
This comment was originally written by [email protected] Me too getting same GCC 4.5.2 gcc -v gives following error Using built-in specs. |
|
This comment was originally written by [email protected] Issue #8 has been merged into this issue. |
|
This comment was originally written by [email protected] Issue #9 has been merged into this issue. |
|
This comment was originally written by [email protected] And again, the other errors from issue #9 (using ghc 4.6.1) third_party/v8/src/ia32/full-codegen-ia32.cc: In member function ‘virtual void v8::internal::FullCodeGenerator::VisitCompareOperation(v8::internal::CompareOperation*)’: third_party/v8/src/ia32/full-codegen-ia32.cc: In member function ‘virtual void v8::internal::FullCodeGenerator::VisitCompareOperation(v8::internal::CompareOperation*)’: |
|
This comment was originally written by [email protected] Workaround: Remove -Werror from dart/tools/gyp/configurations_make.gypi. |
|
This comment was originally written by [email protected] Using comment 8 workaround was able to build dart on 11.04 x32 gcc 4.5.2 |
|
This comment was originally written by [email protected] With r321, it compiles fine with GCC 4.6.1. |
|
Issue #46 has been merged into this issue. |
|
This comment was originally written by [email protected] latest revision r322 compiles fine with Ubuntu 11.04, GCC 4.5.2 |
|
This comment was originally written by [email protected] Set owner to [email protected]. |
|
This comment was originally written by [email protected] Passing the buck to the VM team. Set owner to @iposva-google. |
|
This comment was originally written by [email protected] Issue #52 has been merged into this issue. |
|
This comment was originally written by [email protected] r329 also compiles fine with Ubuntu 11.04, gcc 4.5.2 |
|
This comment was originally written by [email protected] in r330, the "conflicts with previous declaration"-type errors are gone, however the "variable ‘X’ set but not used"-errors still occur with gcc 4.6.1 (prerelease on arch linux) |
|
Fixed in https://code.google.com/p/dart/source/detail?r=321 which should be merged to trunk shortly. |
|
This comment was originally written by [email protected] Could you revoke the classification of issue #9 as a duplicate, then? Issue #9 has been merged into this issue here, and it has not been fixed. |
During my work on dart-lang/language#3648, I ran into some trybot failures with an exception that looked like this: RangeError (index): Invalid value: Valid value range is empty: -1 #0 List.[] (dart:core-patch/growable_array.dart:264:36) #1 List.removeLast (dart:core-patch/growable_array.dart:336:20) #2 InferenceContext.popFunctionBodyContext (package:analyzer/src/generated/resolver.dart:124:33) #3 ResolverVisitor.visitBlockFunctionBody (package:analyzer/src/generated/resolver.dart:1890:38) Some quick reading of the code revealed that `popFunctionBodyContext` always removed a single entry from a list, and `pushFunctionBodyContext` always added a single entry to it. The two calls were always paired up using a straightforward try/finally pattern that seemed like it should guarantee proper nesting, making this exception impossible: try { inferenceContext.pushFunctionBodyContext(...); ... } finally { ... inferenceContext.popFunctionBodyContext(node); } After a lot of headscratching and experimenting, I eventually figured out what was happening: an exception was being thrown during `pushFunctionBodyContext`, _before_ it had a chance to add an entry to the list. But since the exception happened inside the `try` block, the call to `popFunctionBodyContext` would happen anyway. As a result, the pop would fail, causing its own exception, and the exception that was the original source of the problem would be lost. This seemed like a code smell to me: where possible, the clean-up logic in `finally` clauses should be simple enough that it can always succeed, without causing an exception, even if a previous exception has put data structures in an unexpected state. And I had gained enough familiarity with the code over the course of my debugging to see that what we were doing in those `finally` clauses was more complex than necessary: - In the ResolverVisitor, we were pushing and popping a stack of `BodyInferenceContext` objects using the try/finally pattern described above. But we were only ever accessing the top entry on the stack, which meant that the same state could be maintained with a single BodyInferenceContext pointer, and some logic that can't possibly lead to an exception in the `finally` clause: var oldBodyContext = _bodyContext; try { _bodyContext = ...; ... } finally { _bodyContext = oldBodyContext; } - In the ResolverVisitor and the ErrorVerifier, we were also pushing and popping a stack of booleans tracking whether the currently enclosing function (or initializer) has access to `this`. In the ResolverVisitor, this information wasn't being used at all, so it could be safely removed. In the ErrorVerifier, it was being used, but it was possible to simplify it in a similar way, so that it was tracked with a single boolean (`_hasAccessToThis`), rather than a stack. Simplifying this logic brings several advantages: - As noted above, since it's now impossible for an exception to occur in the `finally` clause, exceptions occurring in the `try` clause won't get lost, making debugging easier. - The code should be more performant, since it no longer requires auxiliary heap-allocated stacks. - The code is (IMHO) easier to understand, since the try/catch pattern for maintaining the new `_bodyContext` and `_hasAccessToThis` fields just involves saving a field in a local variable (and restoring it later), rather than calling out to separate classes. Change-Id: I61ae80fb28a69760ea0b2856a6954b4a68cfcbe1 Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/358200 Reviewed-by: Konstantin Shcheglov <[email protected]> Reviewed-by: Brian Wilkerson <[email protected]> Commit-Queue: Paul Berry <[email protected]>
See: b/374689139. https://dart-review.googlesource.com/c/sdk/+/390941 is blocking an SDK roll. Root cause: ``` Action threw an exception: type 'ConstructorMember' is not a subtype of type 'ConstructorFragment' in type cast #0 InterfaceTypeImpl.constructors2.<anonymous closure> (package:analyzer/src/dart/element/type.dart:569) #1 MappedListIterable.elementAt (dart:_internal/iterable.dart:435) #2 ListIterator.moveNext (dart:_internal/iterable.dart:364) #3 new _GrowableList._ofEfficientLengthIterable (dart:core-patch/growable_array.dart:189) #4 new _GrowableList.of (dart:core-patch/growable_array.dart:150) #5 new List.of (dart:core-patch/array_patch.dart:39) #6 ListIterable.toList (dart:_internal/iterable.dart:224) #7 InterfaceTypeImpl.constructors2 (package:analyzer/src/dart/element/type.dart:570) #8 _Visitor._hasConstConstructorInvocation (package:linter/src/rules/prefer_const_constructors_in_immutables.dart:110) #9 _Visitor.visitConstructorDeclaration (package:linter/src/rules/prefer_const_constructors_in_immutables.dart:58) ``` To verify the fix locally: ``` solo_test_X() async { await assertNoErrorsInCode(r''' class A<T> {} '''); var A = findElement.class_('A').instantiate( typeArguments: [intType], nullabilitySuffix: NullabilitySuffix.none, ); A.constructors2; } ``` Bug: b/374689139 Change-Id: I70034d938d840dc0c3939db27e7116164e4617e9 Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/391483 Reviewed-by: Konstantin Shcheglov <[email protected]> Commit-Queue: Phil Quitslund <[email protected]>
This issue was originally filed by [email protected]
Trying to build Dart after clean checkout from SVN gives me :
runtime/vm/dart_api_impl.cc: In function ‘void* dart::Dart_CreateIsolate(void*, void*)’:
runtime/vm/dart_api_impl.cc:38:71: error: declaration of ‘void* dart::Dart_CreateIsolate(void*, void*)’ with C language linkage
runtime/include/dart_api.h:185:26: error: conflicts with previous declaration ‘void* Dart_CreateIsolate(const Dart_Snapshot*, void*)’
I ended up changing the dart_api_impl.cc declaration to use const Dart_Snapshot* and did a cast to (void*) in order to call Dart::CreateIsolate((void*)snapshot, data);
The text was updated successfully, but these errors were encountered: