| commit | 8b228f81d9f8e55707c499eb2edb19e2896440e8 | [log] [tgz] |
|---|---|---|
| author | Googler <noreply@google.com> | Fri Nov 08 11:15:04 2019 -0800 |
| committer | Copybara-Service <copybara-worker@google.com> | Fri Nov 08 11:16:06 2019 -0800 |
| tree | 753a734fda59dbf69366f34c646b6ecbfe932ac3 | |
| parent | 5dd4b22541d6233c7f30794e06ff35864dc77c49 [diff] |
bazel syntax: delete Mutability parameter from SkylarkDict methods In all cases, the correct mutability to use is this.mutability, and (AFAICT) all callers redundantly pass that value. This change leaves in place for now the Location parameter in methods such as put, which serves two purposes: 1) to decorate the EvalException thrown by a failed mutability check. This is unnecessary because an EvalException with no location is caught and rethrown in BuiltinFunction.call and MethodDescriptor.call, so it would be fine to use a null Location here and indeed almost everywhere else throughout lib.syntax and indeed Blaze. 1) to select the mutability-checking variant of the method, (which throws EvalException) instead of the standard Map.put method, which throws an unchecked UnsupportedOperationException. If a failed mutability check instead threw an unchecked exception, we could unify around the simpler standard Map methods. (One might object that "unchecked is bad", but to date the existing 'throw UnsupportedOperationException' statements do not appear to have been a problem.) I thus propose to delete the Location parameters in a follow-up. PiperOrigin-RevId: 279352345
{Fast, Correct} - Choose two
Build and test software of any size, quickly and reliably.
Speed up your builds and tests: Bazel rebuilds only what is necessary. With advanced local and distributed caching, optimized dependency analysis and parallel execution, you get fast and incremental builds.
One tool, multiple languages: Build and test Java, C++, Android, iOS, Go, and a wide variety of other language platforms. Bazel runs on Windows, macOS, and Linux.
Scalable: Bazel helps you scale your organization, codebase, and continuous integration solution. It handles codebases of any size, in multiple repositories or a huge monorepo.
Extensible to your needs: Easily add support for new languages and platforms with Bazel's familiar extension language. Share and re-use language rules written by the growing Bazel community.
Follow our tutorials:
See CONTRIBUTING.md
