1. 15 Oct, 2019 6 commits
  2. 14 Oct, 2019 15 commits
  3. 13 Oct, 2019 2 commits
  4. 12 Oct, 2019 5 commits
    • Giovanni Bajo's avatar
      runtime: adjust expected error threshold in TestSelectFairness · e49ecaaa
      Giovanni Bajo authored
      Make it a bit more relaxed on the expected fairness, as fastrand()
      isn't a truly perfect random number generator.
      
      Fixes #34808
      
      Change-Id: Ib55b2bbe3c1bf63fb4f446fd1291eb1236efc33b
      Reviewed-on: https://go-review.googlesource.com/c/go/+/200857
      Run-TryBot: Giovanni Bajo <rasky@develer.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarKeith Randall <khr@golang.org>
      e49ecaaa
    • Meng Zhuo's avatar
      net: use case-insensitive host string comparison in TestLookup* · 592d304b
      Meng Zhuo authored
      Some nameservers alter the case of records as they return, e.g
      .google.COM or .Google.com.
      However according to RFC4343, DNS name should be treated in case insensitive fashion.
      This CL will fix case sensitive testcases.
      
      Fixes #34781
      
      Change-Id: I5f9f6a41ddc1c61993e8d1f934ef0febddc3adc1
      Reviewed-on: https://go-review.googlesource.com/c/go/+/200277Reviewed-by: default avatarAndrei Tudor Călin <mail@acln.ro>
      Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      592d304b
    • zdjones's avatar
      cmd/compile: make poset use sufficient conditions for OrderedOrEqual · 3c56eb40
      zdjones authored
      When assessing whether A <= B, the poset's OrderedOrEqual has a passing
      condition which permits A <= B, but is not sufficient to infer that A <= B.
      This CL removes that incorrect passing condition.
      
      Having identified that A and B are in the poset, the method will report that
      A <= B if any of these three conditions are true:
       (1) A and B are the same node in the poset.
       	- This means we know that A == B.
       (2) There is a directed path, strict or not, from A -> B
       	- This means we know that, at least, A <= B, but A < B is possible.
       (3) There is a directed path from B -> A, AND that path has no strict edges.
       	- This means we know that B <= A, but do not know that B < A.
      
      In condition (3), we do not have enough information to say that A <= B, rather
      we only know that B == A (which satisfies A <= B) is possible. The way I
      understand it, a strict edge shows a known, strictly-ordered relation (<) but
      the lack of a strict edge does not show the lack of a strictly-ordered relation.
      
      The difference is highlighted by the example in #34802, where a bounds check is
      incorrectly removed by prove, such that negative indexes into a slice
      succeed:
      
      	n := make([]int, 1)
      	for i := -1; i <= 0; i++ {
      	    fmt.Printf("i is %d\n", i)
      	    n[i] = 1  // No Bounds check, program runs, assignment to n[-1] succeeds!!
      	}
      
      When prove is checking the negative/failed branch from the bounds check at n[i],
      in the signed domain we learn (0 > i || i >= len(n)). Because prove can't learn
      the OR condition, we check whether we know that i is non-negative so we can
      learn something, namely that i >= len(n). Prove uses the poset to check whether
      we know that i is non-negative.  At this point the poset holds the following
      relations as a directed graph:
      
      	-1 <= i <= 0
      	-1 < 0
      
      In poset.OrderedOrEqual, we are testing for 0 <= i. In this case, condition (3)
      above is true because there is a non-strict path from i -> 0, and that path
      does NOT have any strict edges. Because this condition is true, the poset
      reports to prove that i is known to be >= 0. Knowing, incorrectly, that i >= 0,
      prove learns from the failed bounds check that i >= len(n) in the signed domain.
      
      When the slice, n, was created, prove learned that len(n) == 1. Because i is
      also the induction variable for the loop, upon entering the loop, prove previously
      learned that i is in [-1,0]. So when prove attempts to learn from the failed
      bounds check, it finds the new fact, i > len(n), unsatisfiable given that it
      previously learned that i <= 0 and len(n) = 1.
      
      Fixes #34802
      
      Change-Id: I235f4224bef97700c3aa5c01edcc595eb9f13afc
      Reviewed-on: https://go-review.googlesource.com/c/go/+/200759
      Run-TryBot: Zach Jones <zachj1@gmail.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarGiovanni Bajo <rasky@develer.com>
      Reviewed-by: default avatarKeith Randall <khr@golang.org>
      3c56eb40
    • Cuong Manh Le's avatar
      cmd/compile: move OAS2 to its own case in order · e79c2382
      Cuong Manh Le authored
      Change-Id: Id0f4955588ae8027a24465b456c90d0543d60db2
      Reviewed-on: https://go-review.googlesource.com/c/go/+/200581
      Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarMatthew Dempsky <mdempsky@google.com>
      e79c2382
    • Cuong Manh Le's avatar
      cmd/compile: simplify OAS2XXX nodes handle in order · ba6aeb6c
      Cuong Manh Le authored
      Passes toolstash-check.
      
      Updates #23017
      
      Change-Id: I0ae82e28a6e9e732ba2a6aa98f9b35551efcea10
      Reviewed-on: https://go-review.googlesource.com/c/go/+/200580
      Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarMatthew Dempsky <mdempsky@google.com>
      ba6aeb6c
  5. 11 Oct, 2019 12 commits