Re: [swift-dev] What's the best way to handle failing SourceKit tests?

2016-04-12 Thread Dmitri Gribenko via swift-dev 
+Argyrios

On Mon, Apr 11, 2016 at 7:55 PM, Michael Buckley via swift-dev
 wrote:
> Hi,
>
> I'm currently working on SR-1115, adding initializers to Int and Uint to
> convert from UnsafePointer, and after making my changes, the
> SourceKit/DocSupport/doc_swift_module.swift tests are failing. (Failures
> attached).
>
> Presumably this is because the new initializers affect the SourceKit
> mappings, but unfortunately, it looks like most of the changes are to key
> offsets, and while most of the offsets have increased by 115, not all of
> them have, and I'm not even sure increasing the offsets by 115 is the
> correct change. I could just make the test pass by increasing the offsets as
> shown in the test failure, I'm worried that this could end up creating an
> invalid test case, which in the worst case could hide SourceKit problems in
> the future.
>
> Since any changes to the standard library probably affect these tests, I was
> wondering what the best way to resolve these failures is. Thanks.
>
> ___
> swift-dev mailing list
> swift-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev
>



-- 
main(i,j){for(i=2;;i++){for(j=2;j*/
___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] swift (ABI) and Windows

2016-04-12 Thread Saleem Abdulrasool via swift-dev 
On Monday, April 11, 2016, Joe Groff  wrote:

>
> > On Apr 11, 2016, at 3:19 PM, Saleem Abdulrasool via swift-dev <
> swift-dev@swift.org > wrote:
> >
> > On Thu, Apr 7, 2016 at 2:12 PM, Saleem Abdulrasool <
> compn...@compnerd.org > wrote:
> > On Wed, Apr 6, 2016 at 10:21 AM, Saleem Abdulrasool <
> compn...@compnerd.org > wrote:
> > Hi,
> >
> > I was playing around with the idea of swift and Windows since there are
> some interesting differences between COFF/PE and (ELF and MachO).
> >
> > PE/COFF does not directly address symbols in external modules
> (DSOs/dylibs/DLLs).  Instead, there is an indirect addressing model (thunks
> in Windows parlance).  Fortunately, LLVM has a nice way to model this:
> GlobalValues have an associated "DLLStorageClass" which indicates whether
> something is "imported" (provided by an external module), "exported"
> (provided to external modules), or "default" (everything else).
> >
> > Adjusting the IRGen to correctly annotate this part of the semantics
> should get us part of the way to supporting swift on PE/COFF.
> >
> > The thing to consider with this is that the DLL storage class is
> dependent on how the module(s) are being built.  For example, something may
> change from the exported storage to default if being built into a static
> library rather than a shared object and is not meant to be re-exported.
> >
> > Part of this information really needs to be threaded from the build
> system so that we know whether a given SIL module is external or internal.
> >
> > To the DLL Storage semantics support, Ive taken a quick first stab at
> it.  Ive pushed the changes to
> https://github.com/compnerd/apple-swift/tree/dllstorage and created a
> Pull Request at https://github.com/apple/swift/pull/2080 .
> >
> > However, as I expected, this is going to cause problems for building
> some of the core libraries.  In particular, there are mismatches between
> what gets compiled and is desired.  The swiftStubs and swiftRuntime are
> statically compiled and then merged into swiftCore.  There is also the
> concern of the the support modules (e.g. Platform).  If there are stubs
> that are being used (e.g. via _silgen_name) then there are issues with
> calculating the correct DLL storage for the associated global values.
> >
> > Playing around with this, I was trying to special case the building of
> the standard library (as the runtime will be statically linked into it, the
> symbols that it is expecting to be externally available are actually
> private linkage.  Not hacking up the compiler like this causes issues since
> there are inverse dependencies (swiftCore gets dllimport interfaces from
> swiftRuntime, which has dependencies on swiftCore).  The crux of the
> problem is that we do not have a way to represent that in swift.
> >
> > The easiest answer that seems to come to mind is to actually introduce
> an attribute to indicate that an interface is part of a specific module and
> assume that everything else is locally defined.  This would also
> potentially allow us to handle things like @inline(always) @transparent
> interfaces which get imported to ensure that a static inline function is
> given local visibility rather than a DLL Import storage.
> >
> > Unfortunately, I believe that currently Im stuck as I do not have a good
> way to determine what type of dll storage class a symbol should be given
> (since currently, theres no way to determine if we will have a symbol
> available locally or not when actually linking).
> >
> > It seems to me, at least initially, that we need a way to treat
> SwiftModule as a container (a la llvm::Module) and indicate which of the
> TopLevelDecls are meant to be a single "module" (DSO, DLL, whatever you
> want to call it) so that we can properly track the DLL storage associated
> with them.  Am I confusing something there?
> >
> > Is there a preference on a means to handle this?
>
> The runtime is linked as part of the standard library, and its ABI
> interface should be exported from libswiftCore.dylib/so/dll like the
> standard library's. We should already mark up the ABI entry points with the
> SWIFT_RUNTIME_EXPORT and SWIFT_RUNTIME_STDLIB_INTERFACE macros. Is it not
> sufficient to expand these macros to __dllexport?


The definitions can be marked as __declspec(dllexport) but the compiler
generated references need to be dllimport for the wrapped runtime functions
(easy for the most part -- see my changes).  There's also the concern of
stubs for the aliases (via silgen_name).  Those are defined externally with
no indication that they are locally available and thus should have default
rather than dllimport storage.  Similar things for standard library
metadata (type, witness tables, etc).

-Joe



-- 
Saleem Abdulrasool
compnerd (at) compnerd (dot) org
___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] What's the best way to handle failing SourceKit tests?

2016-04-12 Thread Argyrios Kyrtzidis via swift-dev 
Confirm that the source text printed out at the beginning is as you expect. It 
is highly unlikely your changes caused something wrong with the offsets, so if 
the source text is fine it should be good to update the expected output.
If the offsets changed without the source text changing, then we have an issue 
with the offsets.

> On Apr 11, 2016, at 7:55 PM, Michael Buckley via swift-dev 
>  wrote:
> 
> Hi,
> 
> I'm currently working on SR-1115, adding initializers to Int and Uint to 
> convert from UnsafePointer, and after making my changes, the 
> SourceKit/DocSupport/doc_swift_module.swift tests are failing. (Failures 
> attached).
> 
> Presumably this is because the new initializers affect the SourceKit 
> mappings, but unfortunately, it looks like most of the changes are to key 
> offsets, and while most of the offsets have increased by 115, not all of them 
> have, and I'm not even sure increasing the offsets by 115 is the correct 
> change. I could just make the test pass by increasing the offsets as shown in 
> the test failure, I'm worried that this could end up creating an invalid test 
> case, which in the worst case could hide SourceKit problems in the future.
> 
> Since any changes to the standard library probably affect these tests, I was 
> wondering what the best way to resolve these failures is. Thanks.
> ___
> swift-dev mailing list
> swift-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev

___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] What's the best way to handle failing SourceKit tests?

2016-04-12 Thread Michael Buckley via swift-dev 
Thank you very much. The source printed out at the beginning is indeed what
I expect, so I will update the offsets. Thanks again.

On Tue, Apr 12, 2016 at 10:40 AM, Argyrios Kyrtzidis 
wrote:

> Confirm that the source text printed out at the beginning is as you
> expect. It is highly unlikely your changes caused something wrong with the
> offsets, so if the source text is fine it should be good to update the
> expected output.
> If the offsets changed without the source text changing, then we have an
> issue with the offsets.
>
> > On Apr 11, 2016, at 7:55 PM, Michael Buckley via swift-dev <
> swift-dev@swift.org> wrote:
> >
> > Hi,
> >
> > I'm currently working on SR-1115, adding initializers to Int and Uint to
> convert from UnsafePointer, and after making my changes, the
> SourceKit/DocSupport/doc_swift_module.swift tests are failing. (Failures
> attached).
> >
> > Presumably this is because the new initializers affect the SourceKit
> mappings, but unfortunately, it looks like most of the changes are to key
> offsets, and while most of the offsets have increased by 115, not all of
> them have, and I'm not even sure increasing the offsets by 115 is the
> correct change. I could just make the test pass by increasing the offsets
> as shown in the test failure, I'm worried that this could end up creating
> an invalid test case, which in the worst case could hide SourceKit problems
> in the future.
> >
> > Since any changes to the standard library probably affect these tests, I
> was wondering what the best way to resolve these failures is. Thanks.
> >  Failures.txt>___
> > swift-dev mailing list
> > swift-dev@swift.org
> > https://lists.swift.org/mailman/listinfo/swift-dev
>
>
___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] [Swift CI] Failure: Swift Package - OS X (master)

2016-04-12 Thread Mishal Shah via swift-dev 
Hi Krish, 

Looks like this bot was fixed in build #1255 
https://ci.swift.org/view/Packages/job/oss-swift-package-osx/1255/

Thanks, 
Mishal Shah
> On Apr 12, 2016, at 2:49 PM, Krish Munot  wrote:
> 
> Hey Mishal,
> 
> What happened? Does this need any immediate attention? I would love to get a 
> solution for this.
> 
> Thanks,
> Krish
> 
> On Tue, Apr 12, 2016 at 2:14 AM, Mishal Shah  > wrote:
> Bot:  https://ci.swift.org/view/Packages/job/oss-swift-package-osx/ 
> 
> 
> Failing Tests (1): (Link 
> )
> Swift :: 
> compiler_crashers/28279-swift-archetypebuilder-potentialarchetype-getnestedtype.swift
> 
> Commits: 
> https://ci.swift.org/view/Packages/job/oss-swift-package-osx/changes 
> 
> #1252 (Apr 11, 2016 2:19:00 AM)
> 
> Add rudimentary nested closure param/return/throws support for Doxygen 
> (commit: a6b410bcb14f469c38b5689f1431ab7d0119e839 
> )
>  — dfarler  / detail 
> 
> Add Objective-C header test for nested closure parameter doc comments 
> (commit: 0f71dfdfde685b094c56f4a179fe332fc8354638 
> )
>  — dfarler  / detail 
> 
> [test] Replaced some if true {} statements with do {} (#2117) (commit: 
> efd04e92e0014739fac86e6273a7112d5909c1bb 
> )
>  — kremenek  / detail 
> 
> #1251 (Apr 10, 2016 10:28:10 PM)
> 
> Revert "Revert "Enable cmark smart punctuation in doc comments"" (commit: 
> fbc220a036905c742c7c141e32bc15743e030f66 
> )
>  — dfarler  / detail 
> 
> Refactor: extractCommentParts can theoretically work for any markup AST 
> (commit: 5eb479a6f29e6f35d05dcde8ffbd310b77cd473a 
> )
>  — dfarler  / detail 
> 
> Rename llvm::markup namespace to swift::markup (commit: 
> a9297eed9f47ed77ca084a217ad4db981503bda9 
> )
>  — dfarler  / detail 
> 
> UnsafeGuaranteedPeephole: Also skip sideeffect free instructions (commit: 
> 75100a9598faf51234393d2e1c219348af80b1fc 
> )
>  — aschwaighofer  / detail 
> 
> [gardening] De-indent comment in `RedundantOverflowCheckRemovalPass`. 
> (commit: c809ca1469c7293ad299b6ac1ec33d007934e880 
> )
>  — jdhealy  / detail 
> 
> hyperlinking relevant directories and sites (commit: 
> d2e98f46338e655d715c548b676700e0a071c695 
> )
>  — krishmunot  / detail 
> 
> Nesting parameter/returns/throws doc comments for closure parameters (commit: 
> c20f3db09e41ca0dcaae885a6c10164a8074612e 
> )
>  — dfarler  / detail 
> 
> [Sema] Improved error message for static functions on existential (commit: 
> de189679923f8787eb10414cac732481689c1e8d 
> )
>  — kremenek  / detail 
> 
> [Toolchains] Document virtual methods (#2134) (commit: 
> a04

[swift-dev] New Swift snapshots available!

2016-04-12 Thread Mishal Shah via swift-dev 
New Swift snapshots available! 

Download new packages from https://swift.org/download/ 



Swift 2.2.x: (swift-2.2-branch)
Following repository are tagged with swift-2.2.1-SNAPSHOT-2016-04-12-a

https://github.com/apple/swift  

https://github.com/apple/swift-clang  

https://github.com/apple/swift-lldb    

https://github.com/apple/swift-llvm    

https://github.com/apple/swift-cmark 
https://github.com/apple/swift-integration-tests 
  


Swift Development: (master)
Following repository are tagged with swift-DEVELOPMENT-SNAPSHOT-2016-04-12-a

https://github.com/apple/swift  

https://github.com/apple/swift-clang  

https://github.com/apple/swift-llbuild  

https://github.com/apple/swift-lldb    

https://github.com/apple/swift-llvm    

https://github.com/apple/swift-corelibs-foundation 
 
https://github.com/apple/swift-corelibs-xctest 
 
https://github.com/apple/swift-package-manager 

https://github.com/apple/swift-cmark 
https://github.com/apple/swift-integration-tests 

https://github.com/apple/swift-compiler-rt

Thanks, 
Mishal Shah___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev