Add --exclude-location flag to hide file locations in detector messages

[ep0chzer0]

Summary

Fixes #2222

Adds a new --exclude-location flag that removes file location information (filename and line numbers) from detector messages.

Before/After

Without flag:

- >=0.8.19 (test.sol#2)
- ReentrancyExploit.get_money() (ReentrancyExploit.sol#35-37)

With --exclude-location:

- >=0.8.19
- ReentrancyExploit.get_money()

Use Cases

As noted in the issue:

• VS Code integration - Location is already shown in the editor, making it redundant in the message
• Third-party integrations - Easier to parse output programmatically
• Cleaner output - When location context isn't needed

Changes

• slither/utils/output.py: Add set_exclude_location() and get_exclude_location() functions, modify _convert_to_description() to conditionally exclude location
• slither/__main__.py: Add --exclude-location CLI argument and call set_exclude_location()
• slither/utils/command_line.py: Add default value for exclude_location

Testing

Tested manually with a simple Solidity file - the location info is correctly excluded when the flag is provided.

[CLAassistant]

All committers have signed the CLA.

[dguido]

Code Review

Thanks for this PR - the feature addresses a real need from issue #2222.

Main Concern: Global Variable Pattern

The implementation uses a module-level global:

_exclude_location = False

def set_exclude_location(exclude: bool) -> None:
    global _exclude_location
    _exclude_location = exclude

This works, but the codebase already has a more idiomatic pattern in colors.py:

class Colors:
    COLORIZATION_ENABLED = True

def set_colorization_enabled(enabled: bool) -> None:
    Colors.COLORIZATION_ENABLED = enabled

Suggestion: Use a class attribute for consistency:

class OutputConfig:
    EXCLUDE_LOCATION = False

def set_exclude_location(enabled: bool) -> None:
    OutputConfig.EXCLUDE_LOCATION = enabled

def get_exclude_location() -> bool:
    return OutputConfig.EXCLUDE_LOCATION

This matches the existing pattern and makes the configuration more discoverable.

Minor: Repetitive if/else in _convert_to_description

The repeated pattern could be simplified with a helper:

def _format_with_location(name: str, source_mapping, exclude: bool) -> str:
    return name if exclude else f"{name} ({source_mapping})"

---

Overall the feature is solid. Just requesting the pattern change for consistency with the rest of the codebase.

[ep0chzer0]

Hi maintainers, could someone please approve the CI workflow runs when you get a chance? This PR is ready for review. Thanks!

[ep0chzer0]

Thanks for the detailed review! I believe the current implementation already addresses both points:

1. Class Attribute Pattern

The code already uses the OutputConfig class pattern (matching colors.py):

class OutputConfig:
    """Configuration settings for output formatting."""
    EXCLUDE_LOCATION: bool = False

def set_exclude_location(exclude: bool) -> None:
    OutputConfig.EXCLUDE_LOCATION = exclude

def get_exclude_location() -> bool:
    return OutputConfig.EXCLUDE_LOCATION

2. Helper Function

The repetitive if/else pattern is already simplified with the _format_with_location helper:

def _format_with_location(name: str, source_mapping: SourceMapping) -> str:
    if OutputConfig.EXCLUDE_LOCATION:
        return name
    return f"{name} ({source_mapping})"

This is used throughout _convert_to_description() to reduce repetition.

Could you take another look at the current diff? Perhaps there was a caching issue or you were viewing an earlier version. Happy to make any additional changes if needed!

[ep0chzer0]

Thanks for the review @dguido! I've implemented both suggestions:

1. Class attribute pattern: Added OutputConfig class with EXCLUDE_LOCATION attribute to match the Colors pattern in colors.py

2. Helper function: Added _format_with_location() to clean up the repetitive if/else logic in _convert_to_description

The changes are already in the branch. CI is passing - just waiting for workflow approval on the latest commit after rebase.

[ep0chzer0]

Also @dguido, if there are any other specific issues you'd like to see tackled, I'd be happy to take them on. Always looking for ways to contribute to Slither!