Repository: dbt-labs/dbt-core

Issue:
{{ exceptions.warn() }} returns None instead of an empty string
### Describe the bug
`{{ exceptions.warn() }}` returns None instead of an empty string (which is what I expected)

### Steps To Reproduce
1:
```
$ cat models/my_model.sql
{{ exceptions.warn("bad thing") }}
select 1
```
2. Compile the SQL, `dbt compile`

### Expected behavior
I expected to get a warning in my terminal, but the SQL should get compiled like so:
```
select 1
```
### Actual behavior
A `None` gets inserted, resulting in invalid SQL
```
None
select 1
```

**The output of `dbt --version`:**
0.16.0-rc2

**The operating system you're using:**

**The output of `python --version`:**

### Additional context
Can workaround by using the `{% do %}` syntax (as documented [here](https://docs.getdbt.com/docs/writing-code-in-dbt/jinja-context/exceptions/#warn), which I just updated).

So I'm okay with this getting a #wontfix on it.


Discussion:
Good idea @clrcrl - let's do this one for the Octavius Catto release :)
Hey all looking for some pointers on trying to make my first contribution (also newish to Python) and seems like this would be an okay one to attempt (maybe?).

Managed to find that if I added a `compiled_node.compiled_sql  = re.sub("None", "", compiled_node.compiled_sql)` in [compilation.py](https://github.com/fishtown-analytics/dbt/blob/dev/octavius-catto/core/dbt/compilation.py#L179) then it managed to compile the SQL correctly but rendering the macro not functional. This is most certainly not the right way to do this.

Traced it further back to the `get_template` / `render_template` in [jinja.py](https://github.com/fishtown-analytics/dbt/blob/dev/octavius-catto/core/dbt/clients/jinja.py) but can't quite understand what's going on here... is it because Jinja parses these 2 differently?
```
{% do exceptions.warn("warning") %} 
{{ exceptions.warn("warning") }} 
```

Keen to know where I should be looking to make the changes. Thanks :)
Hi @jeremyyeo, great to hear you're working on this! I would change the function definition of `warn` in `core/dbt/exceptions.py` from `return run_or_error(msg, node=node)` to:
```
run_or_error(msg, node=node)
return ''
```

I think that's going to be a lot easier than trying to remove `None`s from the compiled sql!
Oh, and I neglected your second part of the question! Yes, there is a difference! `{% do ... %}` always evaluates to the empty string in jinja. On the other hand, `{{ ... }}` evaluates to `str(...)`. So the trick is to make `exceptions.warn` return something that will evaluate to the empty string. We do something similar in `log` (see `core/dbt/contexts/base.py`).

Resolving patch:
diff --git a/core/dbt/exceptions.py b/core/dbt/exceptions.py
--- a/core/dbt/exceptions.py
+++ b/core/dbt/exceptions.py
@@ -819,7 +819,8 @@ def warn_or_raise(exc, log_fmt=None):
 def warn(msg, node=None):
     # there's no reason to expose log_fmt to macros - it's only useful for
     # handling colors
-    return warn_or_error(msg, node=node)
+    warn_or_error(msg, node=node)
+    return ""
 
 
 # Update this when a new function should be added to the


Test patch:
diff --git a/test/integration/013_context_var_tests/emit-warning-models/warnings.sql b/test/integration/013_context_var_tests/emit-warning-models/warnings.sql
--- a/test/integration/013_context_var_tests/emit-warning-models/warnings.sql
+++ b/test/integration/013_context_var_tests/emit-warning-models/warnings.sql
@@ -1,2 +1,3 @@
 {% do exceptions.warn('warning: everything is terrible but not that terrible') %}
+{{ exceptions.warn("warning: everything is terrible but not that terrible") }}
 select 1 as id