This is a step forward for the full migration of Automatic Exec Groups (AEGs). This change will be effective once AEGs are enabled.
In this CL I've added a toolchain_type to `toolchain` attribute of ctx.actions.{run, run_shell} since the Execution platform is selected on a toolchain type level, not on a rule level like before AEGs.
PiperOrigin-RevId: 560782417
The last remaining !go1.22 build is protecting the definition of
pkg/sync.maptype, which is a copy of runtime.maptype. We need to ensure these
definitions match so we can safely access the hasher field.
At its core, this CL achieves this check by ensuring that
unsafe.Offsetof(maptype{}.Hasher) matches the offset in the runtime version of
the type.
Several things happen along the way to achieve this:
* As of May 2023, runtime.maptype is actually a type alias for
internal/abi.MapType. checkoffset was failing to record the offsets because it
skipped type aliases for no good reason. Simply removing the type alias check
is sufficient to make type aliases work. (This part of the CL is technically
unnecessary because this CL ultimately references internal/abi.MapType
directly in anticipation of removal of the type alias. But there is no reason
not to allow type aliases).
* The checkconst / checkoffset regexp unintentionally does not allow / in
package paths, even though the rest of the package supports /. Fix this.
* checkconst was comparing the literal AST expression string against the
runtime value (i.e., "unsafe.Offsetof(maptype{}.Hasher)" vs "72", which fails
comparison. Switch to getting the resolved constant value from the type
checker.
* nogo/check.importer only loads package facts on direct import (stored in
importer.cache). If a package is not directly imported ImportPackageFact will
not find the facts. Typically packages need to ensure they directly depend on
packages they want facts from (e.g., pkg/sync has a dummy import of runtime in
runtime.go). This doesn't work for internal/abi because we cannot directly
import an internal package. Work around this as a hack by unconditionally
"importing" internal/abi when analyzing any package.
With regard to the last point, not that the nogo/defs.bzl nogo integration only
provides facts from the direct dependencies and the entire stdlib (since the
stdlib is analyzed as one bundle). So this trick only works for a stdlib
package. A bazel package indirect dependency would be missing facts altogether.
PiperOrigin-RevId: 549999084
With the latest nogo change, facts are no longer in the build paths. Since full
is only used to speed these paths (and is enabled for full analysis) the full
flag is now redundant and can be removed safely.
PiperOrigin-RevId: 511935530
This allows fact information to be validated in the underlying source files,
but requires us to explicitly maintain this in appropriate version-tagged, and
architecture-tagged files. This is more explicit and safer.
This mechanism uses a special regular expression for matching a +checkconst
stanza to validate constant values, sizes and offsets. This applies to both Go
source files and assembly files.
PiperOrigin-RevId: 511867507
Unexported constants can end up unaddressable in objectpath and thus their
object facts get lost on fact import. Work around this by adding a
package-level fact which is a map of all constants to their value.
Remove the Value facts because it is confusing to have two ways to access the
same thing (especially when one only works sometimes).
PiperOrigin-RevId: 505153453
Based on cl/504066914, this generates the proper procid offsets at build time.
Package facts needs an update to properly skip underscore imports, which don't
have facts for some reason (because they are unnamed?).
Drop use of runtime.getprocid given that these generated code is pretty solid.
PiperOrigin-RevId: 504926257
This removes the need for ongoing tags.
This change requires some minor updates to remove dependency cycles, since
the goid package is a base library used by many internals (log, sync, etc.).
PiperOrigin-RevId: 504066914
All atomic 64 bit ints are changed to atomicbitops.(Ui|I)nt64. A nogo checker
enforces that sync/atomic 64 bit functions are not called.
For reviewers: the interesting changes are in the atomicbitops and checkaligned
packages.
Why do this?
- It is very easy to accidentally use atomic values without sync/atomic funcs.
- We have checkatomics, but this is optional and is forgotten in several places.
- Using a type+checker to enforce this seems less error prone and simpler.
- We get NoCopy protection.
- Use of 64 bit atomics can break 32 bit builds. We have types to handle this
without any runtime cost, so we might as well use them.
PiperOrigin-RevId: 440473398
nogo:fast is converted to nogo:full with the opposite meaning.
All nogo tests have to be always executed with this option.
Analyzing Go Standard Library takes about 10 minutes on buildkite,
but it is required only to run nogo tests.
PiperOrigin-RevId: 438343203
https://go.dev/issue/50860 is adding Pointer[T] to sync/atomic,
which will trip up analyzers that don't handle generics. Skip
it for now.
Drop constraints, maps, slices, as they were dropped from the
standard library.
PiperOrigin-RevId: 437808952
Andrei Vagin
Nevena KotlajaandgVisor bot
Luke SandbergandgVisor bot
Jamie LiuandgVisor bot
Michael PrattandgVisor bot
Adin ScannellandgVisor bot
Liam Miller-CushonandgVisor bot
Kevin KrakauerandgVisor bot
Ayush RanjanandgVisor bot