profile
viewpoint
Caleb Spare cespare Liftoff Palo Alto, CA I make Go servers fast at @liftoffio.

BurntSushi/toml 3210

TOML parser for Golang with reflection.

cespare/deplist 62

List the external dependencies of a Go package.

cespare/discoball 17

A simple stream filter to highlight patterns

cespare/cbor 13

A Go implementation of CBOR (compact binary object representation).

bkad/prat 12

group chat with markdown served over websockets

cespare/carlisle 9

Window control shortcuts for EWMH-compliant X window managers

cespare/dotfiles 8

Personal dotfiles, vim config, little scripts, etc.

cespare/boggle-solver 6

A simple boggle solver written for fun.

cespare/flake 6

Find test flakes

issue commentgolang/go

proposal: net/http: add constant for content type

@ghostsquad it's not different in that regard. Whether the RHS is using a constant or a string literal, that code is a little broken.

tomocy

comment created time in 14 hours

issue commentgolang/go

cmd/vet: improve error message for string(int) warning

The value of improving this error is to help the people who will be momentarily confused when this new vet check starts flagging their code, which is going to happen as soon as Go 1.15 lands. If we can't change the error until 1.16, we might as well not bother; by that point, people will have fixed their code. Fixing this in 1.16 only helps the tiny number of people who skip over the 1.15 release entirely.

josharian

comment created time in 4 days

issue commentgolang/go

proposal: sync: Add UnlockThenRLock() to RWMutex

(And, to be honest, most of the uses of RWLock that I've seen would be better-served by some other synchronization pattern anyway...)

I endorse this. I think we should avoid adding features to rwmutexes that make them more tempting to use than they already are.

I like @nelhage's blog post as a reference for the problems with read-write locks.

pjebs

comment created time in 10 days

issue commentgolang/go

cmd/vet: improve error message for string(int) warning

FWIW I'd be fine with @alandonovan's suggestion in https://github.com/golang/go/issues/32479#issuecomment-628821401.

The key problem with the error message is if you interpret it from the viewpoint of an experienced Go user who is very aware of what string(int) does and has used it intentionally a few times, the response to being told "conversion from int to string yields a string of one rune" is probably "yes...and?" Alan's message which mentions "not a string of digits" makes it clear what the unintentional mistake with this kind of code would be.

josharian

comment created time in 12 days

issue commentgolang/go

cmd/vet: warn about string(int) type conversions

Can we improve the vet error message? I'm seeing this on tip:

x/x.go:9:14: conversion from int to string yields a string of one rune

This message states a fact without indicating a problem. If I weren't aware of this upcoming language change, I'd wonder why vet is spouting non sequiturs.

ianlancetaylor

comment created time in 17 days

issue commentgolang/go

proposal: time: Duration String() should omit zero units

At work we have a time.Duration printing function that trims the useless 0s and 0m suffixes. This is almost always a nicer way to print durations that were provided by humans (for instance, as a flag.Duration).

If we can't change the behavior of String, perhaps we could add a new method. (Display, ShortString, Str...? Nothing great is coming to mind.)

XSAM

comment created time in 17 days

Pull request review commentcespare/reflex

Use doublestar for glob matching

 type globMatcher struct { }  func (m *globMatcher) Match(name string) bool {-	matches, err := filepath.Match(m.glob, name)+	matches, err := doublestar.PathMatch(m.glob, name) 	if err != nil { 		return false 	} 	return matches != m.inverse } -func (m *globMatcher) ExcludePrefix(prefix string) bool { return false }+func (m *globMatcher) ExcludePrefix(prefix string) bool {+	if !m.inverse || len(m.glob) == 0 {+		return false+	}++	matches, err := doublestar.PathMatch(m.glob, prefix)+	switch {+	case err != nil:+		return false+	case matches:+		return true

The documentation for the ExcludePrefix method says:

// ExcludePrefix returns whether all paths with this prefix cannot match.
// It is allowed to return false negatives but not false positives.

That is not what this function implements. For example, if the pattern is **/, that matches the prefix a/ but does not match the path a/b.txt. So this would incorrectly exclude a/b.txt from the watch.

It's not immediately obvious to me how to fix this problem. I designed the ExcludePrefix mechanism mostly with regexp matching in mind.

shaxbee

comment created time in a month

push eventcespare/vim-config

Caleb Spare

commit sha 41ceeed11027fed0952409c6d6f1c476be195cc6

Update govim

view details

Caleb Spare

commit sha 9d6e0f824c73f30dbb821302bf19e1f52ff75b32

Don't default clojure width to 110

view details

push time in a month

issue closedcespare/reflex

`reflex --regex REGEX` does not catch argument

reflex --regex REGEX does not catch the argument where reflex -r REGEX does.

It fails with: flag needs an argument: --regex

closed time in a month

aslafy-z

issue commentcespare/reflex

`reflex --regex REGEX` does not catch argument

You have to write --regex=REGEX in the long form.

aslafy-z

comment created time in a month

push eventcespare/vim-config

Caleb Spare

commit sha 21fbe3628c45cb3b9755dd24f17acb73dba93201

Make split divisions look nicer

view details

push time in a month

issue commentgovim/govim

cmd/govim: become git-aware

In the meantime, being able to restart gopls via govim (#77) would be a massive help for these situations.

myitcv

comment created time in a month

push eventcespare/govim

Paul Jolly

commit sha 7280cf3fb310d1539284b29c8a724300d011166a

cmd/govim: handle buffer name changing in BufWinEnter (#798) A buffer name can change as a result of BufReadCmd. Some plugins use BufReadCmd to handle special reads of files. For example, github.com/plan9-for-vimspaceplan9-for-vimspace adds an address handler to BufReadCmd to handle an attempt to open /path/to/file.go:5:6, i.e. at a specific address (line:col). Most such handlers then fire a BufRead and BufWinEnter to complete the buffer life-cycle events, at which point we can correct the name of the buffer. There is currently no test for this, but it has been verified locally.

view details

Paul Jolly

commit sha bfc288d9c85a89f74c03cec5ef78d9cfb8818777

cmd/govim: workaround BufWinEnter without BufNew bug (#802) Because of https://github.com/vim/vim/issues/5694 we can find ourselves in a situation where we get a BufDelete or BufWinEnter for a buffer we know nothing about. Hence we need to ignore the event or force create that buffer as a workaround respectively.

view details

Paul Jolly

commit sha c7ecca29e78fce8392afa11b09c7ef19221f889e

ci: upgrade to go1.14, go1.13.8 and Vim v8.2.318 (#803) Now that go1.14 has been released, we can also drop go1.12

view details

Pontus Leitzler

commit sha 6b6b570a8a54a1e824a06db66f16a97c977cafc4

deps: upgrade x/tools and gopls to 5c7c66ce (#804) * gopls/doc: update godoc.org to pkg.go.dev 5c7c66ce * gopls/doc: add documentation for running gopls as a daemon 706bc42d * internal/fastwalk: fix checkptr failure on Darwin b3f10971 * internal/lsp/regtest: remove calls to t.Parallel() afe1c6fc * internal/lsp: mitigate possiibility of a slow code action 204d844a * internal/telemetry: removing the concept of exporter lists 2e887e3d * internal/lsp: remove unknown dependency from highlight tests eb7c5624 * internal/lsp/source: fix typo: identifer → identifier 26f6a1b6 * internal/lsp: replace mistaken "break" with "continue" 02067618 * internal/lsp: support textDocument/hover for .mod extension abb57c68 * internal/lsp: support textDocument/documentLink for .mod extension 48cfad2f * internal/lsp: invalidate package IDs along with metadata 807dcd88 * internal/lsp/source: limit WorkspaceSymbols results c099ead9 * internal/gocommand: kill gracefully 7c03e334 * all: consolidate invokeGo implementations c5cec671 * go/ssa/interp: remove unused import ee3f1146 * go/ssa: disable recover2 testcase 12e620e8 * internal/lsp/regtest: clean-up and more error handling fefc8d18 * gopls: update staticcheck to 2020.1.3 042d10a1 * internal/imports: filepath.Clean module Dirs 6bd7a380 * internal/lsp/lsprpc: wait for the handshake before running clientConn 45849e82 * internal/lsp: add a test for internal imports handling df82bb96 * internal/telemetry: add a benchmark with a null writer for comparison a0ec867d * internal/lsp/lsprpc: add a 1m timeout to auto-started gopls daf22849 * internal/lsp/lsprpc: clean up client session on disconnection 63caf62c * gopls/doc: Clear out fixed issues a6bebb63 * internal/jsonrpc2: add an idle timeout for stream serving 9ffc0ab4 * internal/lsp/lsprpc: automatically resolve and start the remote gopls a208025c * internal/lsp/lsprpc: add a handshake between forwarder and remote 20f46356 * internal/lsp/debug: move all debug state onto the Instance e02f5847 * internal/lsp/source: untangle completion type comparison 023911ca * Revert "Revert "go/analysis: add pass to check for impossible interface-to-interface type assertions"" e1da425f

view details

Pontus Leitzler

commit sha a3741ae96aa164e1e2bad5b920d724b49a5263cd

deps: upgrade x/tools and gopls to 066e0c02 (#805) * internal/lsp/lsprpc: use localhost for remote gopls debug interface 066e0c02 * internal/telemetry: remove Flush method from exporter 71482053 * go/packages: drop imports of reflect in tests of import graph a628ca32

view details

Paul Jolly

commit sha 8926deca76dc4aac524e10588d8a1427dfef08e7

all: back-out changes to track all buffers (#809) This commit was formed via the following sequence of commands: git diff -R b989e956 | git apply git show ec0360d5 | git apply git show 9f146506 | git apply git show c7ecca29 | git apply git show 6b6b570a | git apply git show a3741ae9 | git apply Any manual tweaks required to re-add small changes we need from 8826ef5f and friends will be added in later subsequent commits. The more important diff to look at here is: https://github.com/govim/govim/compare/b989e956...backout_all_buffer_tracking i.e. that with respect to b989e956 (the first commit prior to the "track all buffers" changes) the only diffs are changes that are _not_ related to "track all buffers"

view details

Paul Jolly

commit sha 2d6e2fb03301c6c5f512f18b17aa0a5b00a9d575

ci: disable flakey macOS builds until we have time to investigate #781 (#815) Right now the macOS builds typically fail because tests reach the 30 minute timeout. We haven't had the time or inclination to investigate and hence the often red builds are just a distraction that might actually hide genuine failures.

view details

Paul Jolly

commit sha 9f0875830768d13309b598f7c57ab81e9b75c3eb

cmd/govim: handle nil response to Hover (#816) In the current gopls implementation, if there is nothing under the cursor when we call Hover we simply get a zero value protocol.Hover returned (albeit via a pointer variable). As of de023d59a5d1 gopls now returns a zero value of type *protocol.Hover. Hence where we previously assumed we would not get a nil value we now do. Fix that.

view details

Pontus Leitzler

commit sha 49f1a82c8b680b93ad5e5ae2e80f99787127abce

deps: update x/tools and gopls to e4e22f76 (#814) * internal/lsp: support when hierarchicalDocumentSymbolSupport is false e4e22f76 * internal/telemetry: refactor the benchmark framework ca9608b5 * internal/lsp/debug: guard rpc stats with a Mutex 8287d625 * internal/lsp/cmd: improve flexibility of suggested fixes a0897bac * internal/lsp: support textDocument/formatting for .mod extension 136c3617 * internal/lsp/protocol: unmarshal to pointers when dispatching requests de023d59 * internal/lsp/lsprpc: use Setsid on POSIX GOOSes, to avoid SIGTERMs d1d1f200 * internal/lsp/cache: include session IDs in some cache keys bc073721 * internal/lsp/cache: fix NPE in fileWasSaved 6a641547 * internal/tool: avoid editorialization d7d44486 * internal/lsp: use standardised events for tagging 32f14692 * internal/lsp/source: use logical filenames for workspace symbols 95d2e580 * internal/lsp/cache: attach ModTidyHandle to snapshot instance d6a4d556 * internal/telemetry: change tracing to be event based c4206d45 * internal/telemetry: add simple tracing benchmarks c5a14147 * internal/telemetry: move the benchmarks to the main package 3e346efd * internal/telemetry: moving towards a unified event based exporter 046aa1cd * internal/telemetry: remove the concept of a Tagger a1c56757 * internal/telemetry: use atomics to get the exporter ae19ec71 * internal/lsp: move the debug.Instance onto the Context 4183ba16 * internal/imports: don't set a logger unless the user has provided it 2b0b585e * all: upgrade outdated dependencies 658b03bc * internal/lsp: fix active param in signature help 55b754b4 * internal/lsp: fix concurrent map read/write for missingmodules 115860e9 * go/analysis/passes/errorsas: clarify message 4fc520f0 * internal: rationalize debug logging 5bcca83a * internal/lsp/regtest: add a test for diagnostics on first file 9b52d559 * internal/lsp: add an upgrade all dependencies codelens c4f5635f * internal/lsp/source: fix completion crash with untyped assignee 8d770319 * internal/lsp/source: support inverse "implementations" ae0473a2 * internal/lsp/regtest: implement formatting and organizeImports 49e4010b * internal/lsp/regtest: consolidate Env wrappers 9aa23abf * go/analysis/passes/nilness: detecting panic with provably nil values b1e4e041 * internal/lsp/debug: add nil checks in debug page 7ae42e3a

view details

Paul Jolly

commit sha 097679ef00310852065b6ab5def5ba058b84e1d0

cmd/govim: fix handling of changed diagnostics from gopls (#811) In 8826ef5f (since backed out) we uncovered a bug in our handling of changed diagnostics from gopls. Currently we keep track of whether quickfix, sign and highlights have changed since we last tried to update any of the aforementioned categories. However, this is imprecise: we should instead keep track of the diagnostics that were last used to update Vim. Therefore we now track the diagnostics used to, for example, update diagnostics via govim.lastDiagnosticsQuickfix, of type *[]types.Diagnostic. The refactor also necessitated a change in how we determine whether two quickfix entries are equal or not. We now compare quickfix entries modulo the buffer number (which can, and does, change in a Vim session). We also fix a bug that was also hidden by the current implementation whereby signs weren't being re-placed when a buffer is reloaded. We also add some context to each fire of an autocommand, such that the call from Vim -> govim that is made in response to an event includes the autocommand event definition so that it's easier to spot what event is firing. e.g: recvJSONMsg: ["function","autocommand:3","BufNewFile,BufRead *"... We also fix up GOVIMStringFn to work correctly at the end of files and update the test accordingly to add coverage of this. We also add a number of tests to verify that govim behaves when saving unnamed buffers to go/non-go files, opening go/non-go files and switching to go/non-go files, skipping the one case that does not work in light of us having raised #810.

view details

Paul Jolly

commit sha 5d6bd957a9c16a0887e66fc012937b16ceb7e0ba

testsetup: rename GOVIM_DETECT_USER_BUSY -> GOVIM_DISABLE_USER_BUSY (#812) GOVIM_DETECT_USER_BUSY is used by default in tests to disable the automatic timeout-based detection of user busy/user not busy. However the variable is clumsily named, meaning we set a value of false to disable the timeout-based handling. Hence we rename GOVIM_DETECT_USER_BUSY -> GOVIM_DISABLE_USER_BUSY and also provide a test-only function GOVIM_test_SetUserBusy when GOVIM_DISABLE_USER_BUSY=true for manual transitioning of user busy / user not busy where required (we need this in a later PR).

view details

Pontus Leitzler

commit sha 907afa73c90dda8cab95299c29d0a216e8f6ad16

cmd/govim: remove one of the file watchers (#819) There are currently two file watchers being started, one in Init(...) and one in startGopls(...). This leads to duplicate DidChangeWatchedFiles calls to gopls. Remove one of them, as well as a dated comment about this being a temporary fix. This change also removes a field "files" (on the modwatcher struct) that isn't used anymore.

view details

Paul Jolly

commit sha 56e86d726dd3c5c0bf4c983bc8cfb3f117dfb89f

cmd/govim: fix "next" motion key mappings for top-level declarations (#820) The "next" mappings are the wrong way around: ]] when to the start of the next top-level declaration, ][ to the end. Fix that by switching them around.

view details

Paul Jolly

commit sha 30f22929aa0e045e1d5bec8784c24706ba978dbc

cmd/govim: safely handle busy state changes for non-.go buffers (#823) In 8926deca we backed out the changes for tracking all buffer changes. But in so doing we didn't properly handle the situation where the busy state changes and the cursor is in a non-go file. Fix that and add a test to verify we don't regress. Whilst we are at it: * consistently use GOVIM_test_SetUserBusy in our testscript tests * slightly refactor the types/consts used for getting the current cursor position Fixes #821

view details

Paul Jolly

commit sha 07dcaf034282a813e0eaa621b4560f24bf2f8d30

deps: update x/tools and gopls to c312e987 (#824) * gopls/doc: update daemon.md and remove 'experimental' caveats c312e987 * internal/lsp: clean up on Shutdown even if not initialized c1c69b63 * internal/lsp/lsprpc: expose configuration for auto-started daemon 30fd94b3 * go/analysis/singlechecker: append a newline after "Flags:" 79756796 * internal/lsp/cmd: add an inspect verb bd435c61 * godoc/static: update jquery.treeview to 1.4.2 5e2df02a * internal/lsp/source: offer loop keyword completions in range stmt 11d5b4c8 * internal/telemetry: convert key from string to struct eff45d17 * internal/telemetry: use keys properly for benchmarks a9aaa4e9 * internal/telemetry: remove all the event aliases 68dc0f35 * internal/lsp: migrate telemetry to using the event package 206ec5b8 * internal/telemetry: unify the event handling to an event package d780ff7b * internal/lsp/cache: remove parseGo semaphore 3dc7fec7 * all: run go generate c807066f * internal/lsp/tests: fix WorkspaceSymbols tests 0d653b92 * go/analysis/passes/printf: give leeway for fmt.Formatter satisfaction aafaee8b * internal/lsp/source: suppress keyword completions in "case" statement 43e3193a * internal/lsp/source: fix completion in empty switch statements 7bb88503 * internal/telemetry: change detach to be an event f30ed852 * internal/telemetry: add a stats benchmark e8dd451b * go/packages: drop pruned packages in tests of import graph 71bfc1b9 * internal/lsp/source: avoid type checking in AllImportsFixes 0983143f * internal/lsp: change the type of CompletionItem.TextEdit back 3e041465 * internal/lsp: suggest filing an issue if a warning is incorrect b84001dd * internal/lsp/source: offer completion "if err != nil { return err }" 138c814f * internal/lsp: bring generated protocol code up to date; stop corrupting logs 20ab64c0 * internal/lsp/source: suppress completions in ellipsis 92d517f9 * internal/lsp/lsprpc: don't connect to sockets owned by different users aa4048ac * gopls/integration/govim: update to go1.14 images 270c59dc * internal/lsp/source: return location(s) for imported packages c94e1fe1 * internal/lsp/source: support completing "range" keyword 11ec4145 * internal/lsp/source: complete keywords as types 2047c2d5 * internal/lsp/cache/mod: return errors only within ModHandle and ModTidyHandle 51e69f71

view details

Paul Jolly

commit sha c17ec1761c54a195a57d9feaf5da27bd6a538140

deps: update x/tools and gopls to (#827) Includes a couple of fixups for type changes on the gopls side. * x/tools/gopls: run go generate through CodeLens 63da46f3 * internal/telemetry: split the ocagent tests from the support functions fbeba214 * x/tools/gopls: add support for $/progress functionality 3e76bee1 * gopls: update github.com/sergi/go-diff to v1.1.0 bd88ce97 * internal/lsp/cache: fix typo df010c50 * cmd/present2md: add command to convert legacy present to Markdown-enabled present 4303120d * present: accept Markdown in present files 8ac058ed * present: record info in AST for reproducing present inputs 657575a5 * present: improve error for bad author block 17755156 * present: allow line-wrapping of bullet list items 19e328c0

view details

Pontus Leitzler

commit sha b786c5aa0f68df1443fe5c061ffd086f651a3135

govim: move plugin errorchan read to avoid deadlock (#828) If Init() fails, for example gopls exits, we might end up in a deadlock since we don't read the plugin error channel until after Init(). This change moves the reading goroutine so that it is started before Init().

view details

Pontus Leitzler

commit sha 4744627b79bdfb55d9a3abb7c8f466586f65566a

govim: move plugin errorchan read to avoid data race (#829) Embarrassing enough PR 828 fixed the deadlock but introduced a data race where the plugin error channel was read in a goroutine created before the channel was created. This change fixes the data race by moving the reading goroutine to be started after the channel creation.

view details

Rebecca Stambler

commit sha db2f5323507e94805d5d9f2bc4771f29a1e3f8e0

cmd/govim: fix complete_watched in preparation for gopls change (#833) In preparation for a future gopls change which changes the order of returned completion candidates, we unambiguously select one of the Const* values by attempting our completion with a prefix.

view details

Pontus Leitzler

commit sha c6fbe06c234152012479891d44e7dbcde3f3df32

cmd/govim: flush pending deltas before handling callbacks from vim (#834) For all callbacks to govim (other than the handler ultimately responsible for a listener_add callback) we need to flush any pending delta notifications so that govim isn't ever working with stale buffer contents Updates #830

view details

push time in a month

issue closeddominikh/go-tools

staticcheck: rare (flaky) U1000 false positive

(Discussed on IRC but writing it down to have something to refer to.)

We're using staticcheck 2020.1.2 with Go 1.13.3 in our CI environment and we very occasionally see a U1000 false positive on PRs which don't even touch the flagged code.

The symptom is very much like #642, but that bug was clearly fixed by a9480a3ec3bcedcf32d00a67bb464c058ba03281.

What we see is U1000 triggering for a bunch of methods, consts, and funcs defined in a particular package P. All of these names are unexported and are not used within the package proper, but are used in the tests. In fact, there's a U1000 warning for every unexported name in P which is used only in the test. (That is, the unused warnings I get are the same as if I rm *_test.go in the package and run staticcheck.)

I only have two examples of this failure but both times staticcheck failed only on package P, and not any other packages. (We run staticcheck over all our Go code at once using staticcheck root/....)

Unfortunately, I'm not having luck reproducing this flake. The approach that worked for #642 hasn't panned out (I've been running many instances of staticcheck in parallel over various combinations of packages, with and without a new cache for each staticcheck, with and without the race detector, etc.) I've thrown a few CPU-years at it but no failures yet, so there's probably a missing ingredient that I'm not incorporating (such as having partially stale cached results from a previous run over different code).

In theory this could be #671, but I doubt it. We would have to be doing something like deleting all the tests on a different branch to get these kinds of errors into the cache. It seems more likely that there's another bug where the package-with-tests variant is accidentally being associated with the errors for the package-without-tests.

If I keep seeing the flake I might disable the cache to see if it makes it go away.

closed time in a month

cespare

issue commentdominikh/go-tools

staticcheck: rare (flaky) U1000 false positive

We had multiple flakes per day before disabling the staticcheck cache and none afterwards, so I'm going to declare the workaround successful and just leave it disabled for now. If I can figure out the bug (or if the check is rewritten) we can re-enable the cache later.

cespare

comment created time in a month

issue commentdominikh/go-tools

staticcheck: rare (flaky) U1000 false positive

So far no flakes since disabling the staticcheck cache, so it seems likely that doing so suppresses the bug.

cespare

comment created time in a month

issue commentcespare/goclj

Ignore git directory when walking directory tree

If we make a change here, I'd like to do something more principled than teach cljfmt about git.

Cljfmt mostly copies gofmt's behavior, including in this case: it ignores files beginning with ., but descends into all directories. This doesn't seem to have been a big issue for gofmt -- I wasn't aware of running gofmt inside .git as a problem people encounter, and the only issue I can find for it was filed back in 2013 (golang/go#5488).

I think this hasn't been a big deal because people rarely run gofmt/cljfmt directly; they usually use editor integrations and rely on scripts/CI/git hooks. Can you comment more on the circumstances where this happened? Is invoking cljfmt on directories manually part of your normal workflow?

If it was a one-time thing, maybe we should just do nothing and see if it continues to be an issue for people.

vishsingh

comment created time in a month

issue commentdominikh/go-tools

U1000 error for unused functions which are used in skipped test

I've only experienced this problem with SkipNow.

Option 2 is a quick and easy fix, but it is not localized to unused. It affects the IR as a whole. A side-effect of this is that, for example, we might flag nil dereferences in skipped code.

This would be fine for me, because I don't use SkipNow to guard completely broken code (I would comment it out or delete it). Other people might, I suppose.

I didn't expect unused to understand that SkipNow prevents subsequent code from running and make inferences based on that, so I think the flip side of that is that if it starts flagging new stuff in skipped tests, it shouldn't be too surprising for people or hard to understand.

leslie-qiwa

comment created time in a month

issue commentdominikh/go-tools

staticcheck: rare (flaky) U1000 false positive

I'm disabling the staticcheck cache to see if that makes it go away. Should narrow things down.

cespare

comment created time in 2 months

issue commentdominikh/go-tools

staticcheck: rare (flaky) U1000 false positive

It turns out this happens a lot more often than I thought. I have around 100 examples from the past month, and as recently as a few hours ago.

It mostly happens for the one package I mentioned above, but I found some examples of it happening for some other packages too.

cespare

comment created time in 2 months

issue commentgolang/go

proposal: spec: generic programming facilities

@gertcuykens .go2 files are only for the experiment; they will not be used when generics land in the compiler.

(I'm going to hide our comments since they don't really add to the discussion and it's long enough as-is.)

adg

comment created time in 2 months

issue openeddominikh/go-tools

staticcheck: rare (flaky) U1000 false positive

(Discussed on IRC but writing it down to have something to refer to.)

We're using staticcheck 2020.1.2 with Go 1.13.3 in our CI environment and we very occasionally see a U1000 false positive on PRs which don't even touch the flagged code.

The symptom is very much like #642, but that bug was clearly fixed by a9480a3ec3bcedcf32d00a67bb464c058ba03281.

What we see is U1000 triggering for a bunch of methods, consts, and funcs defined in a particular package P. All of these names are unexported and are not used within the package proper, but are used in the tests. In fact, there's a U1000 warning for every unexported name in P which is used only in the test. (That is, the unused warnings I get are the same as if I rm *_test.go in the package and run staticcheck.)

I only have two examples of this failure but both times staticcheck failed only on package P, and not any other packages. (We run staticcheck over all our Go code at once using staticcheck root/....)

Unfortunately, I'm not having luck reproducing this flake. The approach that worked for #642 hasn't panned out (I've been running many instances of staticcheck in parallel over various combinations of packages, with and without a new cache for each staticcheck, with and without the race detector, etc.) I've thrown a few CPU-years at it but no failures yet, so there's probably a missing ingredient that I'm not incorporating (such as having partially stale cached results from a previous run over different code).

In theory this could be #671, but I doubt it. We would have to be doing something like deleting all the tests on a different branch to get these kinds of errors into the cache. It seems more likely that there's another bug where the package-with-tests variant is accidentally being associated with the errors for the package-without-tests.

If I keep seeing the flake I might disable the cache to see if it makes it go away.

created time in 2 months

push eventcespare/flake

Caleb Spare

commit sha 4d25312fe7d11d63bd6fa75b70e13745f8fc1dd7

Improve tempdir handling

view details

push time in 2 months

create barnchcespare/cespare-gmail.com

branch : master

created branch time in 2 months

created repositorycespare/cespare-gmail.com

flake

created time in 2 months

push eventliftoffio/dominikh-go-tools

Markus Thömmes

commit sha 785c4eef00d77ef0d831f827bac847052514605c

simple: flag redundant calls to net/http.CanonicalHeaderKey Calling net/http.CanonicalHeaderKey on the 'key' argument of net/http.Header methods is redundant as these methods canonicalize the key, anyway. Closes gh-520 Closes gh-522

view details

Dominik Honnef

commit sha f2d9b769ab1fb96316d85039efdec55e78972a54

staticcheck: fix tests for CheckExtremeComparison on 32-bit platforms

view details

Dominik Honnef

commit sha 4ddf30ca8eba832fa2a48a5251a608a562fdaf7d

Make sure analyses aren't lacking tests Restructure the test helper so that it always operates on all analyses. This way, forgetting to add tests actually causes a test failure. Also add two tests that were missing.

view details

Dominik Honnef

commit sha 3ffebb5f5a79df18ba695b4e370fab5ddf4467fa

Fix atomic accesses on 32-bit platforms When atomically accessing 64-bit values on 32-bit platforms, they must be aligned on 64-bit boundaries, and we're responsible for ensuring this alignment. For lint.Stats, we switch to 32-bit fields, so that we don't have to be careful about how we allocate the struct. 32-bit should be plenty to keep track of packages and problems. In the trivial cases, we've moved the 64-bit fields to the top of the struct.

view details

Dominik Honnef

commit sha 61c31ebd2fc155ea52bf350276752cece7c4ebd7

staticcheck: don't have Printf tests depend on architecture

view details

Dominik Honnef

commit sha f94f5ae28edd245f544a6fbb18c3086ccfe3b41c

Update 2019.2 release notes We accidentally made changes to the release notes in the website's repository instead of this repository, even though this repository contains the canonical version.

view details

Dominik Honnef

commit sha b8b92f1c351e10ad7beaabfecb9dc0b8b73401e7

Add 2019.2.1 release notes

view details

Dominik Honnef

commit sha 9738f555d2208b8ce4f00bb34a1f2042e687c7d8

staticcheck: flag calls of sort.Slice on non-slice values Closes gh-500

view details

Dominik Honnef

commit sha b5d7675f23e805cafb16f775ccc2bdd99095f196

Simplify definitions of Analyzers

view details

Dominik Honnef

commit sha 9e9c9d3692a44f108ece3d6978d347e5a6c29ada

staticcheck: flag silly bitwise ops involving iota Also improve the wording of the error while we're here. Closes gh-505

view details

Dominik Honnef

commit sha a7e641388513c6532307da60a6b43a879ec175ea

simple: in SA1008, don't make suggestion if both branches return the same value

view details

Dominik Honnef

commit sha 487fbd9f526bac87c37014aac491e458fdb2c912

simple: emit actual code instead of placeholders in S1008 Closes gh-487

view details

Dominik Honnef

commit sha 6c2dcfbea27de86d6a0237f3832ee3955b2624fd

simple: improve negations that we emit

view details

Dominik Honnef

commit sha 8fe051b07f2cd7f05d8688e570fe752e5b61cd0a

loader: print slightly better error when cgo processing fails

view details

Dominik Honnef

commit sha eb53d3af33260adc427a68a23f7374b9ad0b2d00

staticcheck: don't flag uint <= 0 While it is true that uint <= 0 can be written more specifically as uint == 0, this is not a helpful suggestion in reality. A lot of people use uint <= 0 as a defensive measure, in case uint ever becomes signed. Also, unlike all the other warnings made in the check, uint <= 0 is neither a tautology nor a contradiction, it is merely less precise than it could be. As such, changing flagged code won't fix any bugs. A lot of people considered this warning to be noise. Closes gh-534

view details

Dominik Honnef

commit sha 2a10c936ab6539969c9e9628858a385b19db6411

staticcheck: don't flag "unread" variable used in switch with no branches Avoid flagging code that reads as such: key := in.UnsafeString() switch key { default: in.SkipRecursive() } While the value of `key` is indeed useless, this pattern primarily shows up in generated code, making it a noisy positive. For the moment we choose to ignore these unread values in all code, not just generated code, based on the rationale that it looks more used than it looks unused. Closes gh-533

view details

Dominik Honnef

commit sha 26a3626557c9b1bb7e616f188e920910a00c6fe0

config: add more default initialisms

view details

Dominik Honnef

commit sha 0d0264e3bcbe88b752485c9220f4d2a93f6cf1a7

lint: fix overly aggressive filtering of checks The way in which we filtered analysers made it impossible to enable non-standard checkers via config files. We would pre-filter analysers based on the default config as well as command line arguments, which made it impossible to enable additional checks via configuration files.

view details

Dominik Honnef

commit sha a446d37d357d5781e73cf35a07099ca6638b399a

staticcheck: allow duplicate struct tags for bad citizens

view details

Dominik Honnef

commit sha d9c9f4e367a31a48232839ce22c7e9a34e388a34

staticcheck: accept vendored copies of go-flags package

view details

push time in 2 months

created tagliftoffio/dominikh-go-tools

tag2020.1

Staticcheck – a collection of static analysis tools for working with Go code

created time in 2 months

created tagliftoffio/dominikh-go-tools

tagv0.0.1-2020.1

Staticcheck – a collection of static analysis tools for working with Go code

created time in 2 months

push eventliftoffio/dominikh-go-tools

Dominik Honnef

commit sha dfe37feaecf7b73ce53f4fb8fa347265a77c6c4b

Add Molecula as sponsor

view details

Dominik Honnef

commit sha 536b5ea12d8d6ed31bfc06dc2aa1eb0514f61cc9

simple: flag unnecessary uses of fmt.Sprint Closes gh-143

view details

Dominik Honnef

commit sha 82c7dc98d5026ca37b7f82c981597810cf1c37aa

ir: add special handling for logrus methods that exit/unwind Closes gh-656

view details

Dominik Honnef

commit sha efe616ee7108b57c3f760b1ae1c7324b277d1522

functions: fix handling of panics in Terminates When we modified our IR to emit a single exit block, we didn't correctly account for explicit panics leading to the exit block. Closes gh-651

view details

Dominik Honnef

commit sha 575ccdc46111a5e61caf3bf06ded880ee994c467

ir: reset 'seen' map between uses of findPath Closes gh-650

view details

Dominik Honnef

commit sha 99f6b7d9490e6d96d992c78583e2303ba11ab9a1

Remove sponsors from README Originally we had no website and only one sponsor, so we put their logo in the README. Eventually we got a website, and promised sponsors that we'd put their logos on the website. However, we also added them to the README, for fairness. Over time we have gotten quite a few sponsors, and they change somewhat frequently, which means that - too many files in this repository are just images - too many commits are just about changing the list of sponsors - the README is getting quite long, and due to limited styling, looks really cluttered. To tidy things up, we'll only display logos on the website (staticcheck.io) from now on. That's in line with what we promise people when they become sponsors. We still prominently mention the existence of sponsors, at the top of the README, and link to a list of all of them. I hope that this doesn't upset anyone.

view details

Dominik Honnef

commit sha 82a1013350519505150bbec002cf52f829dee7a9

loader: don't return empty packages Closes gh-646

view details

Dominik Honnef

commit sha 412b8d2bdc1dd1e5fc267a9c6b53e65875476e9f

Update golang.org/x/tools dependency Closes gh-612

view details

Dominik Honnef

commit sha 32de78dc1c6c931f2bf017870750b0ca80006601

loader: don't skip packages with errors

view details

Dominik Honnef

commit sha 6cdd070ff900b239448093f4683e21d490f0e67f

facts: fix purity detection for allocations Neither make nor new should have ever been considered pure. They allocate memory and different invocations return different addresses. The ir.UnOp case has never handled allocations correctly (there was no '&' UnOp), and loads were broken when we introduced the Load instruction.

view details

Dominik Honnef

commit sha 2fc7317e106eb2ae6975b577889c2147e35f893a

code: optionally make use of purity information in MayHaveSideEffects

view details

Dominik Honnef

commit sha 9774f3b9ff1812e89d2b42fc5dc5cd4474d86faf

staticcheck: don't flag self-assignments with side effects Co-authored-by: Alexey Surikov <ksurent@gmail.com>

view details

Dominik Honnef

commit sha f433d9cd4c036a9b0f627f7b8c167054be5632bf

staticcheck: when checking printf verbs, recognize unsafe.Pointer as a pointer Closes gh-665

view details

Dominik Honnef

commit sha bb290c3c5ea0c4028d4aea9853706960640cf1f0

staticcheck: the %x and %X verbs now support floats and complex numbers Go 1.13 changed fmt to allow the use of floats and complex numbers with the %x and %X verbs. Adjust our check accordingly. Note that we do not check for the Go version, and assume that %x always behaves as in 1.13. This only causes false negatives, and it's probably not worth complicating the code to fix them.

view details

Dominik Honnef

commit sha 717cd7a0595327ea87bc8016753ce6e0ac546200

staticcheck: validate the new %O verb

view details

Jeff Hodges

commit sha 2774002210e8cbf35b5445a3805e6f173c6bec1f

facts: fix detection of goyacc generated files The "Code generated by" comment includes the optional arguments passed to goyacc. Closes: gh-677 Closes: gh-678 [via git-merge-pr]

view details

Dominik Honnef

commit sha 4d6348fedd3596c1982c5a5919b6858e0737382d

ir: remove Comment fields

view details

Dominik Honnef

commit sha 90dfb6335095e0d50c9a4ad28e75d12d41ab8cd8

ir: avoid allocating phis/sigmas we can easily prove are dead

view details

Dominik Honnef

commit sha 3b54dc1d61e2974391a12711ac070b5fa12a8cf6

ir: fix documentation of Package.Functions The list does not actually include anonymous functions.

view details

Dominik Honnef

commit sha 5f60cb41390985645e204892efb29754c27607cc

ir: don't allocate space for builder state for body-less functions We primarily use ir in the context of go/analysis and the buildir pass, which creates a new IR program for each package under analysis. For large code bases, this creates millions of instances of Function, created from export data. These functions do not need any of the transient builder state to be built. Moving this state into a separate struct that gets allocated conditionally saves approximately 50% of space for these repeated allocations, or a reduction of 10 GB when analysing cockroachdb.

view details

push time in 2 months

issue commentgolang/go

proposal: x/tools/gopls: support for per-.go file builds

Can we at least do this for // +build ignored files? (That is, assume that they're single-file packages.) I deal with these all the time (for code generation, or for little one-off programs/scripts) and it's a hassle that gopls doesn't handle them. I don't think it's a "niche edge case" or that I'm "jumping through hoops" in any way whatsoever. Search for // +build ignore in the Go source tree and you can see that I'm not the only one.

myitcv

comment created time in 2 months

issue commentgolang/go

proposal: pointer package

I often need these, and also get annoyed by the proliferation of silly helper packages.

I think a nicer fix would be a small language change to allow easier construction of pointers from literals:

p := &int64(3) // shorthand for 'n := int64(3); p := &n'
p := &"hello"  // shorthand for 's := "hello"; p := &s'
p := &0        // shorthand for 'n := 0; p := &n'; p has type *int

I thought we had an issue for something like this, but now I'm having trouble finding it.

carnott-snap

comment created time in 2 months

issue closedgolang/go

Concurrent calls to errors.As results in a data race

<!-- Please answer these questions before submitting your issue. Thanks! For questions please use one of our forums: https://github.com/golang/go/wiki/Questions -->

What version of Go are you using (go version)?

<pre> $ go version go version go1.14.1 darwin/amd64 </pre>

Does this issue reproduce with the latest release?

yes

What operating system and processor architecture are you using (go env)?

<details><summary><code>go env</code> Output</summary><br><pre> $ go env GO111MODULE="" GOARCH="amd64" GOBIN="" GOCACHE="/Users/yarik/Library/Caches/go-build" GOENV="/Users/yarik/Library/Application Support/go/env" GOEXE="" GOFLAGS="" GOHOSTARCH="amd64" GOHOSTOS="darwin" GOINSECURE="" GONOPROXY="github.com/uploadcare/common-go" GONOSUMDB="github.com/uploadcare/common-go" GOOS="darwin" GOPATH="/Users/yarik/go" GOPRIVATE="github.com/uploadcare/common-go" GOPROXY="https://proxy.golang.org,direct" GOROOT="/usr/local/go" GOSUMDB="sum.golang.org" GOTMPDIR="" GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64" GCCGO="gccgo" AR="ar" CC="clang" CXX="clang++" CGO_ENABLED="1" GOMOD="/Users/yarik/work/uploadcare/webhook/go.mod" CGO_CFLAGS="-g -O2" CGO_CPPFLAGS="" CGO_CXXFLAGS="-g -O2" CGO_FFLAGS="-g -O2" CGO_LDFLAGS="-g -O2" PKG_CONFIG="pkg-config" GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/m_/z4_ls1zd2bdd3z1846w1l8sw0000gn/T/go-build030379024=/tmp/go-build -gno-record-gcc-switches -fno-common"

</pre></details>

What did you do?

Concurrently calling errors.As: https://play.golang.org/p/7FQegBPdSkq

What did you expect to see?

No data race

What did you see instead?

Data race:

==================
WARNING: DATA RACE
Write at 0x00000135ba10 by goroutine 10:
  reflect.typedmemmove()
      /usr/local/go/src/runtime/mbarrier.go:177 +0x0
  internal/reflectlite.typedmemmove()
      /usr/local/go/src/runtime/mbarrier.go:191 +0x3e
  errors.As()
      /usr/local/go/src/errors/wrap.go:92 +0x38f
  github.com/yarikbratashchuk/datarace.fireDataRace()
      /Users/yarik/Desktop/main.go:20 +0x6e

Previous write at 0x00000135ba10 by goroutine 8:
  reflect.typedmemmove()
      /usr/local/go/src/runtime/mbarrier.go:177 +0x0
  internal/reflectlite.typedmemmove()
      /usr/local/go/src/runtime/mbarrier.go:191 +0x3e
  errors.As()
      /usr/local/go/src/errors/wrap.go:92 +0x38f
  github.com/yarikbratashchuk/datarace.fireDataRace()
      /Users/yarik/Desktop/main.go:20 +0x6e

Goroutine 10 (running) created at:
  github.com/yarikbratashchuk/datarace.test()
      /Users/yarik/Desktop/main.go:15 +0x4b
  github.com/yarikbratashchuk/datarace.TestMain()
      /Users/yarik/Desktop/main_test.go:8 +0x2f
  testing.tRunner()
      /usr/local/go/src/testing/testing.go:992 +0x1eb

Goroutine 8 (finished) created at:
  github.com/yarikbratashchuk/datarace.test()
      /Users/yarik/Desktop/main.go:15 +0x4b
  github.com/yarikbratashchuk/datarace.TestMain()
      /Users/yarik/Desktop/main_test.go:8 +0x2f
  testing.tRunner()
      /usr/local/go/src/testing/testing.go:992 +0x1eb
==================
    TestMain: testing.go:906: race detected during execution of test
--- FAIL: TestMain (0.01s)

closed time in 2 months

yarikbratashchuk

issue commentgolang/go

Concurrent calls to errors.As results in a data race

That's expected. The second argument to errors.As, target, is mutated by the function. You wouldn't call it with a global value like context.DeadlineExceeded; you'd call it on a local error value of a particular type. An example from the errors documentation is:

var perr *os.PathError
if errors.As(err, &perr) {
	fmt.Println(perr.Path)
}

If you want to check whether you have an error that matches context.DeadlineExceeded, you'd use errors.Is, not errors.As:

if errors.Is(err, context.DeadlineExceeded) {

playground

yarikbratashchuk

comment created time in 2 months

issue commentgovim/govim

cmd/govim: support running 'go build' and 'go test'

Nice! Looks good.

[...] could also implement #441 in the same PR.

That's this PR. Did you mean to refer to another one?

cespare

comment created time in 2 months

issue commentcespare/goclj

Incorrect indentation when using :let modifier

This is similar to #69.

tao-liu-liftoff

comment created time in 2 months

issue closedcespare/goclj

Handle the :let modifier for doseq and for

This code should be intended as so:

(for [x lst
      :let [a
              (* x 3)
            b
              (* x 4)]]
  (+ a b))

To make this work, we need to teach cljfmt about the :let modifier for doseq and for. Right now it doesn't know that this term is special:

(for [x lst
      :let [a
            (* x 3)
            b
            (* x 4)]]
  (+ a b))

This is very similar to #69.

closed time in 2 months

cespare

issue commentcespare/goclj

Handle the :let modifier for doseq and for

Duplicate of #73.

cespare

comment created time in 2 months

issue openedcespare/goclj

Handle the :let modifier for doseq and for

This code should be intended as so:

(for [x lst
      :let [a
              (* x 3)
            b
              (* x 4)]]
  (+ a b))

To make this work, we need to teach cljfmt about the :let modifier for doseq and for. Right now it doesn't know that this term is special:

(for [x lst
      :let [a
            (* x 3)
            b
            (* x 4)]]
  (+ a b))

This is very similar to #69.

created time in 2 months

issue commentgolang/go

proposal: runtime: add a mechanism for specifying a minimum target heap size

@rsc @aclements I'm disappointed by the outcome here.

The API the GC team designed for this issue is #29696.

This doesn't make sense to me. Issue #29696 has an API designed by @josharian. It is definitely not "for this issue" -- it seems to be solving a problem related to the interaction of caches and GC, which is unrelated except insofar as the topic is "garbage collection".

I tried to carefully describe the problem we were having, which we have experienced again and again over the years, and I collected supporting data. To review what happened:

@aclements mentioned two separate things, both of which are unresolved.

  1. The GC doesn't amortize its cost on small heaps properly. AFAIK this is a bug and it still exists. @aclements's comment on this now-closed issue is the best description of it. (It may also be tracked by #22743.)

    • I followed up on this specific issue, providing additional data from production servers and asking whether it validates this hypothesis, here, here, here, and here, and I never got a response.
  2. @aclements suggested that SetMaxHeap may be useful as a workaround, by running my application with a target max heap size and GOGC=off. (Besides this thread, we also discussed this in person once or twice.)

    I tried this out, and it works, but it's definitely not ideal since it requires me to come up with a max heap size when I otherwise wouldn't have to consider that. (I just want the GC to stop running so much on a tiny heap.) The SetMaxHeap API has now been bouncing around for years, and has been internally tested at Google, and it sounds like the experiment has basically failed, because it's so hard to use properly for its intended purpose.

    Meanwhile, the actual problem that I'm having for which SetMaxHeap was only ever a hacky workaround anyway, and which is much simpler to solve, has seemingly been ignored. The conflation of my problem with SetMaxHeap, and with the other problems people have with the GC, has made the conversation on this issue less clear than it could have been.

Finally, a year and a half after I filed this issue, @aclements wrote the first actual argument against my proposal (other than "we don't want to add knobs"), describing how a SetMinHeap API could lead to bad performance characteristics. The critique didn't make sense to me, though, and my follow-up questions were ignored.

And then, after 7 months more of silence, @rsc closed this issue as a duplicate of an unrelated issue in February.

At every step in this communication, the round trip time can be measured in months or quarters.

One of the worst outcomes, I think, is that at this point the Go community has absorbed the idea of "heap ballast" as the standard fix for this problem. (Just see all the links that GitHub attached to this issue automatically, or read the Twitch blog post that has made the rounds several times.) I never imagined, when I wrote about our heap ballast hack in 2017, that three years later it would still be the best solution.

cespare

comment created time in 2 months

push eventcespare/vim-config

Caleb Spare

commit sha b20aad5cab5a89612dad9a11b1f549356e61f45a

Update govim

view details

push time in 2 months

issue commentgolang/go

net: ParseCIDR returns IP of size 16 and not 4 for IPv4

In general IPv4 address may be represented as IPv6.

I want to use them to determine if the parsed IP address is IPv4 or IPv6, looks like it can't be done in any other way.

You can: the way to do it is to check whether it's an IPv4 address or not (so see if To4 returns nil). If it doesn't, you have an IPv4 address. If it does, you have an IPv6 address which does not represent an IPv4 address. Example:

https://play.golang.org/p/eY-VUtGE5Jr

Although the implementation of the IP address should be hidden, functions To4 and To16 actually do not follow the documentation.

They do. The address you have is the right length to be an IP address.

lzap

comment created time in 2 months

issue commentgolang/go

net: add IP.IsPrivate (RFC 1918 & RFC 4193)

It looks like this useful CL has stalled for more than a year. I think it's ready to go except for some naming concerns. Right now the CL uses the name IsLocal, but the consensus on this thread (before the CL was sent) seemed to be IsPrivate. @mikioh suggested IsPrivateUnicast instead -- @rsc, thoughts about IsPrivate vs. IsPrivateUnicast?

aaranmcguire

comment created time in 2 months

issue closedcespare/goclj

Assoc Formatting Inconsistency

I love the formatter and use it everywhere, but there is one thing that bothers me and I am not sure it's an issue as it seems to be on purpose but I don't really understand the assoc formatting

(assoc a
  :a
    b)

I kind of understand this formatting for some macros e.g cond but I find it a bit weird for functions especially given here it's not consistent with assoc-in which would be

(assoc-in a
          [:a :b]
          c)

closed time in 2 months

tzzh

issue commentcespare/goclj

Assoc Formatting Inconsistency

cljfmt doesn't distinguish indentation forms on the basis of whether the name is a function or a macro, but rather on the function semantics. assoc is indeed hard-coded in cljfmt to use the cond1 indentation, which means that:

  • Subsequent lines are indented by 2 spaces rather than being lined up with the end of the name (this is true for all the "special" recognized names)
  • The [second, third], [fourth, fifth], etc. arguments are understood to be key/value pairs and are indented in an alternating fashion

OTOH, cljfmt doesn't actually know about assoc-in at all, so it gets the default list indentation style, the same as some function you write yourself.

Possibly cljfmt should recognize assoc-in and use cond1 for it, though it's a little different from other cond1-style functions/macros in that it takes exactly 3 args, not a variable number.

In any case, you can override the indentation if you like in your .cljfmt. For example, this swaps the two functions' indentation styles:

{:indent-overrides ["assoc" :list
                    "assoc-in" :cond1]}
(assoc a
       :a
       b)

(assoc-in a
  [:a :b]
    c)
tzzh

comment created time in 2 months

push eventcespare/vim-config

Caleb Spare

commit sha e05c52791e72375acaabb175ca5e33599b6698bd

Fix gx by implementing it ourselves It sucks that this functionality is totally broken.

view details

push time in 2 months

issue commentgolang/go

x/tools/gopls: group imports together for the local module

@stamblerre what is the gopls documentation page where I could learn about the "local" option you referred to in https://github.com/golang/go/issues/32049#issuecomment-549998644? This issue (and the source code) are the only references I've found.

gracenoah

comment created time in 2 months

push eventcespare/misc

Caleb Spare

commit sha d557434949242fb2fef98dca0a0d803f149b1e31

Clean up go.mod

view details

push time in 2 months

issue commentgolang/go

cmd/compile: should -d=checkptr reject unaligned integers on architectures that support unaligned reads?

The annotation indicates that a function is expected to issue an unaligned read (correct?)

No, checkptr only checks unsafe.Pointer conversions. It doesn't instrument every possible read/write using a pointer.

Thanks -- I updated my comment.

I think the general idea still stands, though. The code that triggers the check may not be under the control of the person who created the unaligned pointer.

cespare

comment created time in 2 months

issue commentgolang/go

cmd/compile: should -d=checkptr reject unaligned integers on architectures that support unaligned reads?

It sounds like three of our options are:

  1. Declare unaligned pointers to be always bad on all architectures; delete the go:nocheckptr annotation; update any flagged code
  2. Declare unaligned pointers okay on x86; remove the alignment check on these architectures; possibly update unsafe.Alignof as @mdempsky mentioned in the preceding comment
  3. Declare unaligned pointers to be bad unless annotated with go:nocheckptr; update code to use this annotation where necessary

(3) seems to be our de facto state in Go 1.14, but I don't think it's workable. The annotation indicates that a function is expected to issue an unaligned read (correct?) but really, we need to be able to whitelist the pointer itself since the read might happen in any code. In my case, the read occurs in reflect code called via fmt (demo code) or go-cmp (real code). There's no place I can stick a go:nocheckptr annotation to make the problem go away. In general, the check will be triggered not by the code that constructs the unaligned pointer, but by the code that reads it, which may be in any (possibly third-party) package.

cespare

comment created time in 2 months

startedyuin/goldmark

started time in 3 months

issue openedgolang/go

go.dev: don't imply that vN.x.y is the latest version when vN+1 exists

<!-- Please answer these questions before submitting your issue. Thanks! For questions, please email go-discovery-feedback@google.com. -->

What is the URL of the page with the issue?

For example: https://pkg.go.dev/github.com/cespare/xxhash?tab=doc

What is your user agent?

N/A

Screenshot

screen_20200309145922

What did you do?

Viewed the v1 documentation for a module that also has a v2.

What did you expect to see?

v1.1.0 of my module was marked as "Latest".

What did you see instead?

No v1 version of my module should be considered "Latest". Only the latest version of v2 should be "Latest".

I understand that v1 and v2 are essentially two different modules, and that the discovery site is showing that v1.1.0 is the latest version of the v1 module. However, this may mislead users into thinking that v1.1.0 is somehow up-to-date. I do not want new users of my module to use v1.1.0; I want them to use the real latest version of the module which is v2.1.1 at the moment.

Ideally, when viewing v1.1.0, the users would see on the page that v2 exists and is the latest major module version. There ought to be a link to quickly go to the latest version, just as there is a red "Go to latest" link when viewing the not-latest-minor-version page (example):

screen_20200309150757

This is related to #36969, where the search ranking also pushes users toward using the old major version of my module.

Right now it seems that the discovery site has very little notion of the relationship between different major versions of the same module. Please consider how to make this site more friendly for maintainers of v2+ modules.

created time in 3 months

issue closedcespare/xxhash

get 16/32 byte sized hash from some input

i want to replace sha256 hashing in my program, i don't need strongly crypto hashing function. but i'm need to have hash with 16 or 32 byte long. How can i do that?

closed time in 3 months

vtolstov

issue commentcespare/xxhash

get 16/32 byte sized hash from some input

The XXH64 algorithm implemented by this package produces 64-bit (8-byte) values. If your application requires 16+ bytes, then it's up to you how you will produce 8 extra bytes. You could pad with 0 bytes, for instance, or you could repeat the hash bytes.

vtolstov

comment created time in 3 months

issue commentgolang/go

cmd/compile: should -d=checkptr reject unaligned integers on architectures that support unaligned reads?

@bcmills thanks for the title update. Besides answering the "should it be allowed" question, it would be nice if the error message could say what the problem is (e.g., it would be good to include the word "unaligned").

cespare

comment created time in 3 months

more